[pvrusb2] pvrusb2-mci-20070114 radio support - stereo?
isely at isely.net
Fri Jan 19 15:25:26 CST 2007
On Fri, 19 Jan 2007, Michael Krufky wrote:
> Pantelis wrote:
> > I can confirm that under windows the WinTV Radio program does stereo
> > and even autodetects which stations broadcast stereo vs mono (not
> > everybody broadcasts stereo here). Unfortunately I cannot test that under
> > linux since my test system does not have any speakers and I 'm testing
> > with a *single* headphone (the one attached to a close-talk mic). So no
> > chance of testing whether it sounds like stereo. (Otherwise I would probably
> > have caught this earlier). This is for a model 29034.
> > So, it is either a bug in the demodulator, or we are missing some bit
> > of (initialization?) code or doing something different. In any case, this
> > needs more investigation.
> I could be wrong, but, to my understanding, the determination of
> stereo vs mono lies 100% in the programming of the tda9887 analog IF
I think you are correct.
> The tda9887 is handled by tuner.ko, and it should already know how to
> handle FM Stereo. I haven't looked closely at the tuner handling code
> within pvrusb2, but perhaps the tuner handling has been abstracted
> such that the tuner.ko module isnt getting full control of tuning
> commands? just a thought... Mike Isely will know better on how to
> check about my theory, here.
The way the driver operates the various chip-level drivers is that
_unless_ it has reason to do otherwise, all of those drivers see all
V4L2 command traffic (even the lirc module if it shows up to the
party...). The tuner core is not one of the exceptional cases - a few
old V4L1 modules are the exceptions but even that doesn't come into play
if you are running any kernel 2.6.16 or later.
It is possible that there is a V4L2 command that needs to be issued that
isn't; it's one of the things to be looked into.
It's worth noting here that the horizontal resolution problem that
existed last Fall for 24xxx devices was an interesting case. There, the
pvrusb2 driver was technically doing everything right, but the cx25840
module has/had a misbehavior where it would not correctly program
horizontal scaling unless it is first given a VBI related command -
which should have nothing to do with video scaling! Because the pvrusb2
driver doesn't do VBI it wasn't bothering with that command. This is
why ivtv was ok and pvrusb2 wasn't. Once the pvrusb2 driver was
modified to issue the (otherwise useless) VBI command to the cx25840
module, the scaling problem went away.
This current issue could be yet another case where the pvrusb2 driver
isn't behaving in precisely the "expected" manner in spite of the fact
that it is probably doing the right thing. Food for thought, and
something I'm going to keep in mind here.
> Another theory, although unlikely, is that the tuner and tda988x is
> already being programmed correctly, but the mpeg encoder isn't
> encoding the mpeg audio in stereo mode. This *is* possible, although
> unlikely due to the fact that we know that the stereo stream is being
> encoded properly in television mode.
I don't think that's likely. The mpeg encoder isn't really being told
anything different here. It's just getting audio as usual along with
muted video. If anything we should be trying to get the encoder to stop
sending the (blank) video stream since that just wastes bandwidth.
Upstream of the encoder, the audio pathway is always stereo, and we also
already know that mplayer sees a stereo mp3 audio stream.
> Anyway, just a thought... I could be totally wrong here. Mike, what
> do you think?
My $0.02 are above :-)
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2