I’m using Ardour with USB audio interface and Jack backend, tuned the system and it’s rock solid in terms of xruns when playing or recording. Except when adding/removing tracks or sends/effects. For example, inserting a send into the channel generates almost exactly 15 xruns when Jack is set to 44,1 kHz @ 64/2 (even in a blank, just-one-channel session with 3% DSP usage). Of course, increasing the buffer size somewhat lowers the number of xruns but they still occur every time something is changed in audio connections.
As it is described in this thread, this is somewhat normal because all above operations aren’t realtime safe:
But the question is: can something be done to prevent Ardour reporting such “spurious” xruns? Although they are harmless in terms of audio quality, they make a kind of distraction. Especially when in the middle of the session you out of sudden see a whole lot of them only to realize that they appeared because someone removed two plugins.
Using Ardour 7.3 from ardour.org but on 6.5 the behavior is almost the same (but surprisingly, number of xruns reported during every operation is a little bit lower).
There is an assumption built deeply into Ardour that changing connections does not need to free of side-effects.
If I could go back in time, I would probably revise this assumption. It is based mostly on how traditional studios work, and I still think that it is a valid model. But many people who work entirely “inside the box” (i.e. a DAW running on a computer) have become used to this idea that making connections should be glitch free, and if I was starting Ardour (and JACK) today, I’d likely go with this assumption instead.
Didn’t suspect such behavior is burden so deeply into Ardour/Jack architecture. And yes, one can argue that there’s no such glitches in other DAWs. Knowing all this now, I don’t think it is such a big problem, though.