Re: Audio drop on saa7134

[David Liontooth <lionteeth@cogweb.net>]

hermann pitton wrote:
> Hi,
>
> Am Sonntag, den 20.09.2009, 06:02 -0300 schrieb Mauro Carvalho Chehab:
>   
>> Em Sun, 20 Sep 2009 01:24:12 -0700
>> David Liontooth <lionteeth@cogweb.net> escreveu:
>>
>>     
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbbbb
>>>       
>> This means mute. With this, audio will stop.
>>
>>     
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x000000
>>> Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbbbb10
>>>       
>> This means unmute.
>>
>> It seems that the auto-mute code is doing some bad things for you. What happens
>> if you disable automute? This is a control that you can access via v4l2ctl or
>> on your userspace application.
>>
>> Are you using the last version of the driver? I'm not seeing some debug log messages
>> that should be there...
>>
>>
>>
>> Cheers,
>> Mauro
>>     
>
> despite of still 1001 messages unread, Mauro is right here.
>
> You are also for sure not on a saa7134, likely you would not ever had a
> reason to come up here on such. But the much better is to have you now.
>   
lspci says

00:07.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 
Video Broadcast Decoder (rev 10)

The cards apparently have the saa7133HL-v101 chip. Are you suggesting 
the saa7134 would be better?
> Means, you are at least on a saa7133, not able to decode stereo TV sound
> on PAL and SECAM systems, vice versa counts for the saa7134 on SYSTEM-M.
>   
I'm recording NTSC -- are you saying the saa7133 should be able to 
decode stereo on NTSC?

If "vice versa" for the saa7134, does that mean this chip is not able to 
decode stereo on NTSC?

Sorry, I don't know what SYSTEM-M is in this context.

If you could help me find a chip that avoids this audio drop problem, 
that would be great.
> The automute is for convenience of the users, say not to have loud noise
> on channel switching. 
I see. That's irrelevant for my purposes; the channels are switched 
before the recording starts.
> It is also controlled by different registers for
> analog sound and PCI dma sound.
>   
I'm using PCI dma sound.
> If debugging those issues, one more thing to mention is that external
> video in without audio will kick in mute on those cards too at the first
> round.
>
> It should be possible to disable all such funny stuff on production
> systems, pleasant for the average user's conditions, and then see if
> anything should still remain.
>
> On bad mobos, needing PCI quirks and other such stuff, we are likely not
> any further than what you have seen on bttv previously, but in 99.9
> percent of the known cases it seems to work.
>
> Else Mauro again is right, even audio_debug = 1 should deliver the
> related mute ioctl prints.
>   
I see -- it may be a couple of weeks before I can run tests on a more 
recent kernel, but I'll do that if turning off audiomute doesn't solve 
the problem.

Cheers,
Dave