Re: Changing the refresh rate of OpenAL
Chris Robinson <[email protected]>
| Newsgroups | gmane.comp.lib.openal |
|---|---|
| Message-ID | <[email protected]> |
On Sunday 29 November 2009 4:26:16 am Oleksiy Frolov wrote: > There was a statement earlier in the mailing list that OpenAL is not for > a low latency applications. But I don't see why one could not make it mix > faster (and consume more CPU), when necessary - to achieve a lower > propagation times ? Hi. The full delay/latency introduced by OpenAL is not exposed or settable through the API. The ALC_REFRESH parameter is the number of times it updates per second (or indirectly, a rough estimate of the period size with software mixing). However, that doesn't say anything about the delay between a command getting issued and it becoming audible. Increasing the number of updates per second won't necessarily affect the delay.. eg. an ALC_REFRESH of 20, with a buffer comprised of 3 periods, compared to an ALC_REFRESH of 40, with a buffer of 6 periods. The latter has twice as many updates per second, and will be more responsive, but the overall latency is still roughly the same. Currently, OpenAL Soft does not support setting the ALC_REFRESH attribute. However, there are changes coming that should make it possible to take the default period and buffer sizes down, noticeably decreasing latency (some of it is already in place in the latest Git/SVN). You can change the buffer and period size settings with a config file, though. See here: http://repo.or.cz/w/openal-soft.git/blob/HEAD:/alsoftrc.sample _______________________________________________ Openal mailing list [email protected] http://opensource.creative.com/mailman/listinfo/openal