Audio problems, clicks on linux

Questions
#1

Hey all,

I’ve been experiencing some clicks/pops/noise when using SuperCollider on Linux, it doesn’t require a lot of CPU load to start happening. Interestingly - when recording through Pipewire to Reaper, the reaper recording retains some of the sonic artefacts, but only around 20% or so. When recording directly from SC with s.record, the recordings are flawless.

EDIT: I thought the problem didn’t turn up with an external audio interface, but it does.

Would be grateful for any help!
Cheers,
Jordan

#2

The first thing to check is if all the applications (pipewire, supercollider, reaper) have the same sample rate.

#3

hey Kosmas,

thanks for the reply. I just checked, for some reason I can’t set the SC sample rate to 48k:

s.sampleRate // returns 44100.0
o = ServerOptions.new;
o.sampleRate = 48000;
s.boot;
s.sampleRate // returns 44100.0

Ditto I changed the PipeWire Config to include:

## Properties for the DSP configuration.
default.clock.rate          = 48000 
default.clock.allowed-rates = [ 44100, 48000 ]

This also hasn’t seemed to make a difference. The following always turns up in the post window when booting the server:

SC_AudioDriver: sample rate = 48000.000000, driver's block size

#4

Maybe try:

Server.local.options.sampleRate = 48000
Server.local.boot
Server.local.options.sampleRate
#5

Weirdly enough, it still returns 44100 :frowning:

#6 
s.options.sampleRate = 48000
s.boot;                
s.sampleRate           // returns 44800 ???
#7

maybe
pw-jack scide
to start sc?

#8

I’m not sure this is weird.

Scsynth in Linux doesn’t control its own sample rate – it gets the sample rate from Jack. The fact that you’re running pipewire on your system doesn’t change the way scsynth works.

We run in pipewire by asking pipewire to present itself to scsynth as Jack (pw-jack command).

One side effect of this is that it should be impossible in Linux to have scsynth disagree with the (Jack, or pw-masquerading-as-Jack) sample rate. And you found that it wasn’t possible to get 44.1 kHz while the system was at 48 kHz. So I think that the “mismatched sample rates” line of investigation hasn’t panned out.

Which distro are you using?

I’m suspecting a bit that interrupt priorities may be configured for the USB audio kernel module but maybe not for the built in device. (If that’s the case, it’s out of my league – I use Ubuntu Studio to avoid messing with all that.)

hjh

#9

SC seems to be stuck on 44.1 kHz regardless of what I do, and Pipewire defaults to 48000. Maybe I didn’t express that clearly, sorry.

I’m using Fedora, which has sometimes worked well in the past and sometimes worked not well.

I wrote in the original post that the issues turned up on headphones but not with an USB interface, but after some more testing I realised I was wrong.

One thing I’ve found is that the CPU/Server usage seems to be very very high, and this is when the artefacts start turning up:

50.do {{ Splay.ar(SinOsc.ar(exprand(50, 3000))) * -40.dbamp}.play};

s.peakCPU // 72.58381652832
s.avgCPU // 47.780227661133
#10

this also didn’t work, but thanks for the suggestion!

#11

I’m not clear what’s going on… in Linux, this shouldn’t be possible. The server in Linux can only get its sample rate from the system. The sampleRate setting is ignored.

// upon SC launch
s.sampleRate
-> nil

s.options.sampleRate
-> nil

// ^^ so initially, no setting

s.boot;

// after boot sequence:
s.sampleRate
-> 48000.0  // on my system

s.options.sampleRate
-> nil  // so you should not look at ServerOptions for this

s.quit;

s.options.sampleRate = 44100;

s.boot;

// after boot:
s.sampleRate
-> 48000.0  // sampleRate is obtained from JACK; ServerOptions has no effect

Also, you had said this:

I’m curious if you sniff /status.reply messages to see what scsynth is telling sclang about sample rate:

OSCFunc.trace(true, false);

// a couple seconds later
OSCFunc.trace(false);

Where, on my system, in msg: [ /status.reply, 1, 0, 0, 2, 195, 1.7408411502838, 1.7826608419418, 48000.0, 47998.516963051 ], the 48000.0 is the server’s running sample rate.

I’m not sure how you can get SC_AudioDriver: sample rate = 48000.000000 and then 44100.0 in the /status.reply – I can’t think of any reason why that would happen.

hjh

#12 
// with USB interface
msg: [ /status.reply, 1, 12, 1, 2, 117, 3.9851057529449, 4.1680598258972, 44100.0, 44097.531710422 ]

// without 
msg: [ /status.reply, 1, 12, 1, 2, 117, 4.6818103790283, 5.0320649147034, 44800.0, 44668.052957266 ]

The results of s.sampleRate also reflect this - with the USB device, it returns 44.1k, without, it returns 44.8k.

#13

For whatever reason (I never investigated), my laptop behaves the same. The built-in soundcard can run only at 48 kHz while USB can take 44.1 kHz. So this at least is not really surprising to me.

EDIT: Hold on… 44.8 kHz? Does that even exist? Definitely not standard.

If the dropouts occur with both types of audio device, though, then issue is unlikely to be the result of the difference between devices. Sample rate is probably a dead end.

Linux is quite sensitive to audio driver priority. I struggled with this under plain vanilla Ubuntu for a few years (I was never able to get it completely working, starting from a regular distro), before finding that Ubuntu Studio just gets it right. With Ubuntu Studio, you can even start with a flavor (xubuntu, kubuntu, etc) and apply Ubuntu Studio packages to that, and get the benefits of the ready-to-use low-latency audio configuration. I’m not sure if anything similar exists for fedora (though a quick search seems negative).

hjh

1 Like
#14

I’ve been on-and-off with Fedora, Arch has always seemed to do audio better, but I always lose the nerve for Arch eventually. Might need to see if Ubuntu Studio solves this…

#15

i am on arch for maybe 2 years now, some months on pipewire. after years on ubuntustudio i moved to arch and dont regret. pipewire is not clear enough for me but deals ok ajusting samplerates between apps (i have some old interfaces and apps that just works on 44.1!) – and i had always problems with carla/catia etc… tried njconnect, jack-matchmaker etc but now i am really happy with qpwgraph. to save configs, set exclusive connections…

i didnt edit any configs on pipewire. i suspect that you could review some general audio configs (checking tools, realtime group, cpu governor as suggested by mads at Setting up Arch Linux for audio performance ), maybe check your startup.scd for latency/server mem that may increase your cpu cycles & start a clean config on pipewire.

you could also report which interfaces are you having trouble with (some of them may need some extra alsa configs), and if you are using bluetooth also (maybe phones?)

sorry for this long post and generic info :slight_smile:

#16

Thanks Igor, yeah audio on arch always worked fine, it was other reasons that I moved away from it, might end up going back though.

I also haven’t changed any configs on pipewire. setting cpu to governor doesn’t seem to fix the problem either, and i have an ultraminimal startup.scd.

I’ve had this issue both on a Tascam us 2x2hr and just on my laptop, a Thinkpad T480s.

#17

+1 for manjaro, although I’ve heard good stuff about endeavour (both based on arch)

#18

If you want to save time and have a minimalist setup, this option is not bad at all:

https://archbang.org/