Skip to content
This repository has been archived by the owner on Mar 27, 2020. It is now read-only.

Latency information #16

Open
Skrylar opened this issue Mar 16, 2019 · 1 comment
Open

Latency information #16

Skrylar opened this issue Mar 16, 2019 · 1 comment

Comments

@Skrylar
Copy link
Owner

Skrylar commented Mar 16, 2019

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.

@Skrylar
Copy link
Owner Author

Skrylar commented Jul 9, 2019

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant