[pulseaudio-discuss] Notable delay when changing volume

[Tanu Kaskinen]

On Sun, 2014-12-28 at 23:51 +0100, Mark Gaiser wrote:
> Hi Tanu,
> 
> 
> I just read this [1] bug report from a couple years ago. While i'm not
> the author of the report (or the reporter), i do recognize the issue
> since i've been having that very same issue for years. Literally!
> 
> 
> So i went on investigating this issue a bit and am reporting my
> findings to you. I hope you can take it up further.

What do you mean by "take it up further"? Assuming that the root cause
for your observations is the same that is described in the bug report
that you mentioned, the only problem is to find someone who has time to
fix the bug. It doesn't really need any further investigation.

> First some specs:
> - Archlinux
> - KDE (4.13) environment
> - x64
> 
> 
> I'm - again :) - using mplayer as example application. It's set to
> output audio to pulseaudio via "ao = pulse". There are no further
> custom configurations in mplayer. Now when i just run mplayer on
> source that contains audio it plays just fine. When i change the
> volume it has a notable delay of about 0.6 seconds. It's not instant,
> but it certainly is within a second. But enough to be troubled by it.
> 
> 
> Next, in that very same bug report i read your message stating:
> ------------
> Having pavucontrol running causes pulseaudio to reduce the latency, so
> that pavucontrol's volume meters don't have too much delay.
> 
> ------------
> 
> 
> 
> I verified that this same behavior is visible on my system. I can
> change audio volume much smoother when pavucontrol is open. I'm
> obviously not going to open pavucontrol all the time just to have a
> smoother volume change experience. Therefore i'm wondering, why is
> there a latency difference at all? Can't the same latency that is
> being used when pavucontrol is open be the default latency?
> 
> 
> Why does there need to be a latency at all anyway?

Zero latency would mean that there wouldn't be any buffering before the
digital-to-analog converter (DAC) of the sound card. Whenever the DAC
would need to convert a sample to analog domain, it would have to ask
the CPU to give that sample. With 44100 Hz audio that would mean 44100
wakeups per second. Linux wouldn't be able to cope with that.

The more there is buffering, the less wakeups are needed to keep the
audio flowing, and that translates to less CPU use and better battery
life. As a general rule, we want to run at the biggest latency possible.

The reason why pavucontrol makes the latency smaller is that it shows
volume meters, and if the latency would be high, those meters would
noticeably lag behind what the user would hear from the speakers.

> In all fairness, i find it a bit weird that an application
> (pavucontrol) can influence how the latency of streams is managed. It
> sounds weird, butt hat might also be because i don't know pulseaudio
> internals.
> 
> 
> I hope i'm not terribly out of line by mailing you this question
> directly without sending it to the list or the bugreport (i'm not
> registered on either). If you prefer me to send it to (one of) those
> then i'd happily do that :)

The mailing list would indeed have been a better venue for the mail, so
let's continue there.

> [1] https://www.libreoffice.org/bugzilla/show_bug.cgi?id=48307

-- 
Tanu