After a day or so of heavy usage (KDE with full effects, portupgrade in background, playing music using XMMS with artsd in background using virtual channels), audible skips, clicks and lag tend to occur with the output audio. I have also had this problem with FreeBSD 6.1. Some information that might be useful: hw.snd.maxautovchans: 255 hw.snd.pcm0.vchans: 1 pcm0@pci3:11:0: class=0x040100 card=0x10021102 chip=0x00041102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'SoundBlaster Audigy Audigy Audio Processor' class = multimedia subclass = audio emujoy0@pci3:11:1: class=0x098000 card=0x00601102 chip=0x70031102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10K2 Audigy Gameport' class = input device fwohci1@pci3:11:2: class=0x0c0010 card=0x00101102 chip=0x40011102 rev=0x04 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10K2 Audigy IEEE1394 Firewire Controller' class = serial bus subclass = FireWire Fix: A workaround is to restart the computer. Reloading the sound card module as follows does not fix the problem: kldunload snd_emu10k1 kldunload sound kldload snd_emu10k1 I'm thinking it might be kernel related. Perhaps something to do with scheduling and preemption. This problem does not ever occur in Windows XP Professional. How-To-Repeat: This problem is repeatable but I can't give any better instructions on how to reproduce the problem at the moment except what was provided in the description.
Responsible Changed From-To: freebsd-bugs->freebsd-multimedia Assign to the Multimedia team.
It happens for me rarely with OGG/MP3 files with XMMS, and pausing-unpausing seems to "refresh" the sound buffer with good data. But when it comes to WAV files, specially short ones and/or with different samplings (22 kHz, 11 kHz, ...) and/or word type (8/16 bits, signed/unsigned), I can rarely get a _correct_ playback, often clicking and truncated (near the end of file) sound, and also happens in a random fashion (sometimes clip, others distort, others truncate, or any combination). Anytime, by the way. Repeatable both with emu10k1 and emu10kx (from ports) drivers, using "play" command (audio/sox), and either with the 4 KB buffer or larger. Relevant info: pcib1@pci0:1:0: class=0x060400 card=0x00000080 chip=0xb1981106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'ProSavageDDR P4X600 CPU to AGP Bridge' class = bridge subclass = PCI-PCI pcm0@pci0:10:0: class=0x040100 card=0x80611102 chip=0x00021102 rev=0x07 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10000 Sound Blaster Live! (Also Live! 5.1) - OEM from DELL - CT4780' class = multimedia subclass = audio emujoy0@pci0:10:1: class=0x098000 card=0x00201102 chip=0x70021102 rev=0x07 hdr=0x00 vendor = 'Creative Labs' device = 'EMU10000 Game Port' class = input device isab0@pci0:17:0: class=0x060100 card=0x80ed1043 chip=0x32271106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237 PCI-to-ISA Bridge' class = bridge subclass = PCI-ISA # sysctl -a | grep snd hw.snd.report_soft_formats: 1 hw.snd.targetirqrate: 32 hw.snd.verbose: 1 hw.snd.maxautovchans: 0 hw.snd.unit: 0 hw.snd.pcm0.buffersize: 4096 hw.snd.pcm0.vchans: 0 dmesg: pcm0: <Creative EMU10K1> port 0xd800-0xd81f at device 10.0 on pci0 pcm0: <SigmaTel STAC9708/11 AC97 Codec> interrupts: # vmstat -i interrupt total rate irq1: atkbd0 110012 1 irq6: fdc0 10 0 irq12: psm0 1167054 11 irq14: ata0 882550 8 irq15: ata1 18 0 irq16: nvidia0+ 14367427 136 irq21: uhci0 uhci* 208925 1 irq23: vr0 500321 4 cpu0: timer 210239163 1999 Total 227475480 2163 # uname -a FreeBSD sauron.lan.box 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Regards. -- Ricardo Nabinger Sanchez <rnsanchez@{gmail.com,wait4.org}> Powered by FreeBSD "Left to themselves, things tend to go from bad to worse."
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Thanks for taking the time to submit this bug for the issue you encountered, and we apologize that it was not addressed in a timely fashion. The FreeBSD sound subsystem has had a large number of bug fixes and improvements over the last year or two, and this issue may be fixed. In the absence of feedback confirming this is still a problem on contemporary FreeBSD versions we are closing this issue. Please open a new bug if this issue is reproducible on a supported FreeBSD release.