[pulseaudio-discuss] Regarding latency of pulseaudio

[Sean Greenslade]

Hello, Thomas.

> What is the latency and configured latency that is being displayed in
> pulseaudio via pactl list sinks?

Configured latency is the target latency that PulseAudio is attempting
to achieve, while the plain latency value is the actual value that pulse
believes it is achieving at the current moment. This can vary due to
timer / scheduling jitter, hardware clock drift, interrupt delays, etc.
 
> It is observed that these parameters value is less in pulseaudio version 9 and
> more in pulseaudio version 15 for module-alsa-sink,
> 
> checked while playing same stream using paplay.
> 
> 
> Example:  version 9 -  Latency: 22429 usec, configured 23219 usec
> 
>                   version 15 - Latency: 79711 usec, configured 92879 usec

I took a quick glance through the changelogs for versons 10 through 15,
but I didn't see anything indicating a change in latency behavior.
Perhaps your config changed, or maybe your distro changed a default. For
example, tsched being enabled or disabled could have an effect on the
target latency.

> It's observed that values are too high in pulseaudio 15 version.

Are you experiencing an actual issue here? Pulse tries to keep larger
buffers in order to prevent underflows and reduce the amount of CPU time
used to process audio data. Pulse makes use of buffer rewinding to
prevent buffer latency from causing noticable delays in things like
volume control changes.

If you really need lower latency, pulseaudio provides some config
options to use smaller buffers. There are also other options to prevent
buffer expansion in the case of underruns, in case you would prefer to
have audio crackles rather than higher latency.

> is this the actual latency introduced by the module-alsa-sink? or overall
> pulseaudio ?

Some portion of the latency is dictated by the configuration parameters
of the alsa interface (e.g. the fragment size) and some is dictated by
the chosen pulseaudio buffer size. Other elements along the line (e.g.
resamplers) can introduce additional latency.

> Is there a way to measure the latency introduced by pulseaudio in a file
> playback?

Pulseaudio reports the latency values through its application interface.
This allows applications like mplayer to know the latency of the audio
pipeline and adjust the video playback to sync with the audio.

To view the current latency numbers of an application, use
"pactl list sink-inputs". This gives you both the unavoidable sink
latency, as well as the buffer latency due to the buffer size chosen by
the playback application. See the following for an example with mplayer,
where the sink provides ~26 ms of latency, while the mplayer buffers an
additional ~500 ms of audio. This makes sense for local file playback,
since decoding can look far ahead and do larger batches at a time.

> $ pactl list sink-inputs
> Sink Input #44
> 	Driver: protocol-native.c
> 	<SNIP>
> 	Buffer Latency: 449892 usec
> 	Sink Latency: 26475 usec
> 	Resample method: speex-float-1
> 	Properties:
> 		media.name = "ALSA Playback"
> 		application.name = "ALSA plug-in [mplayer]"
> 		...

--Sean