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