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

bttv msp3400 2.6.15.6 - > 2.6.16 stereo stop working

On Wednesday 29 March 2006 04:00, Roland Scheidegger wrote:
> Hans Verkuil wrote:
> > Please apply the attached patch to msp3400-kthreads.c and let me
> > know if this fixes the problems.
>
> I've tried that patch and it doesn't help. I think the chip gets
> misprogrammed somewhere, the stereo detect reg always hovers around 0
> even after a long time (nowhere near that 4096 it needs to be for
> stereo).

I'll take another look tonight.

>
>  >> 3) when pres enter(xawtv)  sound mute but when increase  volume
>  >> or switch channel some glitches are present.
>  >
>  > It's not likely that that will be solved. It's not present with
>  > msp3400d and newer versions. It may be a limitation of the
>  > msp3400c.
>
> Sorry, but this is a lame excuse at best :-) (Not that I'd accuse
> anyone of not fixing it, I understand it may not exactly be the most
> important thing...)

Yeah, it's a lame excuse. I wish I had a msp3400c card, I have the d and 
g revisions, just not c.

> One reason (there may be more) is that the chip simply is never muted
> when it does its am/fm scan (which takes a while). xawtv (and
> probably other progs) will mute sound, then switch channel, then
> unmute. Now, what happens is that xawtv mutes (which causes a restart
> scan but it doesn't really matter) and audio is muted. Then, channel
> is switched, which will cause the next restart scan (and audio is
> still muted). Then, xawtv unmutes, so audio gets unmuted, even though
> the msp3400 is still trying to find the carriers (and I think this
> causes another restart scan). I'm not exactly sure what happens next,
> but I see another restart_scan which mutes again, until finally audio
> gets unmuted for the last time. No wonder there's a lot of popping
> noise...
> Other things are wrong too. For instance that muting audio causes a
> full restart scan is just evil (and no wonder the popping noises are
> back with that).
> There is a fast_mute value too which could be used instead of setting
> volume to 0, which might prevent some popping noises, though I don't
> think it is needed (it certainly won't help with the fact that the
> chip simply is not muted while searching for the carriers). The 3410d
> may be way faster with detection so it doesn't have the problem that
> sound gets unmuted when it's still busy with detection, or it may
> just mute its output anyway when doing autodetection, so I'm not
> surprised there is no problem there.

Thank you for this detailed info. I'll dive into the datasheets again 
tonight and see if I can fix it.

	Hans

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