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: ALSA: poll time out, polled for 3999027 usecs
Feb 03 06:23:25 norns jackd: 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?
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.
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.)