Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
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" > > To: General PulseAudio Discussion > > > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > > distorted audio randomly > > Message-ID: > > > > Content-Type: text/plain; charset="UTF-8" > > > > Mikael Nousiainen : > > > > > > On Thu, Nov 8, 2018, at 20:49, > > > pulseaudio-discuss-requ...@lists.freedesktop.org wrote: > > > > Message: 4 > > > > Date: Thu, 8 Nov 2018 21:31:52 +0500 > > > > From: "Alexander E. Patrakov" > > > > To: General PulseAudio Discussion > > > > > > > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > > > > distorted audio randomly > > > > Message-ID: > > > > 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
> Message: 2 > Date: Sat, 10 Nov 2018 10:54:03 +0500 > From: "Alexander E. Patrakov" > To: General PulseAudio Discussion > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > distorted audio randomly > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Mikael Nousiainen : > > > > On Thu, Nov 8, 2018, at 20:49, > > pulseaudio-discuss-requ...@lists.freedesktop.org wrote: > > > Message: 4 > > > Date: Thu, 8 Nov 2018 21:31:52 +0500 > > > From: "Alexander E. Patrakov" > > > To: General PulseAudio Discussion > > > > > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > > > distorted audio randomly > > > Message-ID: > > > 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
Mikael Nousiainen : > > On Thu, Nov 8, 2018, at 20:49, > pulseaudio-discuss-requ...@lists.freedesktop.org wrote: > > Message: 4 > > Date: Thu, 8 Nov 2018 21:31:52 +0500 > > From: "Alexander E. Patrakov" > > To: General PulseAudio Discussion > > > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > > distorted audio randomly > > Message-ID: > > 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
On Thu, Nov 8, 2018, at 20:49, pulseaudio-discuss-requ...@lists.freedesktop.org wrote: > Message: 4 > Date: Thu, 8 Nov 2018 21:31:52 +0500 > From: "Alexander E. Patrakov" > To: General PulseAudio Discussion > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > distorted audio randomly > Message-ID: > 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? -Mikael ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
[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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
On Thu, 2018-11-08 at 14:56 +0500, Alexander E. Patrakov wrote: > Mikael Nousiainen : > > > I've got a very weird issue with PulseAudio when trying to route audio > > from one application (Firefox 64.0b7 (64-bit)) to another one (WSJT-X > > v1.9.1). > > I'm experiencing the same issue with different browsers (Chrome and > > Chromium too). > > The browser is receiving audio from a radio transceiver through a WebRTC > > connection and I'm feeding it to WSJT-X to decode the data in the audio > > signal. > > > > I'm using two module-null-sink modules to transfer the audio between > > the browser and WSJT-X. I use pavucontrol to make the browser play audio to > > null sink called "radio-output" and then let WSJT-X listen to the audio > > via "radio-output.monitor". The kind of setup exists for transmitted audio > > where WSJT-X feeds audio to the browser through a null sink called > > "radio-input". > > > > However, the issue her is that WSJT-X is mostly not able to decode the data > > when it's using "radio-output.monitor" as audio input. Sometimes it works > > and sometimes it does not. As a technical detail, I'm trying to decode FT8 > > digital mode traffic and I've confirmed that the reason is not related to > > bad time sync (which FT8 requires), because I can even play the browser > > audio through laptop speakers and let WSJT-X use the laptop microphone as > > audio input and it decodes the data just fine -- the audio sounds clean > > and strong with no audible artifacts. > > We need to figure out whether this is due to a monitor or due to a > null sink. Could you please let the browser play to your speakers, and > WSJT-X record from the monitor of the sound card that the browser is > playing to? Does it work? > > Is the webrtc feed public? I.e., can I run WSJT-X locally in order to > reproduce the issue? 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. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
up a fixed latency range for the hardware sound cards, but > I believe this should not have any effect on the null sinks or loopback > modules: > > load-module module-udev-detect tsched=yes tsched_buffer_size=65536 > fixed_latency_range=yes > > I am not sure if these audio artifacts are caused by PulseAudio, WSJT-X > or some specific configuration issue in my system. Any ideas? > > > -- > > Message: 2 > Date: Thu, 8 Nov 2018 14:56:23 +0500 > From: "Alexander E. Patrakov" > To: General PulseAudio Discussion > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > distorted audio randomly > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Mikael Nousiainen : > > > I've got a very weird issue with PulseAudio when trying to route audio > > from one application (Firefox 64.0b7 (64-bit)) to another one (WSJT-X > > v1.9.1). > > I'm experiencing the same issue with different browsers (Chrome and > > Chromium too). > > The browser is receiving audio from a radio transceiver through a WebRTC > > connection and I'm feeding it to WSJT-X to decode the data in the audio > > signal. > > > > I'm using two module-null-sink modules to transfer the audio between > > the browser and WSJT-X. I use pavucontrol to make the browser play audio to > > null sink called "radio-output" and then let WSJT-X listen to the audio > > via "radio-output.monitor". The kind of setup exists for transmitted audio > > where WSJT-X feeds audio to the browser through a null sink called > > "radio-input". > > > > However, the issue her is that WSJT-X is mostly not able to decode the data > > when it's using "radio-output.monitor" as audio input. Sometimes it works > > and sometimes it does not. As a technical detail, I'm trying to decode FT8 > > digital mode traffic and I've confirmed that the reason is not related to > > bad time sync (which FT8 requires), because I can even play the browser > > audio through laptop speakers and let WSJT-X use the laptop microphone as > > audio input and it decodes the data just fine -- the audio sounds clean > > and strong with no audible artifacts. > > We need to figure out whether this is due to a monitor or due to a > null sink. Could you please let the browser play to your speakers, and > WSJT-X record from the monitor of the sound card that the browser is > playing to? Does it work? > > Is the webrtc feed public? I.e., can I run WSJT-X locally in order to > reproduce the issue? > > -- > Alexander E. Patrakov > Ok, so I recorded audio with Audacity from both the null sink monitor and speaker monitor and the results are clear: null sink monitor audio contains distorted (buffer underrun-like?) artifacts, while speaker monitor audio does not. I also recorded the samples using two sample rates (44.1 kHz and 48 kHz) just to see if it made a difference -- and the artifacts were certainly worse with 44.1 kHz capture, when PulseAudio has to do sample rate conversion (all devices are set to use 48 kHz). However, the artifacts are there also in the 48 kHz recording as you can hear. One thing was interesting, though: I could not first reproduce the issue, but after restarting PulseAudio with "pulseaudio -k", the artifacts appeared again! I restarted WSJT-X after restarting PulseAudio, but did _not_ restart Firefox. After recording the samples, I restarted Firefox and WSJT-X both and I seem to be getting clean audio again. Not sure if NOT restarting Firefox while PulseAudio gets killed/restarted has something to do with this. I'll have to repeat these tests a couple of times at least to see if there is a pattern. Here's a link to a ZIP file containing the recordings as WAV files: https://we.tl/t-QE6Cixchay (one of them contains some quiet audio from microphone in the beginning, forgot to cut it out) -Mikael ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
Mikael Nousiainen : > I've got a very weird issue with PulseAudio when trying to route audio > from one application (Firefox 64.0b7 (64-bit)) to another one (WSJT-X v1.9.1). > I'm experiencing the same issue with different browsers (Chrome and Chromium > too). > The browser is receiving audio from a radio transceiver through a WebRTC > connection and I'm feeding it to WSJT-X to decode the data in the audio > signal. > > I'm using two module-null-sink modules to transfer the audio between > the browser and WSJT-X. I use pavucontrol to make the browser play audio to > null sink called "radio-output" and then let WSJT-X listen to the audio > via "radio-output.monitor". The kind of setup exists for transmitted audio > where WSJT-X feeds audio to the browser through a null sink called > "radio-input". > > However, the issue her is that WSJT-X is mostly not able to decode the data > when it's using "radio-output.monitor" as audio input. Sometimes it works > and sometimes it does not. As a technical detail, I'm trying to decode FT8 > digital mode traffic and I've confirmed that the reason is not related to > bad time sync (which FT8 requires), because I can even play the browser > audio through laptop speakers and let WSJT-X use the laptop microphone as > audio input and it decodes the data just fine -- the audio sounds clean > and strong with no audible artifacts. We need to figure out whether this is due to a monitor or due to a null sink. Could you please let the browser play to your speakers, and WSJT-X record from the monitor of the sound card that the browser is playing to? Does it work? Is the webrtc feed public? I.e., can I run WSJT-X locally in order to reproduce the issue? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
