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
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.
The text was updated successfully, but these errors were encountered:
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.
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.The text was updated successfully, but these errors were encountered: