[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] Eickmeyer: I suppose That should somehow be done with installer too. [15:16] 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] while I am sure tcl/tk could do that, A rewrite to python would probably be the best next step forward [15:17] It would be. [15:19] And yes I have found another opps in controls :P [15:23] Fun. Got fixes? [15:24] I think I can... I have been working on documenting foldback: http://scott.cbbs.org/ardours-interface/foldback-strip/ [15:25] but I think I can set that aside as done. [15:26] Ah, yes. You showed me that. Sweet. :) [15:29] I try to keep the manual up to date as I work while I remember what I did... [15:30] 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] 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] Interesting. So, %zita-buffer-variable=%jack-buffer-variable/2 or something of that sort. [15:37] 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] Yeah, that's true. [15:38] and so the buffer size needs to have a lower limit [15:39] 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] 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] Ok, but USB devices almost automatically mean it needs to be */3. [15:41] So I need to set half at anything higher than 128, and then 64 for anything lower [15:41] */3 is only needed for really small 32/3 for example. [15:42] 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] What I'm referencing is this: https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface [15:44] 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] Ok, interesting. [15:47] 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] Unfortunately not everyone's machine can do that. [16:00] 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] yup [16:04] and as we found yesterday, high core machines have limited low latency ability [16:05] Which makes sense as they have to dedicate the IRQs to multithreading. [16:07] 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] However, the reality is, that use case matters [16:09] 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] Agreed. [16:10] 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] Well, that's why I have a laptop with dedicated graphics. [16:11] 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] wonko is turning into a bit of a leech. [16:21] no worries, he has turned up a few bugs others will also find. [16:22] Eickmeyer: for the 64 samples in minimum bug, should I file a bug report before pushing? [16:22] If you wouldn't mind, that would be great. Shows that we're not just uploading for the sake of uploading. [16:22] FF tends to be an interesting time. [16:23] 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] https://bugs.launchpad.net/ubuntustudio-controls/+bug/1844706 [16:28] Launchpad bug 1844706 in ubuntustudio-controls "Many USB devices will not bridge correctly at latencies below 128 samples" [Undecided,New] [16:28] Cool. [16:38] 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] The more you know. :) [16:42] I seem to have forgotten what perl does [16:49] 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] Yeah, that seems like a great idea. I feel as if rtirq hasn't been touched in forever. [16:51] 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] YES! That might eliminate unneccesary xruns on the master device. [16:53] 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] 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] 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] I have no doubt it will, but that's another thing that can bite me if I'm not careful. :) [17:52] sorry, I should have done that. [17:58] No worries.