[pulseaudio-discuss] How to check visually for XRUNs/drop-out/interruptions and similar in PulseAudio?

[Tanu Kaskinen]

On Fri, 2017-11-03 at 15:24 +0100, 21naown at gmail.com wrote:
> Le 03/11/2017 à 10:05, Tanu Kaskinen a écrit :
> > Drop-outs are logged, but you need to enable verbose logging.
> > PulseAudio generates a lot of logs in the verbose mode, I don't know if
> > you want all that in your syslog. It's possible to set the log target
> > to a file, though.
> > 
> 
> Super! I will change the target of the log file yes (I saw 
> “--log-target=file:PATH”).
> Do you know the error message or a keyword for the drop-outs to find 
> them in the logs?
> What is the “log-level” to show them? (if I am not wrong, “notice”, 
> which is “2”, is the default)

"Actual underrun of 'application name'" will be logged when a playback
application fails to provide data to PulseAudio fast enough. The log
level of this message is "debug".

The alsa sink will log "Underrun!" if PulseAudio doesn't write fast
enough to alsa, but if you're only using jack as the output in
PulseAudio, then that's irrelevant.

Other modules that maintain their own buffers may also have underrun or
overrun situations. I don't have a comprehensive list of them. I know
module-loopback logs "Could not peek into queue" when it has an
underrun in its buffer.

> You can confirm any problem similar to a drop-out (= which modifies the 
> value of the sound whereas it should not) is logged if it is the 
> PulseAudio’s fault?

If PulseAudio needs to resample a stream and a rewind (i.e. a jump
backwards in a buffer) happens in the render_memblockq of the stream,
that can cause a small glitch, because the resampler state is not reset
to what it was at the point where the rewind jumps to. Rewinds of
render_memblockq are logged using message "Have to rewind %lu bytes on
render memblockq.". That message doesn't mean that there was a glitch,
but if the stream is being resampled, then there probably was a glitch
(whether that's audible is a different matter, I have personally never
noticed anything).

If you're recording from a monitor source, then that's another thing
that can have glitches when rewinding, and those glitches are pretty
severe (extra data is added to the stream). There's some bug in the
monitor source rewinding code that I haven't located so far. When this
happens, "source.c: Processing rewind..." is logged.

-- 
Tanu

https://www.patreon.com/tanuk