Advice for debugging ALSA problem?

I’ve consistently had a problem when running a standalone JUCE app with Linux/ALSA where the audio will become very garbled for an indeterminate period of time. As far as I can tell it seems to appear more often when CPU usage is high. The problem is that when this occurs, PluginProcessor::processBlock gets called noticeably faster than it should be for the current buffer size and sample rate, resulting in higher CPU usage, sustaining the problem. The problem usually goes away after playing no notes and waiting for CPU usage to drop as a result.

Recently, I’ve made some additions to my project which, on an unoptimized build, can reliably cause this problem. I wanted to take the opportunity to go into JUCE’s ALSA code to see if I could create a patch for the problem. Unfortunately, I am not very familiar with ALSA or how JUCE interacts with it. All I’ve been able to figure out so far is that ALSADevice::writeToOutputDevice in juce_audio_devices/native/juce_linux_ALSA.cpp gets called more often than it should be when the audio is garbled and returns to a normal rate when the audio becomes clear again.

I would appreciate any advice on what to do or suggestions of things to try.

2 Likes

Did you manage to fix it?

I was unable to fix it.

I run in similar symptoms:
With a probability of 50% the garbling sounds starting with the application and sometimes it appears when cpu-load is extreme high or low.
As an absolute beginner in juce and c++ I have no idea how to debug this issue.

@aaaaaaaaaaaa how have figured out, how often an when your processing block has been called?

If someone else want to listen, here is an example of the problem:
sound_example_link_to_dropbox

I run into this issue on Ubuntu 20.04 with juce 5.4.7 (to reduce the sources of other errors i didnt update)

Does anyone else have an Idea where the origin of the error could be?