Popping|crackling sound 96khz on Linux

When trying to run sessions on 96khz on my Linux setup I hear crackling sounds but when I use 48khz it’s fine. I even tested on my windows 10 setup abs 96khz sounds fine.

Is there a setting I should know about to adjust. I believe it’s the same with jack and Alsa.

First question is, is your machine correctly setup for audio?

Second question might be what audio interface you are using? This could be an issue in the driver for it depending.


I use a m-audio fast track c400
I’ll check over the info you sent

Buffer size is the main thing that is likely to control this. Using small buffer sizes at 96kHz can be challenging on a lot of hardware.

I tried messing with jack buffer to the highest buffer and still noises but when I set it to pulse audio In ardour at 96khz it was playing through my audio interface and the cracklings were gone, but I figured pulse audio is downsampling to 44.1 or 48khz doesn’t it.

I decided to just stay at 48khz in my Linux setup, reason why I wanted to use it was a lot of my saturated plugins or distortion don’t have a over sampling feature to reduce aliasing and i read online That running sessions at higher sample rates can help with that. Plus I believe audio fx do sound different at higher sample rates etc

1 Like

It’s always best to experiment (to test it)
swapping sample-rate in ardour/mixbus is not that ‘fast’ as in Bitwig or Renoise…
Difference is obvious, when using distortion/tape saturation plugins… At least, in Renoise, you can play song - and swap sample-rate on the fly, and hear the difference… :slight_smile:

At I tried a amp sim and I noticed it sounded different at 96 then 48, doesn’t mean better but different

exactly, no one says it is better, but there surely is difference… it depends on the plugin… how it is programmed… maybe it just shows wrong values when using higher sample-rate… maybe not… but for example in Reason 11/12 when i use Scream rack (tape mode), the distortion sounds so smooth - with less of the high-freq material… i can say same for airwindows tape/channel9 and even renoise built-in distortion module :slight_smile:

i remember comparing kotelnikov recently in both 44.1k and 96k. Seems like at higher sample-rate (read 96k) it cannot handle fast attack transients well… like some transient pass uncaught… whereas at 44.1k it handles fast transients without any issue, everything is smashed to death :smiley:

just my 2 cents

If that was the case, then the FX is broken. Some DSP algorithms that benefit from higher sample-rates do upsamle internally, so you don’t have to do that explicitly.

In any case, measure it (or use the source-code when available), there is no need to believe.

Do you have a rough estimate of how much latency high quality upsampling/downsampling would add to a processor?

Depends, it can be zero, but if the DSP doesn’t allow for that, certainly less than 100 samples. maybe 4 or 16 – less than a ms, anyway.

But with distortion plug-ins, some don’t say they oversample, usually it’s listed in the features. Plus it’s to avoid aliasing they say to use oversample or use higher sample rate in your session. As for plugins sounding different at different sample rates; I’ve tested this and I came to the conclusion that it’s different. I’m sure many plugins do what you described but I can’t for sure know it’s a standard thing plugin developers do

Say you’re a mixing or mastering engineer. In that case sample-rate is predefined by the recorded material and/or the deliverable format.

The last thing you want is for plugins to sound differently each time, so you buy ones that are not affected by the rate…


can you specify some plugin vendors which are exactly that?
Do you know if Harrison XT (lv2) suite of plugins is behaving same for all rates?
the x42 eq?

The sample rate of audio file is pre-defined and that is fine - but how do plugins behave when processing audio at higher sample-rate? I’m interested in this topic lately, and i would like to see some proofs, because most native DSP effects sound different within different sample rate (bitwig, reason, renoise… - i tested those),

also i remember author of airwindows (http://www.airwindows.com/) plugins (Chris J.) mentioned that increasing sample-rate is always better than using oversampling (cannot find the topic from gearspace for 15 minutes so far -.-). Can you describe why should one do so, or why one should NOT do?
many questions, i know…

Thank you in advance!

I stubbled over this topic below after stumbling over a topic in the changes for kernel.

Paul Davis suggest that small buffers can be a chalange for some hardware. After reading the changes to kernel 5.14.2 it seems more likely to be a chalange for the developers of kernel drivers.

With the 5.14.2 or newer was possible to go from 64 to 32 samples, 0.7 ms 3 periods. Using Jack and FFADO with Focusrite Saffire pro26.

Pulse Audio is not disconnected. It is possible to have Pulse play something on the Soundblaster CA0132 while tracking USB keyboard with the Focusrite,

Maybe we should collect some $ to pay someone to do what the changes is suggesting?

Here is the Changes

ALSA: usb-audio: Work around for XRUN with low latency playback

commit 4267c5a8f3133db0572cd9abee059b42cafbbdad upstream.

The recent change for low latency playback works in most of test cases
but it turned out still to hit errors on some use cases, most notably
with JACK with small buffer sizes.  This is because USB-audio driver
fills up and submits full URBs at the beginning, while the URBs would
return immediately and try to fill more -- that can easily trigger
XRUN.  It was more or less expected, but in the small buffer size, the
problem became pretty obvious.

Fixing this behavior properly would require the change of the
fundamental driver design, so it's no trivial task, unfortunately.
Instead, here we work around the problem just by switching back to the
old method when the given configuration is too fragile with the low
latency stream handling.  As a threshold, we calculate the total
buffer bytes in all plus one URBs, and check whether it's beyond the
PCM buffer bytes.  The one extra URB is needed because XRUN happens at
the next submission after the first round.

Fixes: 307cc9baac5c ("ALSA: usb-audio: Reduce latency at playback start, take#2")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210827203311.5987-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.