[14:25]  * Eickmeyer thinks it's hilarious every time someone asks for a way to do a "minimal" install and choose which packages to install when it's right there in Ubiquty.
[15:15] <OvenWerks> Eickmeyer: I suppose That should somehow be done with installer too.
[15:16] <Eickmeyer> OvenWerks: We've been talking about this for a while. Unfortunately most of our time has been chasing edge-case bugs like those of Wonko's.
[15:17] <OvenWerks> while I am sure tcl/tk could do that, A rewrite to python would probably be the best next step forward
[15:17] <Eickmeyer> It would be.
[15:19] <OvenWerks> And yes I have found another opps in controls  :P
[15:23] <Eickmeyer> Fun. Got fixes?
[15:24] <OvenWerks> I think I can... I have been working on documenting foldback: http://scott.cbbs.org/ardours-interface/foldback-strip/
[15:25] <OvenWerks> but I think I can set that aside as done.
[15:26] <Eickmeyer> Ah, yes. You showed me that. Sweet. :)
[15:29] <OvenWerks> I try to keep the manual up to date as I work while I remember what I did...
[15:30] <OvenWerks> but I have to keep a separate branch because it is not released yet. (I now remember I should add an "as of version 6.0)
[15:36] <OvenWerks> Eickmeyer: what I have found is that the recomended buffer size for zita-ajbrdge is 1/2 the size of jack master. This is because the bridge adds latency and running a smaller buffer size reduces that.
[15:37] <Eickmeyer> Interesting. So, %zita-buffer-variable=%jack-buffer-variable/2 or something of that sort.
[15:37] <OvenWerks> Eickmeyer: however, there are limits for many USB devices. One has to remember that the main reason for the bridge at all is to add cheap USB mics to the mix
[15:37] <Eickmeyer> Yeah, that's true.
[15:38] <OvenWerks> and so the buffer size needs to have a lower limit
[15:39] <Eickmeyer> Is there a lowest possible limit? Because if (in the unlikely event) someone has set jack's buffer to 16 then that means zita would need to be 8.
[15:39] <OvenWerks> I found that running jack at 64/2 zita could not even open my cheap usb IF at 32/2 but was fine when I set 128/2 so zita at 64/2
[15:39] <Eickmeyer> Ok, but USB devices almost automatically mean it needs to be */3.
[15:41] <OvenWerks> So I need to set half at anything higher than 128, and then 64 for anything lower
[15:41] <OvenWerks> */3 is only needed for really small 32/3 for example.
[15:42] <OvenWerks> the limit is that USB is 1ms call rate which happens to be 1/3 for 16 samples at 48000 (assuming the exact same clock)
[15:44] <Eickmeyer> What I'm referencing is this: https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface
[15:44] <OvenWerks> As intel has messed up USB with XHCI (for USB 3.0) no one can get 32/3 on their usb device anyway and so 64/2 seems to work fine even on my cheap $0.80 usb device.
[15:45] <Eickmeyer> Ok, interesting.
[15:47] <OvenWerks> Shutting off the XHCI driver in my bios was effective in allowing me to raise the priority of my front usb port above the back (mouse) usb port
[15:59] <Eickmeyer> Unfortunately not everyone's machine can do that.
[16:00] <Eickmeyer> The thing is, we can't rely on BIOS methods of fixes or workarounds because that is completely dependent on the device manufacturer.
[16:03] <OvenWerks> yup
[16:04] <OvenWerks> and as we found yesterday, high core machines have limited low latency ability
[16:05] <Eickmeyer> Which makes sense as they have to dedicate the IRQs to multithreading.
[16:07] <OvenWerks> ya, my old single core P4 with hyper thread turned off was rock solid at with no xruns with .7  ms latency (16/2)
[16:08] <OvenWerks> However, the reality is, that use case matters
[16:09] <OvenWerks> for recording and other daw use, a high latency is mostly ok so long as monitoring is done outside the box, either in the audio interface or an external mixer
[16:09] <Eickmeyer> Agreed.
[16:10] <OvenWerks> for live use, latency matters but who is going to drag around a server box to do that when a pi4 does the job really well?
[16:11] <Eickmeyer> Well, that's why I have a laptop with dedicated graphics.
[16:11] <OvenWerks> For mobile, low latency use the i5 4 core cpu is about the most expensive that still works well or has any advantage
[16:13] <Eickmeyer> wonko is turning into a bit of a leech.
[16:21] <OvenWerks> no worries, he has turned up a few bugs others will also find.
[16:22] <OvenWerks> Eickmeyer: for the 64 samples in minimum bug, should I file a bug report before pushing?
[16:22] <Eickmeyer> If you wouldn't mind, that would be great. Shows that we're not just uploading for the sake of uploading.
[16:22] <Eickmeyer> FF tends to be an interesting time.
[16:23] <Eickmeyer> Also, bug fixes are allowed after beta freeze before final freeze, but I like to cover our butts on this kind of thing.
[16:28] <OvenWerks> https://bugs.launchpad.net/ubuntustudio-controls/+bug/1844706
[16:28] <Eickmeyer> Cool.
[16:38] <OvenWerks> Eickmeyer: fix uploaded (two lines added)
[16:39]  * OvenWerks has found another eason to not like python... in tcl everything is a string, in python typing is required str(*) and int(*)  :P
[16:40] <Eickmeyer> The more you know. :)
[16:42] <OvenWerks> I seem to have forgotten what perl does
[16:49] <OvenWerks> Eickmeyer: BTW the udev-rtirq package I was interested in (next cycle-ish) does not seem to work for me. It is quite a simple package and so I will probably just pull the idea and see if I can make it work. Whatever I do, would replace rtirq. I am guessing it would become a part of -controls or at least depend on it.
[16:50] <Eickmeyer> Yeah, that seems like a great idea. I feel as if rtirq hasn't been touched in forever.
[16:51] <OvenWerks> My idea is that if the autojack config file (or at least some of the info) was available to a system land daemon, then that daemon would set jack master device as the highest and zita devices after. Any audio device not being used would not have it's priority raised
[16:52] <Eickmeyer> YES! That might eliminate unneccesary xruns on the master device.
[16:53] <OvenWerks> last of all, finding any MIDI devices and raise them but below any of the others. (MIDI being as slow as it is may not need a raise)
[16:54] <OvenWerks> rtirq has been changed in the last few years... or maybe the kernel has changed, because I used to be able to do usb3 and get it picked up.
[17:32] <Eickmeyer> OvenWerks: autobuild didn't trigger (last change was only 21 hours ago), so manually triggered. I want to see if it builds properly before I upload to eoan.
[17:32] <Eickmeyer> I have no doubt it will, but that's another thing that can bite me if I'm not careful. :)
[17:52] <OvenWerks> sorry, I should have done that.
[17:58] <Eickmeyer> No worries.