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.

Sign up for GitHub

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

Jump to bottom

Review and possibly improve FlexASIO buffer management #40

Closed
dechamps opened this issue Jan 20, 2019 · 0 comments
Closed

Review and possibly improve FlexASIO buffer management #40

dechamps opened this issue Jan 20, 2019 · 0 comments
Assignees
@dechamps

Comments

@dechamps
Copy link
Owner

In the context of developing ASIO401 I ended up writing a document that explains how to do ASIO buffer management properly - because of ambiguities in the ASIO SDK docs this is not nearly as trivial as one would think.

We should review FlexASIO and ensure it follows these guidelines. At first glance it already seems to be doing most things correctly, but we probably want to support ASIOOutputReady() to improve latency.
@dechamps dechamps self-assigned this Feb 2, 2019
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
Get the bufferSwitch timestamp as soon as possible.
d4be476 
The previous code was completely wrong - it would update the
timestamp right after bufferSwitch returns, which is pointless. As
a result the timestamp would be off by one period.

See #40.
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
Fix output latency calculation not including the buffer switch time.
8679c2f 
PortAudio-reported output latency is calculated from the time of the
stream callback. But once the ASIO Host Application generated an
output buffer, it will only be delivered to PortAudio at the *next*
stream callback. We have to take that additional period into account
in the total output latency, as explained in the ASIO SDK docs (see
ASIOOutputReady) and in dechamps_ASIOUtil/BUFFERS.md.

See #40.
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
Don't wait for the next stream callback to copy the output.
eb79c78 
As dechamps_ASIOUtil/BUFFERS.md explains, as soon as bufferSwitch(A)
returns, we can use buffer B. So let's just copy the data from B as
soon as possible, instead of waiting for the next callback for no
reason.

This should decrease output latency by about a full buffer length.

See #40.
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
Add support for ASIOOutputReady().
000954f 
This will reduce the output latency by a full buffer length in ASIO
Host Application that support OutputReady.

See #40.
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
Set directProcess to true in the bufferSwitch callback.
f00889a 
PortAudio fully expects that processing will occur within the
callback. Advising ASIO Host Applications to defer processing will
only hurt performance.

See #40.
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
Mention dechamps_ASIOUtil/BUFFERS.md in a code comment.
b3f9ed0 
See #40.
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
When OutputReady is enabled, send buffer 1 during priming.
f5f1cb6 
Otherwise the initial buffer 1 would be skipped.

See #40.
dechamps added a commit that referenced this issue Feb 3, 2019
@dechamps
Tell PortAudio to ask for initial data instead of playing silence.
477571e 
From an ASIO API perspective this is fine - the ASIO SDK explicitly
allows one or more initial bufferSwitch calls for priming.

See #40.
@dechamps dechamps closed this as completed Feb 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dechamps dechamps

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@dechamps