search

jackaudio / jackaudio.github.com

jackaudio's Website and Wiki hosted at github
457 stars 77 forks source link

FAQ omits that async mode adds a period of latency #138

Open Be-ing opened 3 years ago

Be-ing commented 3 years ago

https://jackaudio.org/faq/no_extra_latency.html currently says:

Does using JACK add latency? There is NO extra latency caused by using JACK for audio input and output. When we say none, we mean absolutely zero. The only impact of using JACK is a slight increase in the amount of work done by the CPU to process a given chunk of audio, which means that in theory you could not get 100% of the processing power that you might get it if your application(s) used ALSA or CoreAudio directly. However, given that the difference is less than 1%, and that your system will be unstable before you get close to 80% of the theoretical processing power, the effect is completely disregardable.

We have done some experiments with Mixxx to verify this and found it not to be completely correct. JACK2 in asynchronous mode adds one period of latency compared to ALSA. The only documentation I could find about the difference between synchronous and asynchronous modes was buried on the wiki page comparing JACK1 and JACK2:

JACK2 can run in 2 different modes : "asynchronous" when the server does not wait for graph end for a given cycle but just write the outputs computed at the previous cycle. In this case an extra period of latency is added. JACK2 can also be run in "synchronous" mode, when the server waits for the graph activation end in a given cycle, in which case it works like JACK1.

Practically, I don't know what this means as a user. What advantage does asynchronous mode bring that is worth the cost of an extra period of latency? If there is none, or it is only beneficial in edge cases, it should not be the default.

Be-ing commented 3 years ago

ping?

falkTX commented 3 years ago

contributions welcome :)

falkTX commented 3 years ago

and some small short explanation: async adds extra buffer so that bad clients to not make the whole graph produce noise. a chain of connections from a bad client does not end up on the final audio buffer sent to the soundcard. this allows to keep audio rolling without any perceived noise or artifacts or similar if a client misbehaves. that said, if you only use a single client or connect everything in series, there is no gain in the end.

Be-ing commented 3 years ago

Can you clarify what you mean by "bad client"? What does a client have to do to mess up the whole graph?

I'm questioning why it is the default to add latency. I think this is very unexpected, especially considering the website has said for a long time that JACK adds zero latency.