This is more jack related than ardour but I’m hoping to get it working with ardour once I fix this issue…
I’ve spent the past few days/nights trying to put together an Arch Linux system together that loads up my jack routing, an instance of Pd and Carla and MIDI inputs/outputs using a2jmidid. It’s working really well except for the fact that about once every 5-10 minutes of playing synth plugins (I’m using Helm and ZynAddSubFX) loaded up in Carla, there will be a sudden deluge of xruns and all audio chokes up for about 30 secs - 1min. Watching the xruns in Cadence it can get up to >5000 very quickly. Then suddenly it will play all the MIDI notes I hit while it was chocked up, as if they had been recorded and played back… and once that finishes it’s all back to normal again for another 5-10 mins. Very odd! Having a look in the Jack logs these are sometimes reported but often it doesn’t show any errors at all.
I figured it must be some real time issue, some process interrupting periodically but I don’t really know what to do. I’ve used the realTimeConfigQuickScan and gone through the results of that to make sure everything is listed as “good” - the only thing I’ve left to do is install a real-time kernel. From what I’ve read though, I understand that these days the RT kernel shouldn’t be necessary. And I should point out that this behaviour occurs when Cadence is registering a DSP load of <10%. So the computer is hardly stressed it would seem!
I’m currently building the RT kernel package and will give it a go tomorrow but would love to hear any suggestions to fix…
RT kernels can be flaky, I’ve had nothing but problems with them. RT kernel is not needed, I’ve been running on a standard low latency kernel for years with no problems with xruns.
You could try disabling wifi. If it is built into your motherboard it might be connect through USB and interfere with USB audio cards.
Power savings might be another thing to look at. Disable any powersaving feature you can find.
If you are on Linux and you use a USB audio device you can check which of your USB ports use the same USB bus and put your audio device to a bus where there are no other devices. You do this by plugging for example a mouse into one of the USB connectors and checking with: lsusb which bus it is on, then move the mouse to another connector and run lsusb again.
Thanks mhartzel - switching USB solved it! I was using a USB 3 port with the (USB2) audio interface and it looks like that was the problem. Looks like pretty much all new PCs/laptops only offer USB 3 these days so I hope this is only an issue with older USB busses/interfaces…
I needed to disable USB 3 on two of my new computers (3 and 2 years old) to get USB2 sound cards to work properly. After disabling USB 3 in the UEFI the USB ports all reverted to USB 2. I also had USB 3 disk corruption while running the ports on USB 3 under Linux.
@mhartzel, can you give more info on the computers that necsessitated disabling USB3 in the UEFI? I am curious what motherboards, chipsets, etc. were problematic…or is this a Linux kernel issue?
I did some further testing using a Focusrite Scarlett 2i4 on machines running Linux and Windows 8.1 and Windows 10. Interestingly, on both Windows machines the interface would not work at all on the USB 3 ports - it wouldn’t even power up. On USB 2 ports it was fine running on Focusrite’s Windows driver. So it seemed like Linux was actually doing a much better job of at least detecting the device and running it as a class compliant device, even if there were some glitches using the USB 3 ports. I may have to try reinstalling the Windows drivers though as Focusrite does say that their devices should work fine on USB 3.1 ports (maybe not 3.0? I’m not sure exactly…).
I’ve been researching this and testing various combos as I’m looking to soon purchase a new laptop + interface soon to replace my ancient Macbook Pro and Firewire interfaces. From what I’ve read on various forums it looks like the two best options currently available are the RME UCX and MOTU AVB interfaces. The UCX has the limitation that you can’t access the onboard mixer/dsp in Linux and the MOTU doesn’t seem to like USB 3 unless you have the official (Windows) driver (see Fernando’s post at http://linux-audio.4202.n7.nabble.com/Motu-1248-Full-success-td103577.html). I don’t know how well the UCX runs on USB 3 ports under Linux.
Anyway it seems like a pretty major issue seeing as pretty much all laptops now only offer USB 3 ports. Do I have to check the UEFI of every laptop I consider purchasing to check if there is an option to disable USB 3 and run as USB 2? I’ve now successfully set up an excellent Linux based sound production/performance system on an older laptop that is a far better working environment than anything I’ve ever experienced on Windows/Mac. The final hurdle to getting it to work on a newer system seems to be USB 3…
On my Asus laptop USB 3 is disabled by setting: Legacy USB Support = On. On my Acer laptop USB 3 is disabled by setting xHCI support = Off. After this all ports on these devices work in USB 2 mode.