Random dropouts when adding/removing audio streams

[acarasimon96]

In the last few months, I've noticed that the output from JamesDSP would rarely but randomly drop out for a split second when there are multiple sources playing and one of them is being torn down.

Here's what I did to reliably reproduce this:

1. Play some white noise or something similar. I used this myNoise page on Firefox for this.
2. In a GUI audio player, click the play and stop buttons repeatedly until you hear a very brief dropout or popping sound. I did this step with Foobar2000 on Wine, DeaDBeeF, and even the built-in media player on Firefox.

I was also able to trigger those dropouts when I leave Zoom meetings on their official app, but they seem to occur more frequently than doing the above steps. I had to temporarily blocklist that app to prevent the dropouts from happening every time I exit out of a meeting.

When the dropouts occur, I would see the ERR count beside jamesdsp_sink and jdsp_PwJamesDspPlugin_JamesDsp on pw-top go up by 2, but I found no logs mentioning xruns in the system journal.

Solutions I've tried to address this include:

• Changing api.alsa.headroom to 1024 (or higher) in the Wireplumber configuration files
• Changing the values for default, minimum, and maximum quantum size to match each other in /etc/pipewire/pipewire.conf. I chose 1024 to minimize the effects of higher latency while keeping the latency low enough for the audio outputs to be stable.
• Launching JamesDSP either on the terminal or from a .desktop file with the PIPEWIRE_LATENCY variable added in front of the actual command, e.g. PIPEWIRE_LATENCY=2048/48000 jamesdsp. I tried different quantum values as low as 512 and as high as 8192, and the rare dropouts still occur regardless.
• Launching JamesDSP with a PTY as explained in #47
• Setting the CPU priority of either JamesDSP or Pipewire to the highest level and their CPU schedulers to "First In First Out"
• Tweaking the RTKit daemon service per the Pipewire wiki
• Giving realtime privileges to the current user

All of the above actions did nothing to eliminate the dropouts, but they might have reduced how often those dropouts occurred.

---

App version: 2.3-299-g77da74 (Pipewire flavor, Git build from AUR) JamesDSP core version: 4.1.0 Pipewire version: 0.3.57 Distribution: Manjaro Desktop environment: KDE Plasma 5.25.4

[acarasimon96]

It turns out that, for some unknown reason, the value of link.max-buffers in my /etc/pipewire/pipewire.conf was set to 16 instead of the default 64. I made that change about 3 days ago, and so far I have not yet heard any dropouts every time a new stream is added or removed. Still, the xruns count in pw-top for jdsp_PwJamesDspPlugin_JamesDsp goes up by 1 or 2 on every startup and pipeline reload.

[acarasimon96]

The random dropouts finally came back earlier today, this time with link.max-buffers in /etc/pipewire/pipewire.conf set to 128, and when a new audio stream starts playing rather than at teardown as initially reported.

Since I have become easily irritated every time I hear the audio dropping out, I don't know what else to do to fix this other than getting myself a separate computer just to process all the audio coming out of the main machine.

As of this comment, I am running the following software in the same distro:

App version: 2.4-124-gd46304d (Pipewire flavor, Git build from AUR) JamesDSP core version: 3.12 Pipewire version: 0.3.68-2 Desktop environment: KDE Plasma 5.27.4