I cloned this bug, because the original one was nearly a year old and I have not the rights to reopen it. +++ This bug was initially created as a clone of Bug #6709 +++ With several Logitech Webcam models there is a regular distortion (clicking noise) in the recorded audio. The kernel module that is used by those webcams is the "snd_usb_audio" audio module. I'm running openSUSE 10.3 (x86_64) with kernel 2.6.22.9, the kernel is compiled with CONFIG_SND_DEBUG=y and as soon as I start recording audio, I see many of those messages in the dmesg output: ALSA sound/usb/usbaudio.c:352: frame 0 active: -18 ALSA sound/usb/usbaudio.c:670: cannot submit urb (err = -45) I have a suspicion what might be the reason for this clicking noise. When I tried to grab video from my webcam with 'ffmpeg', 'ffmpeg' always aborted after a few seconds because it received incomplete/erroneous video frames. Laurant Pinchard, the developer of the uvcvideo driver explained it as following: > The USB isochronous transfers are not error free. Packets can be lost, > which results in incomplete/erroneous frames. > The driver currently handles complete and incomplete frames the same way. > I can add a driver option to make it drop incomplete frames, returning < complete frames only to the application. Could it be, that the same happens with the audio frames sent by the webcam? I noticed that, when I try to record audio using 'sox' from '/dev/dsp2', 'sox' also aborts after recording for a few seconds (like 'ffmpeg' aborted after few seconds when an incomplete video frame was received). If I record from the webcam microphone via 'arecord', I have the same clicking noise in the recorded audio, but unlike 'sox', 'arecord' doesnt abort recording. Could it be, that those clicking sounds in the recorded audio are incomplete audio frames? So if the isochronous USB transfer is not perfect for the video data, it is self-evident that the same applies to the audio data transfer!? Well, this is just the best assumption I currently have what could be the reason for the clicking noise. Maybe it helps to analyze this bug. Sample recordings of what the distortions sound like can be found here: http://forums.quickcamteam.net/showthread.php?tid=6
The error code -18 means that the computer was not able to send data to the device when there was a packet scheduled to be sent. It is probable that some other module disabled interrupts for too long. Please show all modules that are loaded (the output of "lsmod").
# lsmod Module Size Used by usblp 30976 0 nfsd 271576 13 exportfs 22656 1 nfsd uvcvideo 66692 1 compat_ioctl32 25472 1 uvcvideo videodev 44416 2 uvcvideo v4l1_compat 28676 2 uvcvideo,videodev v4l2_common 36480 3 uvcvideo,compat_ioctl32,videodev nls_iso8859_1 21888 0 nls_cp437 23680 0 vfat 30336 0 fat 70704 1 vfat ipt_MASQUERADE 20480 1 xt_TCPMSS 21760 1 ppp_deflate 22912 0 zlib_deflate 36488 1 ppp_deflate bsd_comp 22528 0 ppp_async 28800 0 crc_ccitt 18944 1 ppp_async ppp_generic 45984 3 ppp_deflate,bsd_comp,ppp_async slhc 22784 1 ppp_generic bnep 50176 2 xt_tcpudp 20096 42 xt_pkttype 18688 6 ipt_LOG 23040 30 xt_limit 19840 30 snd_pcm_oss 67456 1 snd_mixer_oss 34176 1 snd_pcm_oss snd_seq_midi 27136 0 snd_emu10k1_synth 25088 0 snd_emux_synth 54400 1 snd_emu10k1_synth snd_seq_virmidi 24320 1 snd_emux_synth snd_seq_midi_event 24576 2 snd_seq_midi,snd_seq_virmidi snd_seq_midi_emul 23552 1 snd_emux_synth snd_seq 74992 5 snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_event,snd_seq_midi_emul nfs 266552 1 lockd 84816 3 nfsd,nfs nfs_acl 20352 2 nfsd,nfs sunrpc 198600 13 nfsd,nfs,lockd,nfs_acl af_packet 57100 2 ipt_REJECT 21504 3 xt_state 19328 23 iptable_mangle 19712 0 iptable_nat 24580 1 nf_nat 37420 2 ipt_MASQUERADE,iptable_nat iptable_filter 19840 1 nf_conntrack_ipv4 28816 25 iptable_nat nf_conntrack 84188 5 ipt_MASQUERADE,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4 nfnetlink 23224 3 nf_nat,nf_conntrack_ipv4,nf_conntrack ip_tables 37848 3 iptable_mangle,iptable_nat,iptable_filter ip6_tables 31944 0 x_tables 37000 11 ipt_MASQUERADE,xt_TCPMSS,xt_tcpudp,xt_pkttype,ipt_LOG,xt_limit,ipt_REJECT,xt_state,iptable_nat,ip_tables,ip6_tables cpufreq_conservative 24968 0 cpufreq_userspace 23680 0 cpufreq_powersave 18560 0 powernow_k8 31504 0 apparmor 58672 0 aes_x86_64 42280 1 cbc 21376 1 blkcipher 23044 1 cbc ohci_hcd 38020 0 dm_crypt 30480 1 xfs 507560 2 loop 36356 0 dm_mod 77152 3 dm_crypt rfcomm 73896 5 l2cap 57344 13 bnep,rfcomm usbhid 58160 0 hid 43776 1 usbhid ff_memless 22536 1 usbhid snd_via82xx 47528 1 usb_storage 102816 0 snd_usb_audio 109952 1 snd_via82xx_modem 33420 0 k8temp 22656 0 rtc_cmos 25016 0 i2c_viapro 26008 0 fglrx 1747484 0 i2c_core 43648 1 i2c_viapro hwmon 20232 1 k8temp button 26400 0 ide_core 165648 1 usb_storage emu10k1_gp 20864 0 snd_emu10k1 159632 4 snd_emu10k1_synth firmware_class 27520 1 snd_emu10k1 snd_ac97_codec 130248 3 snd_via82xx,snd_via82xx_modem,snd_emu10k1 ac97_bus 19328 1 snd_ac97_codec rtc_core 38156 1 rtc_cmos snd_pcm 108680 6 snd_pcm_oss,snd_via82xx,snd_usb_audio,snd_via82xx_modem,snd_emu10k1,snd_ac97_codec rtc_lib 19968 1 rtc_core gameport 32656 3 snd_via82xx,emu10k1_gp ohci1394 51272 0 ieee1394 115800 1 ohci1394 skge 58768 0 shpchp 50716 0 snd_timer 42632 3 snd_seq,snd_emu10k1,snd_pcm pci_hotplug 49396 1 shpchp hci_usb 35100 2 floppy 79624 0 snd_util_mem 22272 2 snd_emux_synth,snd_emu10k1 serio_raw 24068 0 snd_usb_lib 34688 1 snd_usb_audio snd_hwdep 27528 3 snd_emux_synth,snd_usb_audio,snd_emu10k1 sr_mod 33444 0 cdrom 52392 1 sr_mod snd_mpu401_uart 25984 1 snd_via82xx snd_rawmidi 44544 5 snd_seq_midi,snd_seq_virmidi,snd_emu10k1,snd_usb_lib,snd_mpu401_uart snd_seq_device 25620 6 snd_seq_midi,snd_emu10k1_synth,snd_emux_synth,snd_seq,snd_emu10k1,snd_rawmidi snd 84984 29 snd_pcm_oss,snd_mixer_oss,snd_seq_midi,snd_emu10k1_synth,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq,snd_via82xx,snd_usb_audio,snd_via82xx_modem,snd_emu10k1,snd_ac97_codec,snd_pcm,snd_timer,snd_util_mem,snd_usb_lib,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 25360 2 snd snd_page_alloc 28048 4 snd_via82xx,snd_via82xx_modem,snd_emu10k1,snd_pcm bluetooth 89092 8 bnep,rfcomm,l2cap,hci_usb sg 53304 0 ehci_hcd 50572 0 sd_mod 45824 6 uhci_hcd 42144 0 usbcore 155816 11 usblp,uvcvideo,ohci_hcd,usbhid,usb_storage,snd_usb_audio,hci_usb,snd_usb_lib,ehci_hcd,uhci_hcd edd 26760 0 ext3 156688 1 mbcache 26248 1 ext3 jbd 89192 1 ext3 fan 22792 0 pata_via 30212 4 sata_via 29700 0 libata 164224 2 pata_via,sata_via scsi_mod 176536 5 usb_storage,sr_mod,sg,sd_mod,libata thermal 34576 0 processor 59720 2 powernow_k8,thermal
Try without the fglrx module, or try to disable all 3D acceleration.
No, this didn't fix the problem. Fglrx can't be the problem, because I tested the webcam with 4 different systems and two of the have a Nvidia card. I experience the cracking noise on all 4 systems.
OK, it seems to be certain now, that those clicking noise is caused by a hardware bug of the SPCA525 chipset which is used by some Logitech webcams. Martin Rubli from Logitech explained it in this thread: http://forums.quickcamteam.net/showthread.php?tid=6 > Here's some additional information on the older cameras for which the problem > was initially reported. With some of the models based on the SPCA525 chipset > there is indeed a known issue that can cause clicks under certain > circumstances. Apparently it's something timing related, so it's hard to > predict when it occurs but Linux seems to trigger it much more often than > Windows. > Therefore, on Windows there is a pop/click audio filter installed with some > camera models that fixes the problem before it reaches the applications. > That's why you can't hear it on Windows. So the question is, would it be possible to implement a similar filter in the ALSA usb audio module, which is only activated for devices with a certain USB ID?
It would indeed be possible to implement such a filter, but the proper place to do this would be a userspace plugin that gets automatically activated by alsa-lib. You only have to find someone to do this.