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.
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.)
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
// ^^ so initially, no setting
// after boot sequence:
-> 48000.0 // on my system
-> nil // so you should not look at ServerOptions for this
s.options.sampleRate = 44100;
// after boot:
-> 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:
// a couple seconds later
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.
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).
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?)