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

[Alexander E. Patrakov]

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