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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.