Audio plugin standalone on Linux: Glitchy audio

NOTE: There’s a flickering GIF down this post which makes it hard to read. You might wanna use the pause-button on the GIF before continuing.

I came here to talk about a pretty prominent issue, which I’ve faced developing on Linux ever since I started using JUCE.

When instantiating the standalone version of a plugin, audio will be choppy / glitchy which makes it basically unusable.

In the “Options” tab, which automatically appears in the window handle, there’s a myriad of options. Usually the only one which will work at all is the option “Playback/Recording through PulseAudio sound server”.

Sometimes opening the tool “pavucontrol” will fix the issue. If it does not, however, I can see the cause of the problem there:

The Alsa plugin is popping in and out of existence!


I’ve battled this issue for the longest time, across multiple distros with multiple audio interfaces. I cannot help but feel that this is an underlying problem of JUCE.

I can’t be the only one battling this issue? How do other Linux devs develop?

1 Like

Something that helps is to set input device to “none”. And I noticed that this bug doesn’t appears with pipewire.

Do you have pulseaudio running?

That’s not helpful when developing an FX plugin :wink: I haven’t used pipewire so far. It’s also possible to get things running with Jack, but it’s a hassle to set up and start every time. I think the out of the box solution should be supported by JUCE.


As far as I know, JUCE tries to get ALSA device directly and PulseAudio tries to intercept it and pass through itself, that’s why things go glitchy. JUCE knows nothing about PulseAudio.

I just disabled PulseAudio for my main DAW audio card (and leave for multimedia/entertainment device). This setup is much better than attempts to make PulseAudio/ALSA coexist on one card.

If it’s not an option, you can run the app with pasuspender.
Also, you can set up PulseAudio as a JACK client and have them run permanently.

I’ve faced this category of issue as well and plan to look for a workaround that hardwires to a specific Linux back end rather than have them be switchable at runtime, which seems to be the cause of most of the issues.

Something similar is the legacy availability for DirectSound on the Windows side, but nowadays no one would want to use it. And WASAPI Exclusive mode can cause annoying issues as well.

It’s hard to beat to the smooth experience of using CoreAudio on macOS, but while the complexity of audio back ends in Windows is annoying but manageable, on Linux it seems there are too many options for most people’s own good, and an alternative solution should be available (to hardwire).

If I can sort this out I will share my solution. It will involve reading from some type of config file to decide which audio back end to initialize and permanently connect with. When choosing JACK, all the usual will have to be done ahead of time (JACK server running, etc.)