[Openal] Do any implementations support alcSuspendContext correctly?

Thu Jul 23 02:29:43 PDT 2009

Hi,

The "native" OpenAL implementations on some Audigy and X-Fi cards support
alcSuspendContext and alcProcessContext.    These operations do not block
mixing, they are used to batch OpenAL calls together.

In theory they can offer a good optimization for hardware devices (I don't
think they are quite so useful for software implementations).   The reason
is that a hardware device will typically immediately respond to an OpenAL
call - e.g. if you set a new 3D position for a source you will instantly
hear the source move to the new location.   This gives you great
low-latency 3D Audio.

But this has a downside ... in order to move the sound to the new location
you have to do panning and attenuation calculations and pass the computed
values to the hardware.   The calculations have a number of dependancies -
e.g source position, reference distance, source orientation, cone
parameters, listener position and orientation etc ...    So the bad news is
that if the application does this ...

Set Source Position
Set Source Reference Distance
Set Source Orientation
...
Set Listener Position
Set Listener Orientation

Then after every single call the panning and / or attenuation calculations
need to be re-done and the new result sent to the hardware.  (In the case
of the Listener calls they need to be done for all Sources).  If all these
calls occurred while the context was suspended they would simply store the
new values and return immediately.  When the context is un-suspended
(processed) one set of calculations and writes to the hardware would be
done.

Unfortunately supporting suspend...process context is not trivial as the
application can do any AL operations it likes while the context is
suspended (e.g starting / stopping sources, swapping buffers, deleting &
generating resources etc ...)   When the context is unsuspended it can be
difficult to determine exactly what state everything should be in.    This
technique has worked well in some games, but has failed badly in others.
Your mileage will vary.

Dan
Creative Labs (UK) Ltd.

Notice
The information in this message is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to this
message by anyone else is unauthorized.  If you are not the intended
recipient,  any disclosure,  copying or distribution of the message,  or
any action taken by you in reliance on it,  is prohibited and may be
unlawful.  If you have received this message in error,  please delete it
and contact the sender immediately.  Thank you.

Creative Labs UK Ltd company number 2658256 registered in England and Wales
at Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB

             Chris Robinson                                                
             <chris.kcat at gmail                                             
             .com>                                                      To 
             Sent by:                  openal at opensource.creative.com      
             openal-bounces at op                                          cc 
             ensource.creative                                             
             .com                                                  Subject 
                                       Re: [Openal] Do any implementations 
                                       support alcSuspendContext           
             07/23/2009 06:07          correctly?                          
             AM                                                            

On Wednesday 22 July 2009 7:40:20 pm Jason Daly wrote:
> Not sure about earlier versions, but the 1.8 version at least sets a
> mutex (critical section) there.  My guess is that this causes the mixing
> thread to block, so this isn't a no-op.

Actually, SuspendContext/ProcessContext are internal functions that hold a
mutex for thread safety. The similarly-named exported ALC functions are
unrelated.

I did experiment with making the ALC functions hold the mutex, but there's
the
issue that the ALC functions are not recursive, and it makes no mention of
threading. For example, if alcSuspendContext is called twice, it still only

takes one alcProcessContext call to resume, not two (the spec is pretty
explicit about that). And if alcSuspendContext is called from one thread,
alcProcessContext from another thread should still work. Or worse, two
alcSuspendContext calls, one from each thread, is not disallowed by the
spec.

I may be able to work something out with semaphores, but it will still rely
on
apps not keeping the context suspended for "long" periods of time ("long"
in
terms of sound card updates, which can be as few as a couple hundred
samples
per update).

> That said, I'm not sure how many implementations actually support
> multiple active contexts in a robust way.  I'd guess OpenAL-Soft and the
> Creative implementations would be OK.  Not sure about OSX.

OpenAL Soft can handle multiple contexts fine, although currently you can
only
get one context per device. To get two contexts, you need to open two
devices
and get one context from each (as long as the hardware/sound system
supports
it, you can open the same device twice, though).

The old software Windows code couldn't handle multiple devices/contexts
properly, though. The callback for DSound output would only work with the
current context. Funny enough, the WaveOut/MMSystem callbacks could handle
multiple contexts (still one per device), but the mixing functions used the

context-specific alGet* functions to get the source and listener
properties. I
don't know if this has been fixed or not, though.

> I know that Creative used Suspend/Process to do batch state changes on
> their hardware implementation.  It's more efficient and sounds cleaner
> to send several state changes at the same time, while the context is
> suspended, than it is to process them as you get them.  In a software
> implementation, this isn't as critical, so it's not all that surprising
> to see no-ops, I guess.

Personally, I wouldn't mind implementing alcSuspend/ProcessContext in a way

that behaves like this, as there is some apparent value in making sure some

changes happen at "the same time". If I block mixing updates while
suspended,
no mixing is done with the changed properties until processing resumes, at
which point, the changes will be in effect simultaneously. As long as it's
not
suspended long, the sound card can catch up quickly. I just need to handle
it
with something more flexible than mutexes.

> The original sample implementation from Loki was radically different
> here.  IIRC, if you created a synchronous context, you had to constantly
> call alcProcessContext to handle the mixing and keep it updated.  I
> remember Chris being rather shocked at this part of the SI (this might
> have been what drove him to write OpenAL-Soft, actually :-) ).

Part of it, yeah. I wasn't sure if I could keep it working, or even if it
was
even working to begin with.
_______________________________________________
Openal mailing list
Openal at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal

ForwardSourceID:NT0006E0DA