| * 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. | 14:25 | |
| OvenWerks | Eickmeyer: I suppose That should somehow be done with installer too. | 15:15 |
|---|---|---|
| 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:16 |
| 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:17 |
| OvenWerks | And yes I have found another opps in controls :P | 15:19 |
| Eickmeyer | Fun. Got fixes? | 15:23 |
| OvenWerks | I think I can... I have been working on documenting foldback: http://scott.cbbs.org/ardours-interface/foldback-strip/ | 15:24 |
| OvenWerks | but I think I can set that aside as done. | 15:25 |
| Eickmeyer | Ah, yes. You showed me that. Sweet. :) | 15:26 |
| OvenWerks | I try to keep the manual up to date as I work while I remember what I did... | 15:29 |
| 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:30 |
| 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:36 |
| 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:37 |
| OvenWerks | and so the buffer size needs to have a lower limit | 15:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:44 |
| Eickmeyer | Ok, interesting. | 15:45 |
| 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:47 |
| Eickmeyer | Unfortunately not everyone's machine can do that. | 15:59 |
| 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:00 |
| OvenWerks | yup | 16:03 |
| OvenWerks | and as we found yesterday, high core machines have limited low latency ability | 16:04 |
| Eickmeyer | Which makes sense as they have to dedicate the IRQs to multithreading. | 16:05 |
| 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:07 |
| OvenWerks | However, the reality is, that use case matters | 16:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| Eickmeyer | wonko is turning into a bit of a leech. | 16:13 |
| OvenWerks | no worries, he has turned up a few bugs others will also find. | 16:21 |
| 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:22 |
| 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:23 |
| OvenWerks | https://bugs.launchpad.net/ubuntustudio-controls/+bug/1844706 | 16:28 |
| ubottu | Launchpad bug 1844706 in ubuntustudio-controls "Many USB devices will not bridge correctly at latencies below 128 samples" [Undecided,New] | 16:28 |
| Eickmeyer | Cool. | 16:28 |
| OvenWerks | Eickmeyer: fix uploaded (two lines added) | 16:38 |
| * 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:39 | |
| Eickmeyer | The more you know. :) | 16:40 |
| OvenWerks | I seem to have forgotten what perl does | 16:42 |
| 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:49 |
| Eickmeyer | Yeah, that seems like a great idea. I feel as if rtirq hasn't been touched in forever. | 16:50 |
| 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:51 |
| Eickmeyer | YES! That might eliminate unneccesary xruns on the master device. | 16:52 |
| 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:53 |
| 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. | 16:54 |
| 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:32 |
| OvenWerks | sorry, I should have done that. | 17:52 |
| Eickmeyer | No worries. | 17:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!