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

FlexASIO should be smarter about the default buffer size #20

Closed
dechamps opened this issue Oct 29, 2018 · 1 comment
Closed

FlexASIO should be smarter about the default buffer size #20

dechamps opened this issue Oct 29, 2018 · 1 comment

Comments

@dechamps
Copy link
Owner

dechamps commented Oct 29, 2018

Currently, FlexASIO reports a preferred buffer size of 1024 samples, a constant hardcoded value. Some host applications seem to use that without even giving the user a choice; see #19.

#19 is mostly about making that preferred buffer size configurable in FlexASIO so that users can compel host applications to use whatever buffer size they choose. However, I believe improvements can also be made to the default value, so that users don't need to care about the optimal buffer size in the first place.

One way to come up with a buffer size that is more likely to be optimal is to try to open a PortAudio stream with no buffer size set, i.e. paFramesPerBufferUnspecified, observe what buffer size we get back (also log the latencies too, that might be interesting), and just use that as the default size.

This might possibly get rid of some of the latency weirdness seen in #10, because it's likely PortAudio's behaviour in that regard will be more consistent if we give it the freedom to use the most appropriate buffer size.

One should keep in mind PaStreamInfo::suggestedLatency while experimenting with this. One would expect it to have interesting effects on the buffer size that PortAudio settles on.

@dechamps
Copy link
Owner Author

dechamps commented Nov 11, 2018

The new suggestedLatencySeconds option introduced in FlexASIO 0.5 can now be used to customize the suggested latency. Experiments show that this can have a dramatic effect on latency.

It looks like paFramesPerBufferUnspecified is not required to achieve close-to-hardware latency. For this reason there are no plans to introduce that, for now.

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

No branches or pull requests

1 participant