[00:03] <wonko> 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] <wonko> 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] <wonko> https://gist.github.com/bhechinger/0e1cb2b21c04d3eae203f6e1359ba9bb
[13:54] <wonko> oooooooooooohhhhhhhh
[13:54] <wonko> I just set the priority of firewire_ohci as well
[13:54] <wonko> running at 16/2 and did a find / and got only 2 xruns. NICE!
[14:45] <OvenWerks> 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] <wonko> so it looks like you definitely need to prioritize both firewire *and* firewire_ohci
[14:46] <OvenWerks> I think just the OHCI
[14:46] <wonko> 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] <wonko> oh?
[14:47] <OvenWerks> ohci is the one that talks to the device
[14:47] <wonko> ok, I can do that, but I might just leave both, because why not. :)
[14:47] <wonko> what's the other one then?
[14:47] <OvenWerks> whatever works
[14:48] <OvenWerks> I actually have snd_ice ahead of firewire
[14:49] <OvenWerks> but I am no longer using the ice so I should change that
[14:50] <OvenWerks> using just firewire should be ok as it seems to be the irq*firewire* that it raises
[14:51] <OvenWerks> (which is firewire_ohci
[14:52] <OvenWerks> That is, rtirq seems to be smart enough to only choose the irq service blobs
[14:54] <OvenWerks> 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] <wonko> Is that something you need help with?
[14:57] <wonko> 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] <wonko> OvenWerks: How do you get x-run counts in studio-controls?
[15:13] <OvenWerks> wonko: they are only sine studio-controls startup
[15:14] <OvenWerks> the gui monitors the jack xrun call back
[15:15] <OvenWerks> 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] <wonko> how do I access that? I'd like to track the xruns
[15:16] <OvenWerks>  look at ~/,log/jack/jackdbus.log
[15:16] <OvenWerks> (I think... it should be obvious looking in the directopry)
[15:16] <wonko> yeah, I see them there
[15:17] <wonko> but if there is a better way than parsing the log file I'd prefer to do that
[15:30] <OvenWerks> wonko: here is the output you asked for above: http://www.ovenwerks.net/paste/prior.txt
[15:32] <OvenWerks> 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] <wonko> Ok, I see why rtirq status output on liquorix doesn't show everything
[15:44] <wonko> that same ps on liquorix prints out firewire instead of irq/17-firewire
[15:44] <wonko> I wonder why that is
[17:38] <OvenWerks> wonko: https://github.com/ovenwerks/studio-controls/issues/30
[17:38] <OvenWerks> that is why xrun stuff will change
[17:42] <OvenWerks> 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] <Eickmeyer[m]> I agree. I kindof saw this from the get-go.
[17:43] <Eickmeyer[m]> If it were me, I'd close the issue if he hasn't responded in two months.
[18:24] <OvenWerks> Eickmeyer[m]: good idea... done
[18:24] <wonko> ok, so I would need an jack-client to capture xruns?
[18:25] <OvenWerks> that or tail -f ~/.log/jack/jackdbus.log |grep <whatever>
[18:26] <wonko> yeah, i might end up using mtail or something for that but I was hoping to get it from the source.
[18:27] <wonko> Actually, this will be a fun dive into using the jack client
[18:27] <wonko> I'll do it. :)
[18:27] <OvenWerks> 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] <wonko> hmm, well, we'll find out
[18:28] <wonko> I mostly just need the actual xruns
[18:28] <wonko> to turn into timeseries data
[18:28] <OvenWerks> python or c(**)?
[18:28] <wonko> Go
[18:28] <OvenWerks> Ok, bye :)
[18:29] <wonko> I *have* been thinking about learning Rust, maybe I'll do it in that.
[18:29] <OvenWerks> Compiled would use the same API either way
[18:29] <wonko> yeah
[18:30] <wonko> i'm sure they are both just wrappers around the C library
[18:30] <OvenWerks>  Actually even the python spi is very close
[18:30] <OvenWerks> *API
[18:31] <wonko> Eh, I just want to get this done. I'll do it in Go. Rust can wait.
[19:42] <wonko> 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] <OvenWerks> wonko: be aware that in general jackd callbacks can not run any jack calls from within the callback itself
[19:45] <wonko> that's good to know
[19:45] <wonko> looks like it's missing a lot
[19:45] <wonko> https://github.com/xthexder/go-jack#implemented-bindings
[19:45] <OvenWerks> so callback  should be very short... just xrun_hit = xrun_hit + 1
[19:46] <wonko> yeah, just hitting the prometheus counter Inc() function
[19:46] <OvenWerks> then your main loop will be if (xrun_hit) { make calls to jack, display xruns whatever}
[19:47] <wonko> which is literally just what you said. :)
[20:12] <wonko> BAM
[20:12] <wonko> curl --silent localhost:9002/metrics | grep jack
[20:12] <wonko> # HELP jack_xruns The total number of XRUNs that have happened
[20:12] <wonko> # TYPE jack_xruns counter
[20:12] <wonko> jack_xruns 25
[20:58] <wonko> 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] <OvenWerks> That will be in 2.2.0 (already there)
[21:04] <OvenWerks> ~/.config/autojack/prestop, poststop, prestart and poststart
[21:05] <OvenWerks> 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] <OvenWerks> The script has to be +x
[21:11] <wonko> ok, so I just have to wait for 2.2.0 then, cool
[21:12] <wonko> https://imgur.com/hCrz0JA.png
[21:12] <wonko> yay! :-D
[21:32] <wonko> And here we have it as per time: https://imgur.com/hxXcsDG.png
[21:33] <OvenWerks> wonko: now all you need is to have what processes are busy at the time of peak
[21:34] <wonko> yeah, I just need to create a dashboard in grafana that tracks that all.
[21:34] <wonko> All that data is already in prometheus, I just need to make it something to look at