Description of problem: Pulseaudio freqently reports "module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers." With default settings these messages typically appear a few times per minute when playing music. With tsched=0, they often appear multiple times a second and quickly bloat up /var/log/messages (and keep rsyslog and the disk active). After adding a line in /etc/rsyslog.conf to filter out these messages, I tried running pulseaudio with tsched=0 again. Although the totem web-plugin was glitchy the first time I tried it, sound behaviour is generally good. There are occasional glitches but so far none of the unpredictable sound dropouts I sometimes get with default tsched=1 (especially noticeable with flash/youtube). Other driver-related symptoms: Grepping through /var/log/messages* for other PA-related messages, I see several examples of "alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 26560 bytes (150 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers." although values of 70-90ms are perhaps more frequent than values around 150ms. Version-Release number of selected component (if applicable): kernel-2.6.27.12-170.2.5.fc10.i686 alsa-lib-1.0.19-2.fc10.i386 pulseaudio-0.9.14-1.fc10.i386 $ lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:09.0 Network controller: Broadcom Corporation BCM4303 802.11b Wireless LAN Controller (rev 02) 00:0b.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24/30 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) Additional info: With tsched=1, flash causes pulseaudio to idle at around 16% CPU (on an old 1GHz athlon) when doing nothing, while with tsched=0 flash causes PA to idle at around 8%. From my understanding of timer-based scheduling, this is expected due to the cs46xx mis-behaviour (and flash mis-behaviour), but I wanted to note it anyway.
This is a driver bug, reassigning to kernel.
Things have got worse with Fedora 11. Music and video now have a constant "fluttering" sound (with any of phonon-xine, flash, vlc, xine, totem-gstreamer, mplayer). I tried tsched=0 to see if things would improve, but (although pulseaudio restarts without error) no sound can be played. Music appears to be stuck, e.g. in mplayer the elapsed track time stays at ?? and does not progress. "speakertest -D front" continues to play without problems.
Created attachment 353823 [details] Selected output from alsa-time-test I ran alsa-time-test following the instructions at http://pulseaudio.org/wiki/BrokenSoundDrivers and reached an assert within a second.
The current situation is intermittent distortion that lasts until PA idles out or it can be persuaded to disappear if I play with the volume control in pavucontrol until the distortion goes. Alsa time test still asserts very soon after starting. /var/log/messages frequently gets messages from PA. I can paste the results of pulseaudio -vvvvv if anyone thinks that might be useful.
I'm seeing the exact same problem, with an Asus A7V333 motherboard. Hardware info from "asla-info": !!Soundcards recognised by ALSA !!----------------------------- 0 [CS46xx ]: CS46xx - Sound Fusion CS46xx Sound Fusion CS46xx at 0xbe000000/0xbd800000, irq 17 !!PCI Soundcards installed in the system !!-------------------------------------- 00:0e.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24/30 [CrystalClear SoundFusion Audio Accelerator] (rev 01) !!Advanced information - PCI Vendor/Device/Susbsystem ID's !!-------------------------------------------------------- 00:0e.0 0401: 1013:6003 (rev 01) Subsystem: 5053:3357 I saw these problems after I upgraded the system from F9 to F11. I'm going to be replacing this system real soon with an Asus M4A785TD-V EVO motherboard, which has VIA VT1708S onboard audio, so I'm not going to care about this particular bug for much longer. But it's still pretty bad that audio that was working perfectly in F9 is majorly broken in F11. :(
The discussion at http://mailman.alsa-project.org/pipermail/alsa-devel/2009-September/021001.html is probably relevant. This alsa list message also indicates that the cs46xx driver is somehow unique: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-August/020376.html - I don't know enough to know whether this makes a real difference to PA though.
Created attachment 366128 [details] pulseaudio output from playing wav file with tsched=0 tsched=0 works again on F12 Beta, and appears to playback perfectly (although I've only tested with paplay and aplay). However the following messages appear in the 'pulseaudio -vvvv' output: E: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! E: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_cs46xx'. Please report this issue to the ALSA developers. E: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. See attached file for the full output.
I've filed bug #531066 about constant dropouts during playback with this sound card (tested with paplay and aplay). Hopefully it's better to have one bug report per set of symptoms.
*** Bug 531066 has been marked as a duplicate of this bug. ***
I am pretty sure this is a bug in the cs46xx driver in regards to the handling of snd_pcm_rewind() and the order hw buffer size negotiation. This mails sheds some light on this: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-August/020376.html Will know reassign to the kernel, since this really seems to be something that needs to be fixed in the kernel driver.
Oh dang, it was already assigned to the kernel... pfft
FWIW, in reply to https://bugzilla.redhat.com/show_bug.cgi?id=531066#c4 I played with the paplay --latency values and it seems like 8000 is about the most stable point I could find (which corresponds to about 4-5% cpu usage). More than this and there are noticeable dropouts. Less than this and audio doesn't last long before breaking up for a few seconds or spamming the sound card with noise until both paplay is killed and pulseaudio suspends on idle - I guess it can't cope with underruns with the smaller latencies? Is there something other than latency setting that makes pulseaudio more resilient when pavucontrol is active?
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #3) > Created an attachment (id=353823) [details] > Selected output from alsa-time-test > > I ran alsa-time-test following the instructions at > http://pulseaudio.org/wiki/BrokenSoundDrivers and reached an assert within a > second. can you rerun the test with tail -500 http://thread.gmane.org/gmane.linux.alsa.devel/60371/focus=60520
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
you have to ask PA developer why there is no data in queue , this is underrun D: protocol-native.c: Underrun on '/media/Oliver/TestDay/Nouveau/03 Delgados, The - American Trilogy.wav', 0 bytes in queue.
Still similar problems with F14 - both with the PA 0.9.21-6 and with the recently built 0.9.22 F15 packages. I'll try and follow up with more current logs if I can.
it is rather strange to use 8.6 fragments if cs46xx only allow specific period sizes ( seem to be power of two ) if the block transfer copy data from system memory to DSP's memory static unsigned int period_sizes[] = { 32, 64, 128, 256, 512, 1024, 2048 }; I: alsa-source.c: Using 8.6 fragments of size 2048 bytes (11.61ms), buffer size is 17632 bytes (99.95ms)
Does this still happen with the latest f14 (or preferable f15) kernels?
Yes, tested with the F15 kde livecd: kernel-2.6.38.6-26.rc1.fc15.i686 pulseaudio-0.9.22-5.fc15.i686 alsa-lib-1.0.24-2.fc15.i686 with the same results, ie: that playback is sometimes silent(*) and volume changes can cause rapid stuttering(**) regardless of tsched setting. With tsched enabled then playback is often broken up by fluttering(*). * can be cured by spamming the volume change up and down ** can be cured by further volume change or simply waiting for PA to timeout once playback finishes. I saw some recommended settings at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/428619/comments/96 but they don't appear to make any difference, except possibly making silent playback with tsched enabled more likely.
you have to post the log "pulseaudio -vvvvv" again using F15 since PA already limit the rewind to 256 bytes and this may be not sufficient for cs46xx which use 512 frames per period http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=4df443bbe682055a41e7c2248877dcc7682a69b8 report to alsa-developer mailing and pulseaudio mailing list D: alsa-util.c: Hardware PCM card 0 'Sound Fusion CS46xx' device 0 subdevice 0 D: alsa-util.c: Its setup is: D: alsa-util.c: stream : PLAYBACK D: alsa-util.c: access : MMAP_INTERLEAVED D: alsa-util.c: format : S16_LE D: alsa-util.c: subformat : STD D: alsa-util.c: channels : 2 D: alsa-util.c: rate : 44100 D: alsa-util.c: exact rate : 44100 (44100/1) D: alsa-util.c: msbits : 16 D: alsa-util.c: buffer_size : 4408 D: alsa-util.c: period_size : 512 D: alsa-util.c: period_time : 11609 D: alsa-util.c: tstamp_mode : ENABLE D: alsa-util.c: period_step : 1 D: alsa-util.c: avail_min : 512 D: alsa-util.c: period_event : 0 D: alsa-util.c: start_threshold : -1 D: alsa-util.c: stop_threshold : 1155530752 D: alsa-util.c: silence_threshold: 0 D: alsa-util.c: silence_size : 0 D: alsa-util.c: boundary : 1155530752 D: alsa-util.c: appl_ptr : 0 D: alsa-util.c: hw_ptr : 0
Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15. In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs.