You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 27, 2020. It is now read-only.
JACK expects us to inform it how long it takes a signal to enter and finally exit Rack. I assume this information gets used for delay compensation since I've never had to deal with plugin latency using it.
The text was updated successfully, but these errors were encountered:
It would be nice to fix this, but getting it 100% would require some serious jankery.
We would have to change to locking up Rack until a process cycle has occurred (currently we allow them to occur but lock it up when an input/output buffer is full), then do some magic with mutexes/conditions to process a full audio block which then re-blocks Rack and passes the results off. That would bring us to parity on the app side.
Within Rack there are single sample delays for each cable, and no easy way to know how many cables from the input to an output. There are some theoretical ones, and some blunt ones, but eh...
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
JACK expects us to inform it how long it takes a signal to enter and finally exit Rack. I assume this information gets used for delay compensation since I've never had to deal with plugin latency using it.
The text was updated successfully, but these errors were encountered: