I’m running a linux machine devoted to SuperCollider. My audio device is a Native Instruments Komplete Audio 6 mkII. I’ve followed various guides and believe I have things pretty tightened. Jack2. Realtime Kernel (with unused soundcard, wifi and bluetooth modules removed and running rtirq to set priorities). CPU frequency scaling set to performance, etc. At a buffer size of 256 I’ll see the occasional Xrun. 128 more so. And 64 is non-stop. I haven’t found much of a difference between 48000 or 44100. But here’s the thing at no matter the buffer size (I’ve tested up to 1024) and sometimes with a simple SinOsc I will here clicks and pops with Cadence/Catia not showing any Xruns at the time. I’ve tried swapping cables so I don’t think that is the issue. It happens on both speakers and headphones. This doesn’t always happen but frequently and with no predictability that I can find. Any Ideas?
I’m not an expert on linux audio troubleshooting (tho I’ve done my share of tweaking on my linux machines), but a bit more info about your hardware would be useful to anyone wanting to give advice:
what kind of machine, processor, which linux distro, which kernel version? By ‘Realtime Kernel’ you mean low-latency “Preempt-RT”? [help.ubuntu.com]
Are glitches only present with SC or any other audio program? What is CPU doing when running SC server?
Hey, thanks for the reply. The machine is a budget laptop bought a few years ago: Acer Aspire E5-532-P1ZJ with an Intel Pentium N3700 (Quad 1.6 GHz) and 4GB ram. I’m running EndeavourOS which is a pre-configured Arch distribution. I normally run Arch but wanted a quick install to test the waters as I had strayed away from my initial synth / SuperCollider learning from a year ago. The kernel is linux-rt 5.6.19.12-1 (not lts) from the Arch User Repository (see ArchWiki). It’s running the LightDM display manager with a minimally configured i3 window manager (not with the bells and whistles that comes with EndeavourOS). I start up Jack with Cadence and then have Catia on a window usually to check on Xruns and swap “cables” if need be.
I haven’t been running any other audio on this machine. Just SuperCollider / in and out to my MicroBrute. I’ve had these clicks happen while not interfaced with the MicroBrute or MIDI and running a simple { SinOsc.ar }.play. The last couple of days have been spent in the help files trying to get some handle on the language and not in the deep end with the MicroBrute.
I’ll install VCVRack (though my GPU can’t really handle it) or something after and see if it happens elsewhere. And I’ll try to have a top terminal running to see if there is a process running away when it happens. The clicks and pops may happen a lot in a certain period but don’t usually run on at a time for more than a few seconds.
I figure you have looked at https://wiki.archlinux.org/index.php/Professional_audio - It seems full of great info. I have no experience with arch. I would first try to test if its SC fault or jack/kernel by trying other pro-audio programs on top of jack (Ardour for example). If other apps don’t produce clicks, then the problem is indeed connected to SC. Otherwise it’s something to do with jack/real-time priorities/hardware… The article linked above mentions arch-proaudio IRC channel and also Linux audio users #lau channel.
Yeah I’m going to look into things further and test around. I never especially thought the issue was SuperCollider itself but thought maybe someone here had some ideas. I was just playing with VCVRack and while I was definitely having some xruns (my computer just can’t keep up, I think its mostly GPU related) I think the other issue was there as well. They sound different. Isoloated xruns sound more like a tiny piece of the music is missing (though many at a time are almost white noise) while this issue sounds to me more like clicks and pops on top.
Can you report a bit on settings of starting JACK? how many periods and and frames per period… before starting jack via Cadence, try opening a terminal and running jack from there, something like:
$ jackd -d alsa -d hw:0,0 -p 512 -n 3
the “hw:0,0” is alsa address of your soundcard. you can find out by running
$ aplay -l
you see some something like:
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC285 Analog [ALC285 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
... etc
the imporant part is the number following ‘card’ and ‘device’ where it says “Analog”. that’s probably your analog in/out, therefore hw:0,0
you can also get so called alias names by doing
$ cat /proc/asound/cards
0 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0x2ffb018000 irq 158
using this info you can start jack with something like:
$ jackd -d alsa -d hw:PCH -p 1024 -n 3
In some cases jack wont start if you don’t provide sampling rate to it. So try adding -r 44100 or -r 48000 to the line above. Run jackd -d alsa --help for more commandline arguments and what they mean.
In terminal it is the fastest to see errors and xruns. Success would look something like:
$ jackd -d alsa -d hw:0,0
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0,0|hw:0,0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
(keep the terminal running)
Btw, integrated audio cards in laptops are notorious to produce xruns and clicks and pops when one demands low latency from them (for example 2 x period of 128 frames). Try increasing period size to insane amount, like 2048, and 4 periods, and if there are no xruns, lower period size (dividing by two) - 1024, 512, 256, 128, and number of them from 4 to 2. If nothing works, perhaps borrow a usb interface from a friend and try with it (all above works the same, just find the right alias/card/device number). But you should really be able to work without xruns.
I’m going to play around with these ideas tomorrow. Some notes: I am using a usb interface with my integrated card disabled. I’ve found better success by using the stock kernel but with threadirqs enabled. The realtime kernel in the user repository was at 5.6.19.12 (it has been updated to 5.9.1.something since and I haven’t gotten around to testing that) which had buggy intel i915 stuff going on. I’m not sure at what version this was improved, just that at some point on my main computer (which also has i915) I switched back from LTS and things were working better. But still with my current setup I’m usually getting too many xruns/clicks and pops at 128 frames and at 256 the latency with my microbrute is just a little too noticeable.