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

bttv msp3400 2.6.15.6 - > 2.6.16 stereo stop working

Daniel Smolik wrote:
Daniel Smolik napsal(a): 
Hans Verkuil napsal(a):

On Sunday 26 March 2006 16:33, Daniel Smolik wrote:

Hans Verkuil napsal(a):

On Sunday 26 March 2006 15:04, Roland Scheidegger wrote:

Hans Verkuil wrote:

Is this log all you get when running xawtv in 2.6.15? Can you make
another log, this time starting xawtv, select a stereo channel and
wait 30 seconds, then select LANG1 as audio mode, wait another 30
seconds, then go back to stereo and wait another 30 seconds before
closing down. Can you mail me (off-list) the log from the
/var/log/messages file as that includes timestamps. Please also
run the same procedure again for 2.6.16.



Are you sure you really want to compare it to 2.6.15? I'm sure you
know (as you've fixed it) that this one has completely and utterly
broken stereo / multilanguage selection due to the whacky
best_video_sound function - if you select stereo you get mono, if
you select lang1 or lang2 you get stereo and so on. Doesn't work
at all. I think for me it worked correctly last time with 2.6.13
(not sure, might have been 2.6.12). Either 2.6.13 or 14 introduced
the bogus reporting of the detected mono/stereo/multilang sound
(so xawtv got its initial setting wrong, which could be fixed by
manually setting the desired audio setting), whereas as said
2.6.15 broke it completely. For 2.6.16, xawtv also reports always
mono for me (on a msp3400c). I can switch to lang1/lang2 at least
without getting mixed languages...



What I want to know is why the behavior is different for the
msp3400c. I've tested the msp3400d and g versions and they work
fine. Without a msp3400c I cannot test it and I did the best I
could. As you say, it was all horribly broken, and everything
should be fully functioning again in 2.6.17. Also, the language
handling is by definition broken in the poor v4l1 implementation.
Full fledged support is only possible in v4l2. But that's another
story.

I'd really appreciate it if you or Daniel could test with the
latest v4l-dvb repository from www.linuxtv.org to see if it is
working in there (and thus in 2.6.17).



Yes I download this  hg-v4l-dvb-110e8e48f80b.tar.bz2 I am no familiar
with mercurial. Is it right file for testing ?



Yes, that's fine. I hope this works.


I compile this with my 2.6.15.6 compiled without problems but see the log :-(....
In first time I mean that my msp3400 go away. But I reboot to 2.6.16 and sound works.
If I boot to kernel with development drivers and only reboot to another where msp3400 works , MSP3400 isn't detected. I must turn off computer and boot again :-(.

Just wanted to say I can confirm that behaviour (not surprising, I have exactly the same card (type 11)). I believe the msp3400 chip doesn't have its reset pin wired to anything except a capacitor, so once you've sent it commands which cause it to lockup or something so it no longer responds to i2c commands it will stay dead and cannot be revived - it won't get recognized at all again with any version of the driver afterwards. So it looks like something is wrong with the msp3400 driver in the current tree causing the msp3400 to cease to work.

btw somewhat unrelated but what still doesn't work (and never has) is audio muting when channels are switched. audio gets unmuted very fast, and the msp3400 itself is never muted, which leads to about 3-5 crackling noises when a channel is switched. It looks like you'd need to do it manually, as the chip doesn't really have any ability to mute automatically. It has some mute function (ad_cv bit 9), which I've tried playing with but it's utterly useless (well it even basically says so in the datasheet, so I'm not really surprised) - all it does is mute some perfectly good channels, but it does absolutely nothing when switching channels.

Roland

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