Re: large and relative 3-d coordinate systems

On Sunday, November 07, 2010 8:26:56 am Ben Supnik wrote:
> So I found alcSuspendContext, which looks like what I want...I could
> call alcSuspendContext, set all my properties, and then call
> alcProcessContext.  Two concerns:
> 
> - In the ALSoft code, it appears that there is one AL-wide critical
> section.  Is there a risk of audio under-runs from calling
> alcSuspendContext?  Or is the double-buffer size for the AL usually
> large enough to avoid this?

Hi,

OpenAL Soft doesn't hold the critical section while the context is suspended. 
Once alcSuspendContext returns, the mixer is free to continue working. It only 
grabs the critical section to verify the context and set a flag on it. That 
said, the flag actually does nothing right now.

At one point, I had it so the functions would batch some changes. However, 
because the functions were so poorly defined in the original spec, the 
original Linux OpenAL implementation actually used them for a different 
purpose. So rather than risk breaking existing apps, it was decided that 
suspend/process should continue to do nothing on Linux.

Something I'll likely do is make a quick extension which would allow apps to 
opt in to the batching behavior, so they can check for the extension, set a 
context-creation flag, and get the batching behavior they want. If that 
extension isn't there, the app can still use the suspend/process functions as 
they were. This would just be a stop-gap measure until a real batching API can 
be designed, but it should be good enough until then.

> - The AL docs say: " In some implementations, process and suspend calls
> are each a NOP."
> 
> Does that mean that in some implementations, suspend/process can't be
> used to 'batch' al changes, and there is a risk I would hear a partial
> update of my state data?

Right. However, suspend/process should be used to try batching AL changes 
anyway. At best, they'll do the batching you expect and potentially improve 
performance(*), otherwise they'll simply do nothing and you're no worse off.

(*) Hardware implementations will typically recalculate internal values as you 
change object properties, and some properties will re-recalculate the same 
internal values.. eg, setting source positions will recalc output volumes for 
those sources, setting the source gains will recalc output volumes again, and 
setting the listener position will recalc the output volumes for the same 
sources /again/. Batching helps ensure it does the fewest needed 
recalculations, and that the state used while mixing is consistent.

Additionally, if everything pans out, I really hope to make openal soft have a 
real-time mixer.. that is, to be able to mix ahead however much the system 
needs, then if parameters change or the buffer gets near empty, redo the mix 
from where it's currently playing from. In such a case, it will benefit from 
batching too, for similar reasons.

> It looks like the alternative would be to always use source-relative
> sound...is this generally considered a good practice or a hack?

That may not be a bad option, if you don't mind doing the transformations 
yourself. Can't say I know what the "best" option would be, though.
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal