[03:22] <Eickmeyer[m]> OvenWrks: 2.3.7 is solid.
[15:04] <OvenWrks> Eickmeyer good, I can work on my server upgrade
[15:06] <OvenWrks> Eickmeyer: server is 16.04 and can't be upgraded (32 bit) I suppose I could get it to 18.04... but that is eol ish too. I have a 64 bit machine that I have to set up from scratch.
[15:32] <Eickmeyer[m]> OvenWrks: Well, if you became an Ubuntu member, you can probably get your 16.04 server on Ubuntu Advantage for free.
[15:33] <Eickmeyer[m]> Would be good until 2026.
[15:35] <OvenWrks> It would not hurt to go from 1 core at 800mhz to two cores at 1600Mhz either
[15:36] <Eickmeyer[m]> I'm not going to argue that one! You could probably transfer the stuff you have on the server, regardless of bit architecture, but yeah, a new setup would probably be in your best interest.
[15:37] <OvenWrks> not to mention twice the memory and ssd
[15:38] <Eickmeyer[m]> Yeah, all huge plusses.
[15:52] <OvenWrks> Eickmeyer[m]: how long is pulse support likely to last?
[15:53] <OvenWrks> Eickmeyer[m]: I am thinking the first step to supporting PW is to do an exclusive or.
[15:53] <Eickmeyer[m]> OvenWrks: Indefinitely, I believe. I know that Ubuntu Desktop is switching to Pipewire, but Kubuntu is sticking to pulse for now.
[15:54] <Eickmeyer[m]> I'm not sure how long until it's fully deprecated. 
[15:54] <OvenWrks> So set up a switch that is use jack/pulse or use pw alone
[15:54] <Eickmeyer[m]> Might be years.
[15:54] <Eickmeyer[m]> Yeah, that's kindof what we need at this point.
[15:55] <Eickmeyer[m]> I know Ruth Cheesley (she/her) was looking for something like that for herself, having controls do that would be ideal.
[15:57] <OvenWrks> I think the main thng would be to change the name of the user's "master" device to system:* and be able to set rate and latency for it as well as making it's rate the same as the jack graph.
[15:58] <OvenWrks> secondary to that would be setting the names of all other devices and perhaps rate and latency as well.
[15:58] <Eickmeyer[m]> Similar to how we do it with zita now?
[15:58] <OvenWrks> yes
[15:59] <Eickmeyer[m]> That might be good. Is freewheel support finished yet do you know?
[15:59] <OvenWrks> I am not sure how pw deals with MIDI at this point
[15:59] <Eickmeyer[m]> https://docs.pipewire.org/page_midi.html
[15:59] <OvenWrks> Eickmeyer[m]: the right question might be if ubuntu/debian has the version that does.
[16:00] <Eickmeyer[m]> The version in Kinetic is the most recent version last I checked.
[16:01] <OvenWrks> so free wheeling _should_ be supported.
[16:02] <Eickmeyer[m]> Latest is 0.3.56, Kinetic has 0.3.56.
[16:02] <OvenWrks> zita-njbridge should still "just work"
[16:02] <Eickmeyer[m]> Even Jammy has 0.3.48.
[16:02] <OvenWrks> qipnet should also.
[16:03] <OvenWrks> (or is it qnetip?)
[16:04]  * OvenWrks will have to go back to using his delta 66 for everyday audio  :P
[16:04] <Eickmeyer[m]> Right. It's too bad zita-njbridge isn't cross-platform like jacktrip.
[16:05] <OvenWrks> Eickmeyer[m]: in my life there is only one platform  ;)
[16:06] <OvenWrks> my next phone may very well be pine*
[16:06] <Eickmeyer[m]> Hehe i know.
[16:07] <Eickmeyer[m]> But, you know me, I like to bridge the gap to lure people in.
[16:07] <Eickmeyer[m]> I mean, imagine being able to fully replace Dante.
[16:09] <OvenWrks> AES67 comes close. AVB may do it better.
[16:11] <OvenWrks> The truth though, is that to get good performance on any of them, a dante/avb/aes67 audio card is used that does all that stuff and looks to the OS like a USB/PCIe audio device
[16:12] <OvenWrks> Even on windows or mac a virtual dante audio IF uses a lot of cpu (same with avb or aes67)
[16:13] <Eickmeyer[m]> Well, of course, but that's what people are using in a pinch.
[16:14] <OvenWrks> In a pinch, aes67 on linux and a dante router in wine works too.
[16:15] <OvenWrks> Probably, if dante is installed, there are lots of win/mac computers around to route off of anyway
[16:16] <OvenWrks> So just having aes67 installed would work.
[16:19] <Eickmeyer[m]> Might have to try that in the future, next time I want to play around with that.
[16:20] <OvenWrks> do be aware that jack does not see the aes67 ports, I don't know if zita-ajbridge does either.
[16:21] <OvenWrks> zita would be the best way of connecting anyway.
[16:25] <Eickmeyer[m]> So does alsa not see them?
[16:27] <OvenWrks> most applications that see alsa devices see those ports
[16:27] <OvenWrks> Not applications using the jack code (like ardour)
[16:30] <Eickmeyer[m]> Well, Ardour doesn't have to use Jack.
[16:38] <OvenWrks> That is not what I meant. Even when using ALSA the internal code that talks to ALSA is taken straight out of jack (v1 as happens)
[16:59] <OvenWrks> I am thinking to just set cpu governor and Boost state directly from autojack on startup. I notice they still don't work right.
[17:00] <OvenWrks> not only that but I am tired of chasing OS changes.
[17:12] <Eickmeyer[m]> Yeah, I was noticing that too. Seems that 2.3.7 was a bit more stable after a full shutdown for me (not just a reboot).
[17:21] <Eickmeyer[m]> Is there a reason why we don't just use "cpufreq-set -g performance" or something to set the governor (thereby using cpufreq-utils as a dependency)?
[17:22] <Eickmeyer[m]> OvenWrks: ^
[17:22] <Eickmeyer[m]> I mean, boost makes sense, but that seems to be in a consistent spot.
[17:27] <OvenWrks> cpufreq used to be used but I have noticed (or had) that it was not being kept up. Last I looked it still used sysV init and did not work right.
[17:46] <Eickmeyer[m]> I mean, from the command line, it's fine. I'm not suggesting using it as a startup command, but as something that studio-system could just call to set the governor so that you wouldn't have to chase the API constantly.
[17:47] <Eickmeyer[m]> I think you're mistaking it for indicator-cpufreq.
[17:49] <Eickmeyer[m]> Or not.
[17:49] <Eickmeyer[m]> Seems Dave Jones at Canonical is at least maintaining the package.
[17:50] <Eickmeyer[m]> I mean, it works. We use it at Kubuntu Focus to set the CPU governor in our backend scripts.
[17:50] <Eickmeyer[m]> We don't use the startup features though.