Description of problem: When enabling sound notifications through the GNOME Sound Preferences dialog, and also generally when sound is heard intermittently (i.e. - not a continuous video or music playing), the sound server seems to close the audio hardware every time the audio stops, and resets the hardware before playing each new sounds. This causes two annoying effects (at least on my hardware - standard HDA intel chipset): * When audio just starts there is a noticeable delay before the sound plays - this is very noticeable when the audio is a simple audio notification (for example when enabling audio notifications on buttons and menus). * Everytime the hardware is being reset, an audible popping sound is heard on the speakers. With previous Fedora versions this used to happen only when the session starts and was negligible but in Fedora 11 (with sound notifications enabled and while no other audio is playing) this popping artifact can be heard several times a minute. I'm not sure if this is the fault of pulseaudio or some other component, but I chose pulseaudio because I know its the sound server for GNOME. Version-Release number of selected component (if applicable): pulseaudio-0.9.15-0.test2.fc11.x86_64 How reproducible: Always Steps to Reproduce: 1. In Fedora 11 alpha, enable sound notifications on buttons in the GNOME sound preferences dialog. 2. Make sure volume is set correctly, but don't play any continuous audio stream. 3. Work slowly through some dialogs and menus - make sure to pause a few seconds between each click. Actual results: On some hardware the opening and closing of the audio hardware can be experienced as loud pops are heard from the speakers when the hardware is being reset. Also there sometime a noticeable latency between the mouse interaction and the sound produced, when the hardware has to be reset before playing the sound.
Created attachment 333144 [details] strace of pulseaudio daemon Attached is an strace of the pulseaudio daemon during which an idle desktop was trying to invoke a single sound notification. At the top of the strace the pulseaudio daemon can be seen initting the audio hardware, and at the bottom of the trace you can see it closing the audio hardware ( close(57) and close(62) ). This whole process is executed each time a single beep is sent from the desktop - looks a bit sub-optimal to me. Also, on my hardware (I've just started to notice) the closing of the sound card also triggers a "pop artifact" although it is shorter and less loud.
I've managed to work around the problem by commenting out 'load-module module-suspend-on-idle' in the .pa files on /etc/pulse, but this was the same configuration as in Fedora 10 which didn't have that problem so I'm pretty sure this isn't the right course of action. I'd be happy to provide any additional information required for resolving this issue, or run any tests on my system. I'm going to try to install Fedora 11 alpha on a few different computers to see if I can reproduce this on other types of hardware.
We close the audio device when idle because that is the best way to save power. Opening a device is very fast. If opening a device causes hearable clicking this is considered a driver bug. Please file a seperate bug about this against alsa/kernel.
Thanks for the response. I'd like to comment that there *is* a noticeable delay when opening the sound device - with sound notifications for buttons enabled, one would expect the sound to be heard as soon as button is clicked, but if pulseaudio has to open the device before it can play - then at least on my (granted, not that new) machine there is a lag of maybe even a second at times. Its very noticeable. Secondly, lets assume that both the opening delay and the audible clicking during device opening can both be fixed on the driver side. How likely is this fix to be released in time for Fedora 11? In the mean time, Fedora 11 will be left with a very poor user experience in regards for audio. I've tested this with a couple of more (and newer) machines, both with intel ICH9 the same as mine, and they both exhibit the audible device initialization and (to a lesser degree) the sound latency. Intel's integrated audio devices are *very* common, it would be a shame if most users would experience this easy to fix issue. Please reconsider opening this bug report.
If this really takes 1s for you then something is very very broken for your driver. Please file a bug against the driver. PA has been closing audio devices as idle since about the beginning of time. Thus this certainly is no regression for F11 in PA. If it is a regression then certainly in the drivers, not in PA. Please file a bug against the ALSA drivers, thank you.
I've opened a bug with ALSA ( https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4441 ) though I'm still not sure what could cause this regression: are you suggesting that ALSA's support for intel HDA codec has gotten much worse in the last point release (from F10's 1.0.18rc3 to F11 1.0.19)?