[pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
mikaelnousiainen at fastmail.com
Sun Nov 11 15:47:33 UTC 2018
> 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
> <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:
> 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.
More information about the pulseaudio-discuss