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

[Tanu Kaskinen]

On Sun, 2017-11-05 at 19:23 +0100, 21naown at gmail.com wrote:
> Le 05/11/2017 à 10:54, Tanu Kaskinen a écrit :
> > 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?

Sorry, I don't understand this sentence.

> 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
> > 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

Resampling can't be disabled. If a stream uses different sample rate
than the sink where it plays to, then PulseAudio has to do resampling,
i.e. converting audio from one sample rate to another.

Remixing means adapting between different channel configurations when
the stream channels don't match with the sink channels. If remixing is
disabled, then channels that exist on the stream but not on the sink
are dropped, and channels that exist on the sink but not on the stream
get silence.

> 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)?

I already answered this question in my last mail as well as I can.

-- 
Tanu

https://www.patreon.com/tanuk