I've been using Ardour with my Echo Audiofire 12 on Elementary OS. I've noticed that the latency seems to 'drift' by about 10 ms and then snap back every 10 minutes or so. I decided to get a bit more analytical and compare the behavior to an RME HDSPe AIO sound card and a Behringer Xenyx UB1202 USB mixer. The results are below.
- Intel Core i7 9700K 8-core non-multithreaded CPU
- AsRock Z390-ITX motherboard
- StarTech PCI Express Firewire card with TI XIO2213A/B/XIO2221 firewire chipset. This card contains a PCIe to PCI brigde as well, from the info of lspci.
- Linux kernel: 4.15.0-50-lowlatency
- Echo Audiofire 12 Firewire interface
- RME HDSPe AIO PCIe interface
- Behringer Xenyx UB1202 USB mixer
This is a recording of the click track in ardour which I then re-recorded multiple times on new tracks (each time recording only the original one again). You can see the behaviour of the drift-and-snap-back here in an informal way. The top track is the original, the ones below are re-recordings of it. I zoomed in to show a single click from the track:
I ran jack_delay on the interface for more than an hour, and recorded the measurements. I visualized them in this chart. You can clearly see the latency increasing and snapping back each time:
Zooming in a bit, we can see the step-wise increases in latency:
Displayed as a number of samples, the jumps are pretty constant at 8 samples each jump:
Comparisons to other sound cards on the same computer
Compared to the RME sound card, which is completely solid (this was for about 30 minutes):
And the Behringer USB mixer, pretty solid too (notice the sub-millisecond differences in the scale on the left):
Wondering what could be the problem, I ran jack_delay again and looked at the QJackCtl message log. Every time the "snap back" occurs, there is an XRun at exactly that moment.
I can think of the following theory of what might be going on:
- The clock source of the FireWire card and my PC are not in sync, causing the samples to slowly drift, eventually leading to an empty buffer and requiring a refill. If the PCs clock is slightly faster than the Interface's clock, the samples might not be entering the buffer fast enough, eventually leading to a buffer underrun and the system waiting for new data, and the process starting over again. Does this make any sense?
- The LED on the front of my Audiofire indicate that the clock source is INT. There is also an LED for "1394", which is not lit. I remember this LED being on when connected to my Mac which I was using before my Linux PC. Could this indicate that, indeed, the clock is not properly synced with the PC?
Thanks for your any insight you might be able to provide.