Recently I became aware that the Jack Audio Connection Kit‘s second version, called Jack2, has a mode called “asynchronous mode“, which is different from Jack1’s mode of operation, now referred to as “synchronous mode”.
In “synchronous mode”, Jack waits for all the clients in the audio graph to finish their processing, and then outputs the result. If any client is late, this delays the audio of every client.
What the “asynchronous mode” does, is that instead of waiting for all clients to finish, Jack will proceed with whatever data it already has, even if one or more of the clients are not finished in time for the next cycle. This presumably has less of an impact on the sound, since clients that are finished in time won’t be “punished” by the clients that haven’t finished. Obviously the sound from the unfinished clients will still be affected (unless they are silent), but there is no way to avoid that.
As I was investigating some problems I was having, it became more and more apparent to me that asynchronous mode has several issues. The first undercommunicated piece of info is that running in asynchronous mode adds an extra period of latency. This is quite a big deal to low-latency setups.
The second issue (which at the time of writing is not documented anywhere as far as I can tell) is that it can cause audio sources to get out of sync with one another. This is because in case of xruns, clients that did finish in time will experience more cycles than clients that didn’t finish in time. What impact this has depends on what you’re trying to achieve. If you are playing instruments by hand in realtime, this has no impact at all, because it’s the wall clock time which matters. However, if you are running sequencers alongside one another, they are going to get out of sync with each other!
For me, this turned out to be a big issue, since I was playing back a track from one sequencer, and recording into another. Since this is a pretty heavy project, some xruns would always creep in, and this made my recordings useless, since the two sequencers are not in sync.
It took me a long time to figure out why, but it turns out to be the Jack2 asynchronous mode, which is the default mode of Jack2. After switching to synchronous mode (using the -s option), all my problems went away. In fact, it works better in a multitude of ways:
- Lower latency
- Sequencers stay in sync
- More stable audio
- Even performance is better!
I’m not certain why the audio is more stable, but it seems to me that clients that cause xruns, and therefore end up out of sync, tend to stay out of sync in asynchronous mode, whereas in synchronous mode, after the entire graph is stopped and started again, everything is in sync again. Also, I honestly have no clue why performance is better. Maybe synchronous mode is simply less work for the computer, and that leaves more CPU cycles available for the processing. Or it may be related to the stable audio. I don’t know.
Compared to the presumed benefits, I think the downsides outweigh them. Especially if you consider that asynchronous mode only helps in cases where you have xruns to begin with, which you shouldn’t have for robust setups. In cases where there are no xruns, asynchronous mode has nothing but downsides.
For these reasons I would personally recommend everyone to switch to synchronous mode, unless you are specifically suffering from xruns and the audio sounds better in asynchronous mode.