JACK xrun flood (started this morning, used to work)

[Fishbreath]

So, I have two USB microphones I use for podcasting and music recording, and up until this morning, I had a working setup using Mint 18: add alsa_in clients for the microphones, recording via an alsa_out client hooked up to the ALSA loopback device. Without any changes to the default system (so no realtime), I was able to do 256 frames/2 buffers with no xruns to speak of.

That all changed today. I had to restart my laptop, and now I can hardly find a working configuration at all. 256 frames/2 buffers generates about 110 xruns per second. Even in realtime mode, no combination of frames/buffers below 2048/2 works without an xrun flood, and only 4096/2 works with zero xruns (realtime or not). If I use three buffers instead (128/3 or 256/3 e.g.), I don't get the xrun flood when JACK is running, but with any number of buffers besides two, my microphone alsa_in clients don't work, filling the logs with this error:

JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = cad was not finished, state = Triggered

In short, the only two working scenarios are:

1) set a mic the JACK input device in QJackCtl/when starting the server, which means I can only have one microphone, and
2) use two alsa_in clients with extremely high latency, which is functional, but which means I lose the real-time monitoring, which was the biggest win using JACK in the first place.

Once or twice, I stumbled across some working configuration with one microphone set as the JACK input device on server start and the other as an alsa_in client, but wouldn't that cause me trouble with sample rates and clock drift in the microphones? In any event, I can't find a way to make that happen reliably.

Anyway, I'm nearing my wit's end here, and since I found some similar threads in the history here (whose solutions have not, unfortunately, fixed my problem), I figured I would see if anyone has any advice. Thank you!

[CrocoDuck]

Oh noes! That sucks!

Did you reboot because an update or similar? If so, that could be the cause. If you updated the system, try to see if you can get a log of the upgraded packages. Chances are that either a new version of something doesn't play very well on your system or a conf file was overwritten with not a very good configuration for audio.

Very often xrun flood is caused by wifi. If you have wifi hardware, try to turn it off or modprobe out its kernel driver.

[Fishbreath]

Oh noes! That sucks!

Yup. To rub salt in the wound, I discovered it was broken while writing a blog post about how to do it.

Did you reboot because an update or similar? If so, that could be the cause. If you updated the system, try to see if you can get a log of the upgraded packages. Chances are that either a new version of something doesn't play very well on your system or a conf file was overwritten with not a very good configuration for audio.

Potentially. The only deep-in-the-system thing which changed was dbus, but if I squint, I can see how that might cause trouble.

Very often xrun flood is caused by wifi. If you have wifi hardware, try to turn it off or modprobe out its kernel driver.

Alas, yanking the kernel modules for bluetooth and wifi had no effect.

This is pretty crazy. Not only does it not work like it did yesterday, it's so broken that not even Jack Rack can connect to JACK-with-three-buffers without causing the xrun-process-error-triggered spam. I have half a mind to uninstall and reinstall everything and see if that helps at all.

[CrocoDuck]

I have half a mind to uninstall and reinstall everything and see if that helps at all.

Might actually be the easiest path. I would also maybe try something like AVLinux live, just to see whether it is a software issue. There is also the possibility that some hardware component suddenly broke or started malfunctioning, either in your mics or in the USB hubs and controllers (or somewhere else entirely)...

[gimmeapill]

On the HW side, that *could* have to do with the detection order of the USB devices and/or IRQs assignment. The usb detection order at boot is usually a happy mess, and the behavior seems to evolve from time to time with the kernel or udev.

So, try a cold boot with your USB mics disconnected and connect them one by one to see if there's any order that makes things better / worse (it might also be worth looking at what happens in dmesg at the same time + what kernel module is needed for which device).

If that ever helps, you can then make the order persistent across reboots by specifying indexes in your alsa-base.conf.
Regarding the IRQ Assignment, it would be worth checking first if they are all stuck on the same IRQ for example.

[Fishbreath]

Thanks for the advice, guys. I tried a bunch of things with plugging in the microphones in a different order and checking IRQ assignments, but couldn't turn up anything obvious. Instead, I found room on my HDD for a partition for AVLinux to live in, and that's perfectly happy both doing low-latency stuff and recording to my other partition, so I'm going in that direction.

Thanks again!