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

bttv msp3400 2.6.15.6 - > 2.6.16 stereo stop working

On Thursday 30 March 2006 00:12, Roland Scheidegger wrote:
> Hans Verkuil wrote:
> > On Wednesday 29 March 2006 08:25, Daniel Smolik wrote:
> >>> Please apply the attached patch to msp3400-kthreads.c and let me
> >>> know if this fixes the problems.
> >>
> >> I mean that situation is the same. But in log as I send before
> >> (log is with patch applied) isn't  stereo newer set automaticaly I
> >> must always switch manualy (xawtv always show mono) but don't hear
> >> any difference when switch mono/stereo.
> >
> > Sorry to ask you this again, but can you make another log, this
> > time with debug set to 3 and taken from the /var/log/messages file
> > so that I can see the timestamps too. It's really peculiar and I
> > need a more detailed log.
>
> Sorry, too late :-) Here's a patch, works for me (against hg-v4l-dvb
> two days or so ago, patched with your 2 patches).

Thanks! I'll test it tomorrow and combine it with my patch that should 
hopefully do proper muting during channel changes. I'll also try and 
let the driver fake my msp3400d as an msp3400c. Good idea.

	Hans

> - since msp3400c_set_carrier is no longer called within
> set_audio_mode, the DCO values for one channel never got set up,
> which is why the chip always reported mono.
> - With that fixed, xawtv still always thinked a channel is already
> stereo and thus not switch to stereo automatically (it only switches
> to stereo if it detects stereo capability but not already set stereo
> mode I think). This is due to the incredibly messy v4l2 to v4l1
> translation inside bttv, which will pretty much guarantee you get
> (and set) more or less random values with the v4l2 functions (at
> least for audio). Quick hack up for that included.
> - I also increased the wait period for watch_stereo the first time,
> I've seen it (twice) that 1 second wasn't quite enough.
>
> Oh, and btw the driver writes to another reg which doesn't exist (dsp
> 0x41) (the msp3400c has 2 scart outputs, but according to my
> datasheet the channel source/matrix (not the acb bits) are the same
> for both scart outputs I think). This is not new however and doesn't
> seem to cause any harm. The msp_prod_hi/lo assignment with that div
> and modulo 10 look a bit crazy if you ask me, but don't seem to be
> the cause for this. (I do have a msp3400c c8 datasheet, the chip
> actually seems to be newer: rev1=0x0503, rev2=0x0a1b)
> There also seems to be some problem with overmodulation sometimes,
> maybe something is wrong with input biasing or fir coefficients or
> whatnot. Not sure exactly since when this problem exists, depending
> on the channel it's not noticeable. Maybe I'll need to look at those
> quasi peak registers to see what's going on ;-).
>
> Roland
> P.S: actually, can't you test this code on a msp3410d? IIRC the d
> versions could be programmed like the c versions if you wanted. I
> might remember that wrong though...

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