Steps to reproduce: 0. If you have any sound applications running, quit them. 1. Open a pulseaudio application. Most modern linux music players will suffice, like mplayer or rhythmbox. Play something loud. 2. Use pavucontrol to lower the volume of the application (not the card!) at low but hearable one. Assert yourself the card volume is set at maximum in pavucontrol. 3. Launch an alsa application, i.e. mplayer -ao alsa. 4. Quit it. You may hear a glitch for a fraction of second. I suspect this glitch comes from pulseaudio playing a piece of the sound buffer at maximum volume, regardless of which volume has the application set. This is less noticeable the higher the volume of the pulseaudio application is. This is very annoying with IM clients like gajim and Psi+, which play message notification sounds with alsa. Ugly workaround (and hint): If you run an alsa application and let it running, appearing at pavucontrol, but without playing anything (i.e. run mplayer -ao alsa, and let it paused), no glitch will be heard, since it only happens when *all* alsa applications have quit.
OS: ArchLinux Card: snd_hda_intel
This sounds a lot like the hardware-software volume synchronization problem that is associated with the "flat volume" feature. Can you reproduce the problem if you replace the alsa application with "pacat /dev/zero"? That command plays silence, so ideally you would notice nothing changing in the audio, but I'd expect you to hear some glitches either when starting playing the silence or when stopping it (with ctrl-c). Does the problem go away if you put "flat-volumes = no" in ~/.pulse/daemon.conf and restart pulseaudio?
You're right. The issue is reproducible with pacat /dev/zero, glitching both at start and end (previously, with alsa, I hadn't noticed the glitch at start, but there is too). Setting "flat-volumes = no" made the problem go away. So, what's wrong?
The flat volume feature causes Pulseaudio to apply hardware volume also to stream volumes when possible. This requires that software volume and hardware volume changes happen synchronously. There's no reliable way to achieve that, but Pulseaudio tries its best. It varies across hardware how well it works (it works quite well for me). If you don't mind disabling the flat volumes, then that's the easiest solution to your problem. If you want to use flat volumes, there is a way to tune the timing of the volume changes. In daemon.conf, you can set options "deferred-volume-safety-margin-usec" (default: 8000) and "deferred-volume-extra-delay-usec" (default: 0), which affect the timing of the hardware volume changes. The target is to never have a situation where the hardware volume goes up before the software volume changes or where the hardware volume goes down after the software volume changes, because in these cases there will be an annoying volume spike. Having error to the other direction (having a period where the volume is too low) is not so annoying, but it's still an error, so it's a secondary target to minimize the delay between the hardware and software volume changes. The delay between the two different volume changes varies to some extent, and this variance is compensated with the safety margin parameter. If you get volume spikes both when starting and stopping "pacat /dev/zero", then you need to increase the safety margin. If you get volume spikes only when starting pacat, then the hardware volume changes are happening too early, which you can fix by decreasing the extra delay parameter. If you get volume spikes only when stopping pacat, then the hardware volume changes are happening too late, which you can fix by increasing the extra delay parameter. I'm resolving this bug as wontfix, since there's no way to automatically make the synchronization perfect with all hardware.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.