Re: Audio drop on saa7134
Hi David, Am Montag, den 21.09.2009, 00:53 -0700 schrieb David Liontooth: 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 lionte...@cogweb.net escreveu: Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb This means mute. With this, audio will stop. Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10 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? no, you can't use a saa7134 on System-M without additional audio decoder. You should know better, since you helped a lot to get Closed Captions working on saa7133/35/31e. 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? Yes, of course, but a saa7134 can't. Only the saa7135 and saa7131e chips can do global stereo audio on that driver. If vice versa for the saa7134, does that mean this chip is not able to decode stereo on NTSC? Yes. Sorry, I don't know what SYSTEM-M is in this context. You will find NTSC tuners also in South America. For video they use some PAL, but for audio System-M. A different example you can find in South Korea. For video they use NTSC, but for audio dual FM (A2). 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 Is it really still over the air? We don't have any such anymore, only cable TV from satellites back modulated as RF input into their network in best case. Is very stable. We are not alone and depend also of work done by others. Generally speaking, your stuff should be sufficient already, but without having NTSC here, hm maybe some AFN stuff is still active, you are somewhat on your own again. To back up your kernel's modules media folder, install recent stuff for some testing, and if not pleased, delete the recent media folder, copy the old media folder back into place and run depmod -a once should be not that hard. Lots of small bugs in between ;) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio drop on saa7134
Mauro Carvalho Chehab wrote: Em Sun, 20 Sep 2009 01:24:12 -0700 David Liontooth lionte...@cogweb.net escreveu: Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb This means mute. With this, audio will stop. Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10 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. Ah, great -- I added v4lctl -c /dev/video$DEV setattr automute off to the script and verified it works. Is there a way to turn off the automute on module insertion? I don't see a lot of difference -- during the initialization, audio is still turned off several times, and then left on: Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: tvaudio thread scan start [8] Sep 21 00:25:19 prato kernel: saa7133[4]/audio: scanning: M Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 0xc0 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 0x101010 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:25:19 prato kernel: saa7133[4]/audio: tvaudio thread scan start [9] Sep 21 00:25:19 prato kernel: saa7133[4]/audio: scanning: M Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 0xc0 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 0x101010 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10 Sep 21 00:25:22 prato kernel: saa7133[4]/audio: tvaudio thread status: 0x13 [M (in progress)] Sep 21 00:25:22 prato kernel: saa7133[4]/audio: detailed status: # init done And then audio is turned off again at the end of the recording: Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb I'll run with audiomute off for a while and see if it makes a difference for the audio drops -- it seems a plausible cause. Are you using the last version of the driver? I'm not seeing some debug log messages that should be there... I'm still running 2.6.19.1 and 2.6.20.11 on these production machines -- if it works, don't fix it. If there's a clear reason to upgrade, of course I'll do that. It would be a huge relief to discover the audio drops is a driver issue that can be fixed with a simple setting. Cheers, Dave -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio drop on saa7134
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 lionte...@cogweb.net escreveu: Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb This means mute. With this, audio will stop. Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio drop on saa7134
Hi Hermann -- I ran in debug mode; results below -- and let me correct a mistake: these are 7134 cards, not 7135. I tried some low-profile 7135 cards, but got a far higher rate of audio drops and stopped using them. David Liontooth wrote: hermann pitton wrote: Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth: hermann pitton wrote: Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: snip We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann OK, I'll try running with audio_debug=1. Could you clarify what you mean by The kernel audio detection thread must have been started without success or id find the right thing again? An audio drop can be initiated at any point in the recording. A weak signal is a good guess, but I've never noticed a correlation with video quality. You said audio sometimes recovers, than the kernel thread did detect it again, else failed on the pilots. I didn't know about audio_ddep -- what does it do? I'm not seeing it in modinfo. Oh, are you sure? My mistake -- I'm running 2.6.19 and it's there. It would be fantastic to get this problem solved -- we've had to record everything in parallel to avoid loss, and still very occasionally lose sound. It could also be something else, but that is the point to start. It stops the kernel audio detection thread and tells him to believe that only the norm given by insmod should be assumed. It is some hex in saa7134-audio, don't know it off hand for NTSC. Wait, i'll look it up. 0x40. Thank you! I'll try turning off the audio detection thread first, and then run debug. options saa7134 card=95,95,95,95 tuner=39,39,39,39 audio_ddep=0x40,0x40,0x40,0x40 # audio_debug=9,9,9,9 It's a production system so I may need to wait until the weekend. Cheers, Dave I added the audio_ddep value and it appears to have no effect; audio drops continued at the previous rate on two machines. I removed the audio_ddep parameter and added audio_debug=9: saa7133[4]: found at :02:03.0, rev: 16, irq: 16, latency: 64, mmio: 0xff2ff800 saa7133[4]: subsystem: 5169:0138, board: LifeView FlyVIDEO3000 [card=2,insmod option] saa7133[4]: board init: gpio is 39900 saa7133[4]: there are different flyvideo cards with different tuners saa7133[4]: out there, you might have to use the tuner=nr insmod saa7133[4]: option to override the default value. tuner 4-0061: chip found @ 0xc2 (saa7133[4]) tuner 4-0061: type set to 39 (LG NTSC (newer TAPC series)) tuner 4-0061: type set to 39 (LG NTSC (newer TAPC series)) tuner 4-0063: chip found @ 0xc6 (saa7133[4]) saa7133[4]: i2c eeprom 00: 69 51 38 01 ff 28 ff ff ff ff ff ff ff ff ff ff saa7133[4]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[4]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[4]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[4]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[4]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[4]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[4]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[4]/audio: dsp write reg 0x464 = 0x00 saa7133[4]/audio: dsp write reg 0x46c = 0xbb saa7133[4]/audio: dsp write reg 0x464 = 0x00 saa7133[4]/audio: dsp write reg 0x46c = 0xbb saa7133[4]/audio: dsp write reg 0x474 = 0x00 saa7133[4]/audio: dsp write reg 0x450 = 0x00 saa7133[4]/audio: tvaudio thread scan start [1] saa7133[4]/audio: scanning: B/G D/K I saa7133[4]/audio: dsp write reg 0x454 = 0x00 saa7133[4]/audio: dsp write reg 0x454 = 0xac saa7133[4]/audio: dsp write reg 0x464 = 0x00 saa7133[4]/audio: dsp write reg 0x470 = 0x101010 saa7133[4]: registered device video2 [v4l2] saa7133[4]: registered device vbi2
Re: Audio drop on saa7134
Em Sun, 20 Sep 2009 01:24:12 -0700 David Liontooth lionte...@cogweb.net escreveu: Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb This means mute. With this, audio will stop. Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio drop on saa7134
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 lionte...@cogweb.net escreveu: Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb This means mute. With this, audio will stop. Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00 Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10 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. 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. The automute is for convenience of the users, say not to have loud noise on channel switching. It is also controlled by different registers for analog sound and 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. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio drop on saa7134
hermann pitton wrote: Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth: hermann pitton wrote: Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: snip We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann OK, I'll try running with audio_debug=1. Could you clarify what you mean by The kernel audio detection thread must have been started without success or id find the right thing again? An audio drop can be initiated at any point in the recording. A weak signal is a good guess, but I've never noticed a correlation with video quality. You said audio sometimes recovers, than the kernel thread did detect it again, else failed on the pilots. I didn't know about audio_ddep -- what does it do? I'm not seeing it in modinfo. Oh, are you sure? My mistake -- I'm running 2.6.19 and it's there. It would be fantastic to get this problem solved -- we've had to record everything in parallel to avoid loss, and still very occasionally lose sound. It could also be something else, but that is the point to start. It stops the kernel audio detection thread and tells him to believe that only the norm given by insmod should be assumed. It is some hex in saa7134-audio, don't know it off hand for NTSC. Wait, i'll look it up. 0x40. Thank you! I'll try turning off the audio detection thread first, and then run debug. options saa7134 card=95,95,95,95 tuner=39,39,39,39 audio_ddep=0x40,0x40,0x40,0x40 # audio_debug=9,9,9,9 It's a production system so I may need to wait until the weekend. Cheers, Dave -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Audio drop on saa7134
hermann pitton wrote: Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: snip We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann OK, I'll try running with audio_debug=1. Could you clarify what you mean by The kernel audio detection thread must have been started without success or id find the right thing again? An audio drop can be initiated at any point in the recording. A weak signal is a good guess, but I've never noticed a correlation with video quality. I didn't know about audio_ddep -- what does it do? I'm not seeing it in modinfo. It would be fantastic to get this problem solved -- we've had to record everything in parallel to avoid loss, and still very occasionally lose sound. Cheers, Dave -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Audio drop on saa7134
Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth: hermann pitton wrote: Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth: snip We've been using saa7135 cards for several years with relatively few incidents, but they occasionally drop audio. I've been unable to find any pattern in the audio drops, so I haven't reported it -- I have no way to reproduce the error, but it happens regularly, affecting between 3 and 5% of recordings. Audio will sometimes drop in the middle of a recording and then resume, or else work fine on the next recording. Hi Dave, hmm, losing audio on three to five percent of the recordings is a lot! When we started to talk to each other, we had only saa7134 PAL/SECAM devices over here. That has changed a lot, but still no System-M here. The kernel thread detecting audio on saa7133/35/31e behaves different from the one on saa7134. But if you let it run with audio_debug=1, you should have something in the logs when losing the audio. The kernel audio detection thread must have been started without success or id find the right thing again. I would assume caused by a weaker signal in between. Do you know about the insmod option audio_ddep? It is pretty hidden and I almost must look it up myself in the code. Cheers, Hermann OK, I'll try running with audio_debug=1. Could you clarify what you mean by The kernel audio detection thread must have been started without success or id find the right thing again? An audio drop can be initiated at any point in the recording. A weak signal is a good guess, but I've never noticed a correlation with video quality. You said audio sometimes recovers, than the kernel thread did detect it again, else failed on the pilots. I didn't know about audio_ddep -- what does it do? I'm not seeing it in modinfo. Oh, are you sure? depends: videobuf-core,videobuf-dma-sg,ir-common,i2c-core,videodev,tveeprom,v4l2-common vermagic: 2.6.30.1 SMP preempt mod_unload parm: disable_ir:disable infrared remote support (int) parm: ir_debug:enable debug messages [IR] (int) parm: pinnacle_remote:Specify Pinnacle PCTV remote: 0=coloured, 1=grey (defaults to 0) (int) parm: ir_rc5_remote_gap:int parm: ir_rc5_key_timeout:int parm: repeat_delay:delay before key repeat started (int) parm: repeat_period:repeat period between keypresses when key is down (int) parm: disable_other_ir:disable full codes of alternative remotes from other manufacturers (int) parm: video_debug:enable debug messages [video] (int) parm: gbuffers:number of capture buffers, range 2-32 (int) parm: noninterlaced:capture non interlaced video (int) parm: secam:force SECAM variant, either DK,L or Lc (string) parm: vbi_debug:enable debug messages [vbi] (int) parm: vbibufs:number of vbi buffers, range 2-32 (int) parm: audio_debug:enable debug messages [tv audio] (int) parm: audio_ddep:audio ddep overwrite (int) ^ parm: audio_clock_override:int parm: audio_clock_tweak:Audio clock tick fine tuning for cards with audio crystal that's slightly off (range [-1024 .. 1024]) (int) parm: ts_debug:enable debug messages [ts] (int) parm: tsbufs:number of ts buffers for read/write IO, range 2-32 (int) parm: ts_nr_packets:size of a ts buffers (in ts packets) (int) parm: i2c_debug:enable debug messages [i2c] (int) parm: i2c_scan:scan i2c bus at insmod time (int) parm: irq_debug:enable debug messages [IRQ handler] (int) parm: core_debug:enable debug messages [core] (int) parm: gpio_tracking:enable debug messages [gpio] (int) parm: alsa:enable/disable ALSA DMA sound [dmasound] (int) parm: latency:pci latency timer (int) parm: no_overlay:allow override overlay default (0 disables, 1 enables) [some VIA/SIS chipsets are known to have problem with overlay] (int) parm: video_nr:video device number (array of int) parm: vbi_nr:vbi device number (array of int) parm: radio_nr:radio device number (array of int) parm: tuner:tuner type (array of int) parm: card:card type (array of int) It would be fantastic to get this problem solved -- we've had to record everything in parallel to avoid loss, and still very occasionally lose sound. It could also be something else, but that is the point to start. It stops the kernel audio detection thread and tells him to believe that only the norm given by insmod should be assumed. It is some hex in saa7134-audio, don't know it off hand for NTSC. Wait, i'll look it up. 0x40. Good Luck, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the
