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@xxxxxxxxx> > > To: General PulseAudio Discussion > > <pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx> > > Subject: Re: PulseAudio null sink monitor gives > > distorted audio randomly > > Message-ID: > > <CAN_LGv15swrn8H-GRV9FOi4HnjpHG=jNNiS=2qenHp0HSsFWwQ@xxxxxxxxxxxxxx> > > Content-Type: text/plain; charset="UTF-8" > > > > Mikael Nousiainen <mikaelnousiainen@xxxxxxxxxxxx>: > > > > > > On Thu, Nov 8, 2018, at 20:49, pulseaudio-discuss-request@xxxxxxxxxxxxxxxxxxxxx wrote: > > > > Message: 4 > > > > Date: Thu, 8 Nov 2018 21:31:52 +0500 > > > > From: "Alexander E. Patrakov" <patrakov@xxxxxxxxx> > > > > To: General PulseAudio Discussion > > > > <pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx> > > > > Subject: Re: PulseAudio null sink monitor gives > > > > distorted audio randomly > > > > Message-ID: <e96e0c84-6a83-78f5-dab3-60a39b6eb9a2@xxxxxxxxx> > > > > 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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
