[03:22] OvenWrks: 2.3.7 is solid. [15:04] Eickmeyer good, I can work on my server upgrade [15:06] 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] OvenWrks: Well, if you became an Ubuntu member, you can probably get your 16.04 server on Ubuntu Advantage for free. [15:33] Would be good until 2026. [15:35] It would not hurt to go from 1 core at 800mhz to two cores at 1600Mhz either [15:36] 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] not to mention twice the memory and ssd [15:38] Yeah, all huge plusses. [15:52] Eickmeyer[m]: how long is pulse support likely to last? [15:53] Eickmeyer[m]: I am thinking the first step to supporting PW is to do an exclusive or. [15:53] OvenWrks: Indefinitely, I believe. I know that Ubuntu Desktop is switching to Pipewire, but Kubuntu is sticking to pulse for now. [15:54] I'm not sure how long until it's fully deprecated. [15:54] So set up a switch that is use jack/pulse or use pw alone [15:54] Might be years. [15:54] Yeah, that's kindof what we need at this point. [15:55] I know Ruth Cheesley (she/her) was looking for something like that for herself, having controls do that would be ideal. [15:57] 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] secondary to that would be setting the names of all other devices and perhaps rate and latency as well. [15:58] Similar to how we do it with zita now? [15:58] yes [15:59] That might be good. Is freewheel support finished yet do you know? [15:59] I am not sure how pw deals with MIDI at this point [15:59] https://docs.pipewire.org/page_midi.html [15:59] Eickmeyer[m]: the right question might be if ubuntu/debian has the version that does. [16:00] The version in Kinetic is the most recent version last I checked. [16:01] so free wheeling _should_ be supported. [16:02] Latest is 0.3.56, Kinetic has 0.3.56. [16:02] zita-njbridge should still "just work" [16:02] Even Jammy has 0.3.48. [16:02] qipnet should also. [16:03] (or is it qnetip?) [16:04] * OvenWrks will have to go back to using his delta 66 for everyday audio :P [16:04] Right. It's too bad zita-njbridge isn't cross-platform like jacktrip. [16:05] Eickmeyer[m]: in my life there is only one platform ;) [16:06] my next phone may very well be pine* [16:06] Hehe i know. [16:07] But, you know me, I like to bridge the gap to lure people in. [16:07] I mean, imagine being able to fully replace Dante. [16:09] AES67 comes close. AVB may do it better. [16:11] 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] Even on windows or mac a virtual dante audio IF uses a lot of cpu (same with avb or aes67) [16:13] Well, of course, but that's what people are using in a pinch. [16:14] In a pinch, aes67 on linux and a dante router in wine works too. [16:15] Probably, if dante is installed, there are lots of win/mac computers around to route off of anyway [16:16] So just having aes67 installed would work. [16:19] Might have to try that in the future, next time I want to play around with that. [16:20] do be aware that jack does not see the aes67 ports, I don't know if zita-ajbridge does either. [16:21] zita would be the best way of connecting anyway. [16:25] So does alsa not see them? [16:27] most applications that see alsa devices see those ports [16:27] Not applications using the jack code (like ardour) [16:30] Well, Ardour doesn't have to use Jack. [16:38] 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] 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] not only that but I am tired of chasing OS changes. [17:12] 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] 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] OvenWrks: ^ [17:22] I mean, boost makes sense, but that seems to be in a consistent spot. [17:27] 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] 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] I think you're mistaking it for indicator-cpufreq. [17:49] Or not. [17:49] Seems Dave Jones at Canonical is at least maintaining the package. [17:50] I mean, it works. We use it at Kubuntu Focus to set the CPU governor in our backend scripts. [17:50] We don't use the startup features though.