By Date: <-- -->
By Thread: <-- -->

bttv msp3400 2.6.15.6 - > 2.6.16 stereo stop working

On Friday 31 March 2006 03:34, Roland Scheidegger wrote:
> Hans Verkuil wrote:
> > Please try my v4l-dvb mercurial repository:
> > http://linuxtv.org/hg/~hverkuil/v4l-dvb
> >
> > This should fix all problems (I hope :-) for both bttv and msp3400.
>
> I'll try that tomorrow (couldn't quite find the right file to
> download which actually has the changes included and need some sleep
> now...)
>
> > Note that xawtv now always shows the audio mode for each channel,
> > but that is an application bug: it should show rxsubchans, not
> > audmode.
>
> I don't think so, if I interpret the v4l2 api correctly (and I'm no
> expert on that) I think the expectation is that the driver SHOULD
> change the audmode if it's not currently supported - the api doesn't
> say explicitly if "currently unavailable" does count for that
> exception when the driver is allowed to change that (usually only
> user-changeable) field but I think it would not make sense otherwise,
> as a program would be completely unable to find out what audio mode
> actually gets used currently. xawtv uses vidioc_g_tuner to get both
> rxsubchans and audmode at once (with xawtv -v 2 you can see that) and
> it uses audmode to show the current mode at the OSD (or in the
> options panel). Or are you talking of that audio mode popup? My xawtv
> version (3.95) always seems to show the full set (without lang1_lang2
> though, only mono, stereo, lang1 and lang2), regardless what
> rxsubchans/audmode are, so you can still select "lang2" for instance
> when there is only mono available, which you could consider an app
> bug.

That line in the spec should be changed as it is confusing. The only 
time a driver sets audmode is during initialization. The reason is 
simple: say the user selects audmode=stereo, then goes to a mono 
channel at which point the driver would switch audmode to mono. Then 
back to a stereo channel and audmode would remain mono. Not what you 
want. Audmode sets the behavior of the driver depending on the received 
subchannels. In the case of conflicts the fallback matrix in the spec 
defines what would happen.

audmode is a user setting, rxsubchans is a driver supplied value. I 
can't blame xawtv, though: bttv horribly mangled the audmode/rxsubchans 
values and the spec isn't entirely clear. So there probably was no 
other option. I have noticed that audmode/rxsubchans support in most 
v4l drivers is poor to non-existent. It took me a fairly long time 
before I understood how it is supposed to work.

>
> > Let me know how it goes.
>
> I see you have also improved the quick stereo detection. If you're
> really interested, I stumbled upon that stereo identification reset
> reg (dsp 0x15) which is supposed to speed things up - I think it's a
> bit crazy though :-)
> Oh, and apart from writes to the non-existing dsp 0x41 reg (scart2
> matrix - chip has scart2 out but uses same matrix as scart1) I've
> also seen writes to the non-existing dsp 0x10 reg (nicam prescale -
> the chip has nicam but it looks no nicam prescale reg at least not
> mentioned in my c8 datasheet). Looks though like writes to
> non-existing dsp regs are much more forgiving than writes to
> non-existing demodulator regs ;-).

Ah, thanks. I'll look into that too. There are no doubt more bugs in 
that area, there are so many msp versions that it's difficult to make 
sure I've covered all combinations. Oh well, one step at a time. At 
least it is much improved over the previous msp3400 drivers.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list