[00:03] Has the actual script changed. If not init.d vs systemd gets a big meh from me. It's fine the way it is unless it actually makes something better [13:40] OvenWerks: So, it looks like rtirq is getting set up correctly on liquorix 5.11 it's just that rtirq status doesn't seem to print it properly [13:42] https://gist.github.com/bhechinger/0e1cb2b21c04d3eae203f6e1359ba9bb [13:54] oooooooooooohhhhhhhh [13:54] I just set the priority of firewire_ohci as well [13:54] running at 16/2 and did a find / and got only 2 xruns. NICE! [14:45] wonko: I had a similar find in 20.04, 2 xruns in the first half hour, then nothing for the next 4 days till I shut it down. [14:46] so it looks like you definitely need to prioritize both firewire *and* firewire_ohci [14:46] I think just the OHCI [14:46] right now they are equal (I just manually used chrt to set them up) but I wonder which one should be first in the list [14:46] oh? [14:47] ohci is the one that talks to the device [14:47] ok, I can do that, but I might just leave both, because why not. :) [14:47] what's the other one then? [14:47] whatever works [14:48] I actually have snd_ice ahead of firewire [14:49] but I am no longer using the ice so I should change that [14:50] using just firewire should be ok as it seems to be the irq*firewire* that it raises [14:51] (which is firewire_ohci [14:52] That is, rtirq seems to be smart enough to only choose the irq service blobs [14:54] wonko: the big thing I need to address in controls is hot plugged USB devices. I need to find out at plugin time what the irq service blob is for that device [14:56] Is that something you need help with? [14:57] also, can you paste the output of this on your machine: ps -eo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio [15:13] OvenWerks: How do you get x-run counts in studio-controls? [15:13] wonko: they are only sine studio-controls startup [15:14] the gui monitors the jack xrun call back [15:15] wonko: this is on my list to change though I am thinking I want to move this to autojack and have it comunicate the value to the gui so it could be from the jack startup or from last reset [15:15] how do I access that? I'd like to track the xruns [15:16] look at ~/,log/jack/jackdbus.log [15:16] (I think... it should be obvious looking in the directopry) [15:16] yeah, I see them there [15:17] but if there is a better way than parsing the log file I'd prefer to do that [15:30] wonko: here is the output you asked for above: http://www.ovenwerks.net/paste/prior.txt [15:32] wonko: I really should switch firewire and snd_ice... but it seems to work really well and I think I have tried using the ICE through zita at the same time with no problems. [15:33] * OvenWerks wanders off to get breakfast for his son [15:43] Ok, I see why rtirq status output on liquorix doesn't show everything [15:44] that same ps on liquorix prints out firewire instead of irq/17-firewire [15:44] I wonder why that is [17:38] wonko: https://github.com/ovenwerks/studio-controls/issues/30 [17:38] that is why xrun stuff will change [17:42] Eickmeyer[m]: I am starting to find mxmilkiib anoying on the controls issues... There are a number of issues where I have asked for more information but gotten nothing. [17:43] I agree. I kindof saw this from the get-go. [17:43] If it were me, I'd close the issue if he hasn't responded in two months. [18:24] Eickmeyer[m]: good idea... done [18:24] ok, so I would need an jack-client to capture xruns? [18:25] that or tail -f ~/.log/jack/jackdbus.log |grep [18:26] yeah, i might end up using mtail or something for that but I was hoping to get it from the source. [18:27] Actually, this will be a fun dive into using the jack client [18:27] I'll do it. :) [18:27] The jackclient callback may not give much info. I think you can get how late but maybe not which client caused the xrun [18:28] hmm, well, we'll find out [18:28] I mostly just need the actual xruns [18:28] to turn into timeseries data [18:28] python or c(**)? [18:28] Go [18:28] Ok, bye :) [18:29] I *have* been thinking about learning Rust, maybe I'll do it in that. [18:29] Compiled would use the same API either way [18:29] yeah [18:30] i'm sure they are both just wrappers around the C library [18:30] Actually even the python spi is very close [18:30] *API [18:31] Eh, I just want to get this done. I'll do it in Go. Rust can wait. [19:42] dammit, the go library doesn't have the xrun callback implemented yet. Guess I'll add that. [19:43] * OvenWerks wonders what else is missing... [19:44] wonko: be aware that in general jackd callbacks can not run any jack calls from within the callback itself [19:45] that's good to know [19:45] looks like it's missing a lot [19:45] https://github.com/xthexder/go-jack#implemented-bindings [19:45] so callback should be very short... just xrun_hit = xrun_hit + 1 [19:46] yeah, just hitting the prometheus counter Inc() function [19:46] then your main loop will be if (xrun_hit) { make calls to jack, display xruns whatever} [19:47] which is literally just what you said. :) [20:12] BAM [20:12] curl --silent localhost:9002/metrics | grep jack [20:12] # HELP jack_xruns The total number of XRUNs that have happened [20:12] # TYPE jack_xruns counter [20:12] jack_xruns 25 [20:58] what is the current place to run stuff after jack as started or is that a wait for the new studio controls request? [21:02] That will be in 2.2.0 (already there) [21:04] ~/.config/autojack/prestop, poststop, prestart and poststart [21:05] Hmm, looking at those, right now poststart is right after jack starts but before any bridges are created/connected. Not sure if that is the best place. [21:06] The script has to be +x [21:11] ok, so I just have to wait for 2.2.0 then, cool [21:12] https://imgur.com/hCrz0JA.png [21:12] yay! :-D [21:32] And here we have it as per time: https://imgur.com/hxXcsDG.png [21:33] wonko: now all you need is to have what processes are busy at the time of peak [21:34] yeah, I just need to create a dashboard in grafana that tracks that all. [21:34] All that data is already in prometheus, I just need to make it something to look at