https://bugs.freedesktop.org/show_bug.cgi?id=58313
Tanu Kaskinen <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Tanu Kaskinen <[email protected]> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.
_______________________________________________ pulseaudio-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs
