[02:39] <OvenWerks> wonko: I am not sure where to go next. Disabling xhci seems the best next step.
[02:51] <OvenWerks> wonko: Also it would be good to try and figure out if anything is happening behind the scenes on your system when that happens witch generate high network or disk activity.
[02:52] <OvenWerks> wonko: maybe try running with cron truned off and the network disconnected.
[02:53] <OvenWerks> Also network "enable" in the network dropdown unchecked.
[02:56] <OvenWerks> They may be at a lower priority than your audio device and applications but both cron (updates) and networking deal with large packet sizes which may be done atomically and so could interfere with audio by holding the wrong CPU.
[02:56] <OvenWerks> I don't think an IRQ server can change the cpu it is on once started.
[02:57] <OvenWerks> (rememebr we saw that the irq server for your sound card's xhci process had all it's interrupts on the same cpu)
[14:22] <wonko> OvenWerks: I'm pretty sure it's not network. If I'm downloading a torrent I can push 1Gbit easy and it doesn't affect jack at all.
[14:23] <wonko> and lookking at the interrupts it's almost entirely on one core. One other core get's a *small* number of interrupts, but mostly all on one.
[14:24] <wonko> that small number could be IRQ 18 though
[14:24] <wonko> wait, no
[14:24] <wonko> duh, ignore that. :)
[14:26] <wonko> https://paste.ubuntu.com/p/cR8F98hFwS/
[14:26] <wonko> That's jack restarts
[14:27] <wonko> They're pretty random looking and like they wouldn't line up with cron processes
[14:28] <wonko> xruns: https://paste.ubuntu.com/p/r2WJYYpBV2/
[15:33] <OvenWerks> That does not look like jack restarts (the first log bit) it is controller checking if jack is still running and, oh by the way, what is the dsp time being used. That _is_ something to fix in the next version of controls.
[15:34] <OvenWerks> Anyway it is not a problem aside from too much logging
[15:37] <OvenWerks> wonko: the second paste is xruns. (at what buffer size?) Maybe turn off USB bridging so the webcam does not interfere? Try unplugging the webcam also just to see if it makes a difference.
[15:39] <OvenWerks> it appears I need to have another set of boxes for usb devices that should or should not be bridged.
[16:13] <wonko> OvenWerks: From what I can tell it prints that line every time it restarts. Maybe I'm wrong and you can help me figure out how to determine restart time from the log?
[16:14] <wonko> for the xruns it's 128/2
[16:14] <wonko> I kinda need USB bridging for the audio device though. I can unplug the camera though.
[16:15] <wonko> DSP hovers around 13% while not actively doing much in the way of audio
[16:16] <OvenWerks> not at all, those are very definately not restarts. A jack restart would show all the settings (sample rate, buffer size, device etc)
[16:18] <OvenWerks> DSP is dependent on buffersize and sample rate. There is (once jack is started) always audio activity. Jack has to deal with audio even if it is silent it has to deal with all those zeros.
[16:19] <OvenWerks> jack graph complexity and for that matter jack client complexity will also effect DSP.
[16:30] <OvenWerks> (even if no audible audio is happening)
[16:32] <OvenWerks> Some plugins do use more dsp when the audio is more complex than silence, but many do not.
[16:54] <wonko> https://paste.ubuntu.com/p/cTPYQjXtN3/
[16:55] <OvenWerks> you are still having trouble with memlock
[16:56] <wonko> Oh, that's pre-upgrade
[16:56] <wonko> I just copied an example
[16:56] <wonko> like, that configuring for line, that's jack starting?
[16:57] <OvenWerks> creating alsa driver ... hw:MK2,0|hw:MK2,0|1024|2|192000|0|0|nomon|swmeter|-|32bit
[16:57] <wonko> https://paste.ubuntu.com/p/SVBz8hsss5/
[16:57] <wonko> that's just today's logs if you're interested
[16:58] <wonko> wonko@deepthought:~/.log/jack $ grep "Wed Oct  2" jackdbus.log | grep "creating alsa driver" | wc -l
[16:58] <wonko> 9
[16:58] <wonko> so 9 restarts today?
[16:59] <wonko> grep "creating alsa driver" jackdbus.log : https://paste.ubuntu.com/p/hKZs9kJZ32/
[17:04] <OvenWerks> wonko: ps x |grep auto
[17:05] <wonko> https://paste.ubuntu.com/p/mY7PbKSF8p/
[17:05] <wonko> oh wait
[17:05] <wonko> that's a ton of chrome nonsense
[17:05] <wonko> let me filter that out
[17:05] <wonko> https://paste.ubuntu.com/p/NbdtNcfGND/
[17:07] <OvenWerks> also can you paste ~/.log/autojack.log
[17:08] <OvenWerks> How are you managing to get 2 autojacks running?
[17:08] <OvenWerks> how can I replicate that?
[17:11] <OvenWerks> I don't think that is causing restarts, but it is giving you extra bridges and other odd things
[17:13] <wonko> yeah, I've got double bridges, I saw that
[17:13] <wonko> that happened once before a long time back
[17:13] <wonko> autojack.log is HUGE
[17:13] <OvenWerks> I had fixed it
[17:13] <wonko> how many days back would you like?
[17:13] <wonko> or I can just compress it and stick it on dropbox
[17:13] <OvenWerks> which ever
[17:14] <wonko> I think it's too big for paste.ubuntu.com because I get a 502 when I try to send it with pastebinit
[17:14] <OvenWerks> just today's would probably be enough
[17:14] <wonko> I already sent you that. :)
[17:15] <wonko> This one is today's only: https://paste.ubuntu.com/p/SVBz8hsss5/
[17:18] <OvenWerks> Thats jack.log I want autojack.log
[17:22] <wonko> https://paste.ubuntu.com/p/SwJMbwnqRY/
[17:35] <OvenWerks> sorry went away a bit for a reboot
[17:39] <wonko> no worries, IRC is async. :)
[17:39] <wonko> And I'm fighting more than one battle today
[17:39] <wonko> the motherboard for the new fileserver I was building doesn't power on. :(
[19:31] <wonko> OvenWerks: I can try plugging the KA6 directly into the computer without an extension of any kind and see if that changes anything. If it doesn't that means it's something super annoying most likely. :)
[19:32] <OvenWerks> wonko: what I see in the above log is: sound card: hw:1 removed followed by a failed jack startup (which should get fixed in controls) and then shortly thereafter: a switch master (means it detected a plugin event)
[19:34] <OvenWerks> Jack should not start up with a non-existant device.
[19:34] <wonko> ok, so I've moved the KA6 out to where the computer is
[19:35] <wonko> I stopped jack from controls
[19:35] <wonko> how many autojack should I have?
[19:35] <wonko> 1 or 0?
[19:35] <wonko> because I have 2
[19:35] <wonko> :)
[19:35] <OvenWerks> wonko: there should always only be one
[19:35] <wonko> If I kill both will controls do the needful?
[19:36] <wonko> alternatively should I possibly restart my X session just to be safe?
[19:36] <OvenWerks> you can kill both
[19:36] <OvenWerks> controls will restart one
[19:36] <wonko> ok, I've got none
[19:37] <wonko> now to zero out log files so we don't have old junk in there. :)
[19:37] <OvenWerks> if it starts two then I want to know
[19:37] <wonko> Ok, so I have no autojack and I've cleared out log files.
[19:37] <OvenWerks> the autojack.log file will be cleared when autojack restarts
[19:37] <wonko> Is there anything else I should be doing before I hit start?
[19:37] <OvenWerks> not that I can think of
[19:38] <wonko> I'm being extra overly cautious here about all this. :)
[19:38] <wonko> uh
[19:38] <OvenWerks> I am noticing that with 19.10, the autojack that starts at session start doesn't seem to log properly :/
[19:38] <wonko> clicking the start or restart button in controls isn't doing anything
[19:39] <OvenWerks> Takes a while
[19:39] <wonko> I don't think it takes this a while
[19:39] <OvenWerks> it is slower when when it has to restart autojack
[19:39] <wonko> Ok, I'll be patient then
[19:39] <wonko> hard for me. :)
[19:40] <OvenWerks> it should have started by now though
[19:40] <wonko> ok, i'm going to kill and restart controls
[19:40] <OvenWerks> you should be able to start it from a terminal
[19:40] <wonko> ah yes, that did it
[19:40] <wonko> it did the button half highlights hanging thing I'm used to. :)
[19:40] <wonko> wonko@deepthought:~/.log $ ps -ef | grep jack
[19:40] <wonko> wonko      821  8864  0 15:40 pts/1    00:00:00 grep --color=auto jack
[19:40] <wonko> wonko    55967 54756  0 15:40 ?        00:00:00 /usr/bin/python3 -u /usr/bin/autojack
[19:40] <wonko> wonko    55986 52936  4 15:40 ?        00:00:00 /usr/bin/jackdbus auto
[19:40] <OvenWerks> that would show any errors to the command line
[19:41] <OvenWerks> yup that looks right
[19:41] <wonko> I'm going to launch Carla/Ardour and then we wait. :)
[19:41] <OvenWerks> controls should be showing dsp
[19:42] <wonko> 15-20 or so
[19:42] <OvenWerks> carla/patchage/jack_lsp/qjackctl should only show one set of bridges
[19:42] <wonko> yes, there are only one set of bridges
[19:43] <wonko> so now.... we wait. :)
[19:45] <OvenWerks> autojack is going get some code that when it sends an alive signal to controls it will also send a siganl to itself with its PID... if it gets two pids back it will kill the second it gets... or kill itself if it's own comes back second
[19:47] <wonko> Is PID return order going to be correct?
[19:48] <OvenWerks> wonko: it doesn't matter, so long as both autojacks get it in the same order, one of them will go.
[19:48] <wonko> I'm just thinking, you'll have PulseIn and PulseIn-01 so you need to make sure you kill the correct one.
[19:49] <OvenWerks> wonko: in that case it is just module unloading. That module unloading happens automatically if jack dies and I kill all of them if we change something.
[19:49] <wonko> ok, so it doesn't link an autojack process to a set of bridges
[19:49] <wonko> so killing either one gets rid of the -01 set?
[19:49] <OvenWerks> PulseIn (the first one is always reconneted to the default output
[19:50] <OvenWerks> yes
[19:50] <wonko> ok, that was my concern but seems it was unfounded.
[19:50] <OvenWerks> This is true for a2jmidid and alsa bridges as well (though they are killed by pid)
[19:51] <OvenWerks> (the alsa bridges are) and we kill -9 jackd jackdbus a2amidid as well.
[19:58] <OvenWerks> wonko: I think I will actually have the two autojack thing happen before sending the ok back to controls. That way if for some reason both kill themselves controls will restart one
[20:00] <wonko> oh, good thinking
[20:00] <wonko> ok, 100% not the cable
[20:00] <wonko> jack just restarted
[20:00] <OvenWerks> wonko: this is not likely to happen before 19.10
[20:00] <wonko> I've stopped jack with controls
[20:00] <OvenWerks> There are soe things I can do about that too.
[20:01] <wonko> what is useful to you
[20:01] <wonko> I'm on 19.10. :)
[20:01] <OvenWerks> maybe start jack with qjackctl and see if jack stops or crashes.
[20:03] <OvenWerks> I am thinking for restart I have set it not to restart if there is a new device that is the same device as the current device. It may be that I also need to check in the case of a device removed if the device is actually gone.
[20:07] <OvenWerks> That is why I want to know if it does bad things when started with qjackctl (or jack_control start should work too)
[20:07] <wonko> Ok, started it with qjackctl
[20:07] <wonko> I'll just let it go and see what happens.
[20:07] <wonko> qjackctl needed configuring and none of my pulse bridges are there
[20:08] <wonko> will that be an issue?
[20:08] <OvenWerks> it may be that the device resets itself sometimes and jackd normally ignores that
[20:08] <OvenWerks> it should not... a little less stress on the system but still.
[20:08] <wonko> Uh, I'm getting audio into Ardour even though nothing is routed into it?
[20:08] <wonko> from tha KA6 mic
[20:09] <OvenWerks> are you sure?
[20:09] <OvenWerks> ardour does do some auto routing
[20:09] <OvenWerks> are you using the ka6 as the default device in qjackctl?
[20:10] <wonko> the meters move when the mic picks up sound, so I'm pretty sure. :)
[20:10] <wonko> probably?
[20:10] <wonko> well, I mean, it's the only device, so it has to be the default, right?
[20:11] <OvenWerks> ok yes
[20:11] <OvenWerks> so ardour has connected itself to system_1 capture then
[20:12] <OvenWerks> it would normally connect system_1 to the first audio track and system_2 to the next etc
[20:13] <wonko> ok, that makes sense then
[20:16] <OvenWerks> It also depends on how the audio device is set up... but in that case you would hear the mic before starting jack