jack load monitoring

I’m interested in the jack load monitoring: what’s it useful for? If jacks load is to high, what does one do to mitigate?

I’ve been having troubles with some of my scripts (but not others) where jack suddenly fails. Could this jack load monitoring help?

can you go into more detail by what it means for jack to suddenly fail?

1 Like

Yeah! Feel free to move this to a new thread if that’s appropriate.

Here’s an example I saved off a month or so ago of what I see in the logs:

Feb 03 06:23:25 norns jackd[318]: ALSA: poll time out, polled for 3999027 usecs
Feb 03 06:23:25 norns jackd[318]: JackAudioDriver::ProcessAsync: read error, stopping...

When this happens all sound stops, supercollider fails and exits on restart, and if I knew more about manually restarting Jack I might be able to recover but as it stands I have been ssh-ing in and sudo reboot-ing.

This happens to me, sporadically, when working on/with nydl especially, but sometimes other scripts. It seems to especially occur when using K1 to go to the “main menus” but that also might be my brain imagining patterns in occurances. I haven’t found a reliable way to reproduce myself. I have accepted a couple bug reports of specific tools in nydl causing “audio to stop, and not work again until norns is restarted” in which I suspect Jack too, but haven’t been able to get a solid confirmation from ssh’d in logs, since these users aren’t in the habit of ssh. I think I’ve confirmed it not to be a supercollider crash.

I know relatively little about the care and feeding of Jack, and kind of jumped on “jack is a thing that could be overloaded?” as a possible way forward on a topic where I feel stuck.

i am going to guess that this is exposing some bug in scsynth that hangs the audio graph.

actually no, i think it is the soundcard connection somehow.

its JACK’s internal estimate of how long it is spending to compute the entire client processing graph for a given audio block, compared to the block duration. approaching 100% will be correlated with audible xruns. its a more accurate but much more specific measure of capacity than the averaged profiled load for each CPU core as reported by top (which is the other usage display.)

do note that it represnets all the audio processing load, including norns builtin effects, mixing busses, and softcut. (e.g., sits around 10% with just internal compressor and reverb running.) but does not reflect processing time spend in lua or sclang. (or i think in any DSP worker threads, but we aren’t using any right now; in fact we’re keeping all realtime audio single-threaded as a design decision.)

basically reducing it from supercollider means using fewer ugens, cheaper ugens, more .kr rates, etc.


Ah, that all makes sense. The error message I get sounds like scsynth sat on an audio frame not just a little after the deadline from Jack (which would cause a transient dropout/glitch) but long after it, like 4 seconds, and in this circumstance jack gives up and dies?

that’s what i thought, but now looking at mailing lists etc (and gearing up to check jackd source code to confirm) i think was wrong

i think this particular error specifically happens when jack is waiting on ALSA; viz., can’t talk to the soundcard itself. i’m not sure i’ve ever seen it on norns.

[ed] yeah; this error case specifically occurs in the absence of xruns, when waiting on polling the driver’s buffer file:

are you on a shield? sounds maybe a little ridiculous, but does pressing K1 like, flex something out of place on the PCB / 40-pin header connection?


yeah that reminds me i think it would be good to add some high-level utilities/UI (somehow) to save journalctl logs automatically…

(someone made a script for this recently, i forget who… or maybe it was a mod, which would make sense)

1 Like

Yeah I’m on a shield.

presses k1 vigorously while running dronecaster

Nuthin. Hmm. I’ll have to start doing nydl development in earnest again and see if it recurs. Do you think there’s some chance it’s an electrical problem like a ground loop? There’s a hefty pop when I turn on and off Norns, and I’ve been meaning to check to make sure it’s on the same strip as all the other audio stuff.

Thank you so much for looking in to this. I would not have thought to try the jack code itself.

1 Like

yeah, there’s a chance that static discharge could do it by resetting the codec, or soemthing like that.

idk, just spitballing, seems like time to consider Weird Things.

also of course possible there are multiple issues; e.g. what you;re seeing is different from what nydl users are reporting…

finally, there is the distinct possibility of e.g. OOB memory access bugs in norns code smashing jackd memory, or something horrible like that. you’d think i would have seen that sometime in the last few years though.

i occasionally get weird jackd failures during development but so far have always traced these to zombie processes / PEBCAK (when i can be bothered to trace them.)

… i’m gonna run nydl and see if anything turns up

1 Like