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

bttv msp3400 2.6.15.6 - > 2.6.16 stereo stop working

On Friday 31 March 2006 17:14, Roland Scheidegger wrote:
> Hans Verkuil wrote:
> > 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...)
>
> Ok I've finally found this: hg-hverkuil-v4l-dvb-9abb710ed22c
>
> > 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.
>
> That's true but you could argue it's the applications responsibility
> to check from time to time that it really gets the mode it wants.

Why? And what would the application do with that information? The 
application should be able to show what is transmitted (mono, stereo, 
bilingual) which it can get from the rxsubchans field. That's what it 
is there for. It's like setting your TV to LANG B and then switch to a 
simple stereo transmission and suddenly it is LANG A. 

Anyway, this really was the original intention of the API (I've been 
discussing this before with Michael Schimek). The language still needs 
improving, though. This whole area is one big mess where both 
application and driver authors had different and usually wrong 
interpretations of the API. Not helped by the mixing of V4L1 and V4L2. 
I am sorting out the kernel drivers but as you can see it is a 
difficult process.

> The 
> xawtv author certainly thinked that audmode is not only used to be
> set by the app (the -v 2 output will list that audmode as "tuner
> current"). I would consider that as a flaw in the v4l2 api btw, it
> doesn't quite make sense both ways - if it's never set by the driver
> then an app has to go through hoops to figure out what the current
> mode actually is

Again, why? The user needs to know what is transmitted! Say a channel 
broadcasts NTSC mono + SAP. The audmode is set to stereo initially. So 
G_TUNER will return mono as audmode (as that is the fallback in this 
scenario). But that is not the 'tuner current'! The user needs to know 
what is actually transmitted so that he/she can adjust the audio mode 
accordingly.

> (query both rxsubchans and audmode, then determine 
> the mode according to that fallback matrix, and it's downright
> impossible if there is a dual-language program and audmode is stereo,
> since two answers are possbile in that case according to api spec

Yes, that's one reason I've added LANG1_LANG2. For normal TV viewing it 
makes no sense to hear both languages, but for PVR recordings it does. 
The core problem with this API is that nobody really understood all the 
combinations that can happen. It was also originally developed in a 
somewhat NTSC-centric manner and did not take the complications that 
occur with NICAM/PAL into account. As a result the stereo mode is 
almost obsolete. Really lang1 could take over the role of stereo (or 
stereo that of lang1) since in practice they'll mean the same thing. 
This API is not the best ever designed.

> ). 

> btw shouldn't rxsubchans also contain v4l2_tuner_sub_mono in case of
> a stereo reception?

I think so, yes. As I understand it there are the following combinations 
possible:

NTSC:

mono, mono + stereo, mono + sap, mono + stereo + sap

PAL/SECAM:

mono, mono + stereo, mono + lang2

PAL/SECAM-NICAM:

mono + stereo
mono + lang1 + lang2
mono + lang1

Where mono = the analog mono channel and the others are the decoded 
digital NICAM channel.

However, this is not reflected in the API. I want to make a proposal to 
improve this.

> > 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.
>
> Basically works (with the caveat that now xawtv will always show
> stereo, no matter what, except if you change it manually to say,
> lang2, then it will from there on always show lang2 on all channels
> due to the reasons above), however the crackling and popping noises,
> if anything (hard to say), got worse when channel switching (I'm not
> sure the chip reset is really a good idea there?), and are still
> present when changing volume/muting (still doing the full restart
> scan, am/fm detection,...).

Really? I didn't have any problems with my msp3400d pushed in msp3400c 
mode. In the old situation that would give me noise, but no longer with 
these patches.

> Also, I think the msp3400c_set_carrier 
> call should go in
> msp3400c_set_mode, there is just one single instance left where not
> msp3400c_set_carrier is called directly after msp_set_mode (cause the
> carriers set set in msp3400c_set_mode are not the "final" ones), it
> is just confusing for debugging. Though the order in which the
> demodulator/dsp regs are written isn't quite right if it's not set
> there, not that it matters but maybe some of the functions should get
> rearranged a bit.

I'll look into this tomorrow.

Thanks again for the feedback!

	Hans

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