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

[21naown at gmail.com]

Le 05/11/2017 à 10:54, Tanu Kaskinen a écrit :
> "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".
Noted.
> 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.
PulseAudio may have an overrun/underrun problem like jack/QjackCtl may 
also be concerned, right? So I will check more precisely for 
jack/QjackCtl (with their mailing list for example) if the visual 
indicator shows any drop-out problem and similar, because yes my audio 
configuration is “PulseAudio → jack/QjackCtl → Audacity”.
> On Fri, 2017-11-03 at 15:24 +0100, 21naown at gmail.com wrote:
>> 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.
>
I think I disabled the resampling (please tell me if it is not the 
case), in “/etc/pulse/daemon.conf” with:
enable-remixing = no
enable-lfe-remixing = no


I am nearly sure the resampling is disabled because the sources I played 
from VLC (with 100% volume in VLC and PulseAudio + the resampling of VLC 
disabled), when both values were to “yes”, did not match the original 
file (I check that with “Sample Data Export” of Audacity, with a bit of 
configuration to export the values from Audacity as bit-perfect). And 
when I put “no”, the values were the same, so it was bit-perfect. So I 
really think I disabled the resampling (I play only one source at the 
same time, so I do not need resampling for this case).

So maybe I am not concerned with “rewind” messages? I noted it anyway.

Are there other things similar to a drop-out in PulseAudio (if its 
resampling is disabled)?