[pvrusb2] pvrusb2-mci-20070114 radio support - stereo?

[Mike Isely]

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.

Definitely.


> I could be wrong, but, to my understanding, the determination of 
> stereo vs mono lies 100% in the programming of the tda9887 analog IF 
> demodulator.

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


-- 
                        |         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
                        |                             |