Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Be-ing opened this issue Mar 21, 2021 · 4 comments
Open

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

Be-ing opened this issue Mar 21, 2021 · 4 comments

Comments

@Be-ing
Copy link
Contributor

Be-ing commented Mar 21, 2021

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
Copy link
Contributor Author

Be-ing commented Apr 7, 2021

ping?

@falkTX
Copy link
Member

falkTX commented Apr 7, 2021

contributions welcome :)

@falkTX
Copy link
Member

falkTX commented Apr 7, 2021

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
Copy link
Contributor Author

Be-ing commented Apr 8, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants