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