-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
Remove Sync restriction from jack::ProcessHandler #121
Comments
Thanks for looking at this, I ran into this problem when trying to implement JACK as a backend for CPAL (RustAudio/cpal#389). A Mutex would be required to access the closure doing the audio processing to comply with the CPAL API. To me it makes no sense for the audio process to be called from two different threads at the same time unless the audio processing is entirely stateless. A multithreaded audio processing context would require a very conscious design (such as Supernova for SuperCollider). If the processing has state one of the threads has to block until the other thread releases that state. So we write code that assumes the Mutex guarding the state will never be contended, defeating the purpose of having the ProcessHandler be Sync in the first place. |
I've just had a discussion on IRC in 04:46 < Windfisch> just to be clear: client1's processcallback runs concurrent to itself? to client1's process callback? Seems to me that we can lift the Sync restriction. |
I've checked the source code. I am absolutely sure that the ProcessHandler only must be Send, not Sync. I am not sure if the same holds true for the NotificationHandler. Process, Sync and Timebase callbacks are (transitively) called through All others are handled as |
This partially reverts 356aec6.
This partially reverts 356aec6.
See PR #127 which implements this. |
Based on the Jack Wiki, the ProcessHandler should only be called from the audio processing thread, therefore meaning that the current
Sync
restriction should be lifted. I am aware this was originally put into place due to #104, however I have done further testing (specifically, mapping out which threads certain handlers are called on) and have found the following results:Output is from a program I threw together - source in gist
As you can see,
thread_init
is called from all three created threads, whereas the audio processing callback is only called on the one (presumably RT audio) thread. I am working to see if I can get this solidified as a guarantee in the API that this callback will only be called on one thread at any one time.The text was updated successfully, but these errors were encountered: