Playback glitching with ALSA

Hi,
I'm getting glitchy / choppy audio output from some of the JUCE example projects.  I'm running up-to-date Arch Linux (kernel 3.18.2-2) and I have the JUCE source from git, current as of today (commit 0401.)  I noticed this glitchiing while running the Audio Plugin Host, but I also hear it in the Demo project (e.g. Synthesizers, File Playback) and BouncingBallWavetableDemo.

In Demo, if I increase the buffer size (e.g. between 512 and 4096) the glitching gets slightly slower and steadier, from many dropouts per second (maybe >10) to more like one per second.

Qualitatively the audio glitches sound like what's described here: http://www.juce.com/forum/topic/choppy-playback-scientific-linux
However, it sounded like that poster's problem was specific to pulseaudio, whereas I don't have pulseaudio installed and am just using ALSA.

Any ideas, or other information I can provide?
Thank you!

 

Very hard to debug ALSA things like this without actually having the same device (and system) to test myself. ALSA devices seem to vary a lot in their behaviour.. All I can suggest is maybe running a profiler or debugging into the low level code to try to narrow down the area that's causing trouble. Happy to do what I can if you have any more clues..

Hi Jules, thanks for the reply.  Unfortunately I do not yet have any ALSA log data (incidentally this seems surprisingly difficult, depending on certain kernel flags which are not set on my Arch system https://www.kernel.org/doc/Documentation/sound/alsa/Procfile.txt).  So I'll understand if this still isn't enough data to help, but I did notice a new detail: the glitching goes away (including at small buffer sizes e.g. 64) if I have only audio outputs, and no inputs, active.  (I observed this using the Demo app (Settings + Synthesizers demos) but I've also written several small JUCE programs that use only audio output and work fine on my system.)

Hmm, that's interesting. Because the inputs and outputs are separate, there's some nastiness in the ALSA wrapper to try to synchronise them, and that could be the culprit in cases where the input and output devices have a tendency to drift. I'll try to have a look into this..

I also find that I turn off the output [edit: I meant turn off the input] the glitch goes away.  I was the original poster on the Scientific Linux post and it did appear to be pulseaudio at the time.  The glitchiness was very occasional, so it was hard to determine if pulse was the cause - esp with all the popular discontent with pulse architecture etc. 

But since then I have gotten this bad playback to happen with pulse completely disabled, both with the Juce Demo and my own code.  Shutting off the input seems to make it go away.  My current users don't need to record, so I can disable it in my app, but it would be nice to finally resolve this issue.

 

 

Has anybody made any progress with this? I noticed that the problem seems to go away if I run JUCE at a sample rate of 44100, but it occurs if I run it at 48k.

Still no update on this? I have a very similar problem: Audio noise when input channels enabled, despite only playing a simple sine wave or something…

Using PulseAudio for both input/output, Xonar D1, Ubuntu 18.04.

Noise goes away if I reduce buffer size to 128 (default sample rate 44100Hz) or increase sample rate to 176400Hz (default buffer size 512) but anything in between get a pulsing buzz sound added to it

I measured time between callbacks to getNextAudioBlock(), and it is irregular.

This behavior is attenuated with smaller buffer sizes, and tasks that occupy most of the time interval that corresponds to the buffer. It seems the function is called as often as the CPU is capable of for a few cycles, then the rush is compensated by a delayed call.

When the CPU is busy enough, callbacks become more regular and audio works with inputs on. Without inputs, audio works well even with the irregular callbacks.

This test was on Debian 10, real time linux kernel, core i7 CPU.

I am also struggling with this when using ALSA with Raspbian Buster on an RPi 3b+. Working great when audio inputs are disabled but get dropouts as soon as I enable them and have my AudioSource copy them to the output.

Edit: Very odd, but it seems to be fixed after installing pulseaudio and removing it again (I had it uninstalled to begin with).

Edit 2: The issue has returned after running audio for 20-30 mins.

I’ve been reading about ALSA and pulseaudio recently, and it seems some users in HiFi DACs forums have been having problems with it. IIRC some guys fixed it reseting the configuration of pulseaudio (but don’t quote me on that). Anyway, found Debian and Archlinux distro troubleshooting wikies talking about pulseaudio problems and solutions:

https://wiki.debian.org/PulseAudio#Solving_Problems

https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting

Or even totally disabling it and using only ALSA

Have you guys keep having this problem/solved it? I can’t test it yet since my Raspberry soundcard is yet to arrive

Unfortunately, I’m still having the same problem. I bought a Raspberry Pi 4 that I need to configure and test it with.

Try disabling Pulseaudio and using only ALSA (if you run only 1 audio application at a time) or ditching Pulseaudio for Jack. Afaik Pulseaudio is a more “generic desktop” oriented audio server which I guess is fine for casual audio stuff (browsing, watching some video) but many people doing audio stuff are having some trouble with it, whereas Jack is more suited for those matters

It is already uninstalled, but I still have problems when using the ALSA inputs.

Hey all,
I run in similar symptoms, you can hear here: sound_example_link_to_dropbox (sinewave and pitch are part of aimed effect)

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

As a beginner in juce and c++ I have no idea how to solve it and would be truly grateful to get help.

Have you @aking7 @codePlay found a way to solve it?

for whom it may concern.
high load cpu (around 80% in user space) and setting in a JUCE app a number of input channels to zero both mitigate cracks and pops. those workarounds get me confused.
however, as I found out at Discord, the proper solution is launch jack server. just running qtjackctl should help out.