[00:18] wonko: good. I did not put a logging message in to catch this particular problem. You may see extra "device = play: capture: [00:19] well, at this point zero log entries at all, so I guess that's good then. :) [00:19] If you see those in the log file and your setup doesn't quit/lockup/otherwise misbehave, then we have fixed it. [00:19] I'll check on it in the morning [00:19] I'll keep an eye out for those then [00:20] Thanks for fixing that, btw! [00:20] your welcome, thanks for pointing it out. === john40 is now known as lyth === Unit193 is now known as Guest17120 === Guest17120 is now known as Unit193 [11:14] OvenWerks: so far so good [11:14] https://paste.ubuntu.com/p/hXhk3rsrm8/ [11:16] oh, that thing in the udevd logs is the wireless mouse receiver, not the audio device. [11:16] so unrelated anyway [15:28] KaioHenriquebr was removed by: KaioHenriquebr [15:55] OvenWerks: It just happened again. :( [16:04] your log from last night shows a lot of xruns [16:05] which latency are you using? [16:05] and I forget, are you using the lowlatency kernel? [16:07] wonko: what does cat /etc/default/rtirq |grep RTIRQ_NAME_LIST show [16:10] wonko@deepthought:~/Documents/projects/BattleTech/RTWikiBot$ cat /etc/default/rtirq |grep RTIRQ_NAME_LIST [16:10] # RTIRQ_NAME_LIST="rtc snd usb i8042" # old [16:10] RTIRQ_NAME_LIST="snd usb i8042" [16:10] Linux deepthought 5.0.0-27-lowlatency #28-Ubuntu SMP PREEMPT Tue Aug 20 20:33:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [16:11] 128 latency [16:12] wonko you use your USB device as jack master? [16:13] If so, usb should be before snd [16:13] also usb should be changed. [16:13] I would guess you have USB mouse and kb? [16:14] usb device as jack master [16:14] yes on the mouse/kbd [16:16] your mouse is at the same (maybe higher priority as your audio. [16:17] That happens a lot if it's a mouse with a high pull rate, like a lot of gaming mice. [16:22] wonko: if you type usb-devices do you find that your Sound Device is on the same Bus as you r mouse? [16:22] does changing the USB plug you use on your computer change that? (it doesn't on my computer) [16:24] mouse: T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 15 Spd=12 MxCh= 0 [16:24] audio: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 13 Spd=480 MxCh= 0 [16:25] *everything* is on bus 3 [16:25] I only need usb2 for the KA6 [16:25] I should see if moving that to one of the usb2 ports would put it on a different bus (currently everything is plugged into the usb3 ports) [16:25] Yeah, the new mother boards route all the plugs to one usb bus [16:26] That means it is sharing time with whatever else is there. [16:28] nope, still on bus 3 [16:28] time to go plug the usb pcie card I have in. :) [16:28] yeah that may make a difference [16:29] I would be interested to know [16:30] should I update usb before snd as well? [16:30] i still need to find that card and make the time to stick it in [16:30] and remember what I did with the screws for the bulkhead [16:31] wonko: first you want to get your device on a different usb bus if you can... then do "usb3 snd usb" [16:31] assuming usb3 is your device usb...it may not be [16:31] it's a usb2 device, so that wouldn't be right [16:32] not the same thing. [16:32] in this case usb3 is the bus not the type. [16:33] oh, ok. [16:40] * OvenWerks wonders if using a usb 3.0 hub to plug in a USB 2.0 audio device would separate the audio device to another bus. [16:45] I don't think so [16:47] A USB3.0 device should get it's own bus... there are 4 buses those other three buses must be there for some reason [16:48] A USB3.0 hub should act as a 3.0 to 2.0 device. [16:48] that is, it should be a 2.0 host [17:08] usb card added [17:08] what a colossal pain in the ass [17:08] but, now the audio device is on its own bus [17:14] OvenWerks: should I tweak rtirq or do you want to see what happens now? [17:21] wonko: when you plug your audio device into that plug which usb bus does it end up on? [17:24] the new bus5 [17:25] http://paste.ubuntu.com/p/M3wK7BT9SW/ [17:25] http://paste.ubuntu.com/p/ks3FGGdprb/ [17:27] Cool! so change you rtirq line to "usb5 snd usb" [17:27] do I need to restart/reboot/etc to get that into effect? [17:27] (or whatever just make sure the plain usb is at the end) [17:27] yes [17:28] you would need to reboot [17:28] ok [17:28] you can run the rtirq again but it does not remove priority [17:48] wonko: what does /etc/init.d/rtirq status [17:48] show [18:03] lots. :) [18:04] http://paste.ubuntu.com/p/KHm2FvvVSj/ [18:09] wonko: That still shows snd on top [18:09] RTIRQ_NAME_LIST="usb5 snd usb i8042" [18:10] is what I put in /etc/default/rtirq [18:10] OK, so the usb5 trick doesn't work any more [18:12] we need to find out which of those irq goes to your audio device [18:13] (and wonder if it will stay there) [18:15] Mind ifirq18/38 is your card, that would be ok too [18:15] wonko: do you get less xruns? [18:15] how do I even check? I don't know without Claudia. :) [18:15] just check the log file? [18:16] is that the state = Triggered thing? [18:16] Huh, something else I should add to controls I guess [18:16] that would be nice. :) [18:16] it should show client not finished for an xrun [18:17] adding xruns would mean a redesign of a good portion of things [18:17] http://paste.ubuntu.com/p/bXJKDzZXH3/ [18:22] hmm [18:23] I would guess we are not quite there [18:23] rtirq does nto understand usb5. [18:30] wonko: there is another script that does similar to rtirq that may work better for you but it does not come as a package [18:31] I'm ok with that [18:31] Is any of this still valid: https://wiki.linuxaudio.org/wiki/system_configuration [18:32] some of that is out of date. [18:32] I ran that script and this is what "failed" [18:33] Checking access to the high precision event timer... not readable - not good [18:33] Checking access to the real-time clock... not readable - not good [18:33] Kernel with Real-Time Preemption... not found - not good [18:33] the rest all checks out [18:33] anyway, bbiab, need to get the kid from the bus stop [18:33] however, it does remind me of something... in -controls on the system tab [18:33] (system Tweaks) [18:34] make sure CPU governor is set to performance and boost (if it is changable) to off. [18:37] https://github.com/jhernberg/udev-rtirq [18:38] wonko: ^^ [18:46] first thing I did was set performance and boost off [18:47] so you guys aren't enabling threadirqs? [18:49] I don't know [18:49] something to find out [18:49] I don't see that you are, so I've added that [18:50] cool where? [18:50] I changed GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to GRUB_CMDLINE_LINUX_DEFAULT="threadirqs quiet splash" in /etc/default/grub [18:50] so looks like another reboot. :) [18:50] thank you [18:50] yes [19:09] ok [19:10] http://paste.ubuntu.com/p/Q4x2BpRqfb/ [19:11] no xruns so far [19:21] just got a couple [19:28] wonko: after a few reboots and so far no sign I actually changed the priority of anything by plugging in a usb device... [19:29] I have found that I can turn xhci off in bios after which my usb devices show up on different usb buses [19:29] hmm [19:29] interesting [19:29] so the bus is virtualized by xhci [19:29] where everything was on usb3 before, now my mouse is on usb2 and my audio is on usb1 [19:48] Ok better [19:48] now Quassel-Core won't restart every time I reboot my computer [19:49] oh no! [19:49] jack server restarted. :( [20:03] OvenWerks: Who wrote Carla? you guys? [20:03] no falktx did [20:03] same as all the kxstudio stuff [20:04] It would be nice if it reconnected to jack when it came back. Minor annoyance though, nothing serious [20:04] I haven't found any application that does that... [20:06] The only way to do that I know of is to keep trying to reconnect and fail till it comes back [20:06] bugging jackdbus via dbus may work too, but seems not too rliable. [20:18] Ah well, would have been nice, but again, not a major issue [20:20] major issue being that jack crashed even with all this new stuff going on. :( [20:23] xruns being way down is awesome though [20:31] The udev-rtirq doesn't seem to work for me [20:33] I was able to more my usb irq by hand: http://paste.ubuntu.com/p/RHGxDRd7s7/ [20:34] irq20 is my USB1 and irq23 is sub2 [20:35] how do I find out which irq maps to what? [20:37] I mean, xruns are *way* down, so that's good [20:37] when I did: cat /proc/interrupts I got 20: 2810586 0 30 0 IO-APIC 20-fasteoi ehci_hcd:usb1 [20:37] so maybe it's not super important and is "good enough"? [20:38] I have 56 cores. That's some ugly output. :) [20:38] I guess it depends on what you are doing. [20:38] 56 cores? that may be the problem [20:39] The low latency tests I have seen tend to favour fewer cores [20:39] Also hyperthreading will raise the lowest latency [20:39] Well then I'll be happy with the results I have now. :) [20:40] I don't even see usb5 in /proc/interrupts [20:40] I purposely bought an i5 with 4 cores and no hyperthreads rather than the i7 [20:40] irq19 is usb1 and usb3 [20:41] irq18 is usb2 [20:42] one of the ehci/xhci must be your pcie card [20:43] I would say one of the 4* ones [20:44] 18 and 38 will be linked and 19/39 too [20:44] can I expect zero xruns to be a reasonable goal or is 5 every couple of minutes not terrible [20:45] I don't know, try going from 128 to 256 for buffer size [20:47] I am pretty sure there some more tricks [20:49] I do know that I can do better with what I have. I haven't done a lot of testing lately so I don't know what newer kernels and even this MB are good for. I used to be able to get down to a buffer size 16 with no xruns for hours. [20:49] but that was with a pci audio device [20:52] You can see that have a whole lot shorter irq list too. All of those megasas and ens1 things you have listed must be one per core. [20:53] tying you irq for your usb device along with your audio chain to one core might do wonders too. I know of people who have gotten their buffer size to less than 64 (32/3 I think) even with a usb device [21:23] wonko: I wonder if the webcam is causing any odd stuff. [21:23] Yeah, let's not get crazy just yet. Mic should be here Monday. Then I'll stop using the webcam [21:23] Then we'll see what happens [21:24] And leave CPU pining for last. 😁 [21:24] maybe the webcam doesn't like 64 for a buffer [21:24] cpu pinning is a task and a half I think [21:24] And I don't know if it would help anyway. [21:25] What I do know is that you seem to have 128 extra irqs that most cpus don't have [21:26] I don't know how often they have to tale to each other, but that may be enough to do things. [21:26] s/tale/talk/ [21:37] The joys of not having desktop CPUs