[pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly

[Mikael Nousiainen]

On Sun, Nov 11, 2018, at 17:47, Mikael Nousiainen wrote:
> > Message: 2
> > Date: Sat, 10 Nov 2018 10:54:03 +0500
> > From: "Alexander E. Patrakov" <patrakov at gmail.com>
> > To: General PulseAudio Discussion
> > 	<pulseaudio-discuss at lists.freedesktop.org>
> > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives
> > 	distorted audio randomly
> > Message-ID:
> > 	<CAN_LGv15swrn8H-GRV9FOi4HnjpHG=jNNiS=2qenHp0HSsFWwQ at mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> > 
> > Mikael Nousiainen <mikaelnousiainen at fastmail.com>:
> > >
> > > On Thu, Nov 8, 2018, at 20:49, pulseaudio-discuss-request at lists.freedesktop.org wrote:
> > > > Message: 4
> > > > Date: Thu, 8 Nov 2018 21:31:52 +0500
> > > > From: "Alexander E. Patrakov" <patrakov at gmail.com>
> > > > To: General PulseAudio Discussion
> > > >       <pulseaudio-discuss at lists.freedesktop.org>
> > > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives
> > > >       distorted audio randomly
> > > > Message-ID: <e96e0c84-6a83-78f5-dab3-60a39b6eb9a2 at gmail.com>
> > > > Content-Type: text/plain; charset=utf-8; format=flowed
> > > >
> > > > [resending to the list, really this time]
> > > >
> > > > On 11/8/18 7:44 PM, Tanu Kaskinen wrote:
> > > >
> > > > > The problem is most likely due to this bug regarding monitor sources:
> > > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/304
> > > > >
> > > > > Whenever the monitored sink has a rewind, a chunk of audio is
> > > > > apparently duplicated in the monitor source. It would be great if
> > > > > someone could figure out what goes wrong in the monitor rewinding code.
> > > >
> > > > Let me quote the main mistake, from src/pulse/stream.h:
> > > >
> > > > >  * The latency is stored in \a *r_usec. In case the stream is a
> > > > >  * monitoring stream the result can be negative, i.e. the captured
> > > > >  * samples are not yet played. In this case \a *negative is set to 1.
> > > >
> > > > I.e., the design mistake is that monitor sources allow one to capture
> > > > samples that have not yet been played. This is always wrong, as those
> > > > samples can be overwritten by a rewind, and there is no "uncapture" to
> > > > compensate. So the fix would be to make sure that monitor sources
> > > > capture not what was just written to them, but what was actually played
> > > > and can no longer be overwritten. I.e., change the latency from negative
> > > > to small positive.
> > > >
> > > > --
> > > > Alexander E. Patrakov
> > >
> > > Thanks for digging into this!
> > >
> > > Some questions:
> > >
> > > 1. Is there any workaround for this without a proper bugfix and a new release?
> > > 2. Is this a question of buffer underrun / jitter bcause of  CPU usage? What is the cause for "monitor rewinds", why is it needed?
> > > 3. Why are the artifacts gone sometimes and sometimes the appear after PulseAudio restart?
> > 
> > 1. No.
> > 2. This is unlikely to be related to CPU usage. Rewinds typically
> > happen when new streams appear, or when something changes the volume.
> > To figure out for sure, please run PulseAudio with very very verbose
> > logging, see below. It will then announce the reason for each rewind.
> > 3. No idea, see the log.
> > 
> > Actually, it is still only a speculation (or, if you prefer, educated
> > guess) that your problem is related to rewinds. If PulseAudio does not
> > log anything about a rewind, then that's not it.
> > 
> > Here is how to run PulseAudio with very very verbose logging;
> > 
> > 1. Edit ~/.config/pulse/client.conf, so that it contains exactly one line:
> > autospawn=no
> > 
> > 2. systemctl --user stop pulseaudio.socket pulseaudio.service
> > 
> > 3. pulseaudio -vvv 2>&1 | tee -i pulseaudio.log
> > 
> > 4. Reproduce the problem
> > 
> > 5. Ctrl+C, revert the change to ~/.config/pulse/client.conf, systemctl
> > --user start pulseaudio.socket pulseaudio.service
> > 
> > 6. Send the log here.
> > 
> > -- 
> > Alexander E. Patrakov
> 
> Four takes on verbose logs here: https://we.tl/t-a94jpZtBnN
> 
> During the first run (the files are accordingly named), I did not get 
> artifacts and WSJT-X was decoding the audio signal fine. For runs 2-4 I 
> got distorted audio only and was not able to get clean audio even after 
> starting PulseAudio "normally" through systemctl and restarting all 
> browsers and other PulseAudio clients.
> 
> I noticed "Scheduling delay" / "Underrun" messages even during the first 
> "successful" run and they did not seem to affect audio. The same 
> messages continued even when listening through speakers briefly and I 
> couldn't hear any popping / distortion.
> 
> -Mikael

Do you have insight into this issue? This is very much a blocker for many use cases...

-Mikael