Do any implementations support alcSuspendContext correctly?

[E. Wing]

I am looking at the Mac OS X implementation of alcSuspendContext
(partly because I am trying to figure out the best way to handle a
phone call interruption on iPhone).

I discovered that it is a no-op. I found the following comment in the code:

        // This code breaks Doom 3 [4554491] - The 1.0 implementation was a no op.
        // Since alcProcessContext()/alcSuspendContext() are also no ops on
sound c ards with OpenAL imps, this should be ok

I was rather startled at the claim that nobody implemented this.

I skimmed through the OpenAL Soft code, and it looks like a no-op there too.

On iPhone, it seems to behave as a no-op. But interestingly, if I make
the current context NULL, the behavior acts like a SuspendContext,
where the audio state pauses. So if I was in the middle of a sound,
when I resume the context after some arbitrary amount of time, the
sound resumes from where it lefts off.

But thinking about this, this is really not the behavior I want from
switching contexts. I've been toying with a multiple view design
pattern for Mac desktop applications where I have multiple OpenGL
views (each with a separate context). I want to mirror that with each
having its own OpenAL context to go with each view. When the user
changes the active view focus, I want to switch OpenAL contexts to the
new active view. But if a sound was in the middle of playing on the
context that is being swapped out, I don't necessarily want the
context suspended. (The audio is likely coordinated with the visuals
and the visuals keep moving as they may be visualizing live data.)

Any how, I am wondering, do any implementations out there support
alcSuspendContext correctly? And do all the implementations suspend
the context if you swap out the current context?

Thanks,
Eric
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Jason Daly]

E. Wing wrote:

> I am looking at the Mac OS X implementation of alcSuspendContext
> (partly because I am trying to figure out the best way to handle a
> phone call interruption on iPhone).
>
> I discovered that it is a no-op. I found the following comment in the code:
>
> // This code breaks Doom 3 [4554491] - The 1.0 implementation was a no op.
> // Since alcProcessContext()/alcSuspendContext() are also no ops on
> sound c ards with OpenAL imps, this should be ok
>
> I was rather startled at the claim that nobody implemented this.
>
> I skimmed through the OpenAL Soft code, and it looks like a no-op there too.
>  

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.


> On iPhone, it seems to behave as a no-op. But interestingly, if I make
> the current context NULL, the behavior acts like a SuspendContext,
> where the audio state pauses. So if I was in the middle of a sound,
> when I resume the context after some arbitrary amount of time, the
> sound resumes from where it lefts off.
>  

Interesting.  That's not the intended behavior.  Contexts that aren't
current should still continue to be processed.

> But thinking about this, this is really not the behavior I want from
> switching contexts. I've been toying with a multiple view design
> pattern for Mac desktop applications where I have multiple OpenGL
> views (each with a separate context). I want to mirror that with each
> having its own OpenAL context to go with each view. When the user
> changes the active view focus, I want to switch OpenAL contexts to the
> new active view. But if a sound was in the middle of playing on the
> context that is being swapped out, I don't necessarily want the
> context suspended. (The audio is likely coordinated with the visuals
> and the visuals keep moving as they may be visualizing live data.)
>  

In my understanding, that's how it's supposed to work.  You might get
into resource contention if you have too much going on, but basically,
what you laid out is the right idea.

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.


> Any how, I am wondering, do any implementations out there support
> alcSuspendContext correctly? And do all the implementations suspend
> the context if you swap out the current context?
>  

There has been a lot of confusion on alSuspend/ProcessContext over the
years.  The 1.0 spec wasn't very clear on it, and 1.1 wasn't much
better.  As a result, it seems that the implementations each did
whatever they felt was most appropriate for their platform, even though
this may have led to inconsistent behavior.

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.

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 :-) ).

It sounds like OSX may have taken even a different tack here (at least
on the iPhone).

Since we seem to be talking about 1.2 spec issues today, maybe this is
another one to add to the list.


--"J"

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

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@...
http://opensource.creative.com/mailman/listinfo/openal

[Daniel PEACOCK]

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@gmail                                            
             .com>                                                      To
             Sent by:                  openal@...      
             openal-bounces@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@...
http://opensource.creative.com/mailman/listinfo/openal

ForwardSourceID:NT0006E0DA

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Jason Daly]

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

So they are.  I'm batting a thousand today, aren't I?  :-)

--"J"

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[E. Wing]

Thanks for the responses on this. I had to sit and think about it for
awhile. One thing that struck me was that alcSuspendContext with
Creative cards allows for batching commands.

As I understand "batching", this will let you queue up OpenAL commands
while the context is suspended. Then when you resume processing, all
the commands (potentially coalesced?) are sent to the card. Is this
correct?

I had not thought of this in terms of alcSuspendContext. For some
reason or another, I was thinking that  a suspended context would just
throw away commands (become no-ops). But after thinking about this and
dealing with an evil corner case on the iPhone with handling phone
call interruptions, I think I like the idea of queuing up commands to
be run when processing resumes.

However, re-reading the spec, I don't think any of this behavior is
actually specified. Again, talking about 1.2 wishlists, I think this
needs to be drawn up.

Thanks,
Eric
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Daniel PEACOCK]

Hi Eric,

>As I understand "batching", this will let you queue up OpenAL commands
>while the context is suspended. Then when you resume processing, all
>the commands (potentially coalesced?) are sent to the card. Is this
>correct?

Yes that's right.  It can give a pretty good speed-up, particularly for
games that update a lot of parameters regularly.  However, as I also said,
it gets pretty complicated to keep track of everything that happens unless
you resort to simply storing a list of commands and values - which wouldn't
be so optimal.

The specification is very vague about the exact behaviour - and therefore
would be a good thing to sort out for a future version of OpenAL.

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



                                                                           
             "E. Wing"                                                    
             <ewmailing@gmail.                                            
             com>                                                       To
             Sent by:                  "openal@..."    
             openal-bounces@op         <openal@...>    
             ensource.creative                                          cc
             .com                                                          
                                                                   Subject
                                       Re: [Openal] Do any implementations
             07/29/2009 01:59          support                            
             AM                        alcSuspendContextcorrectly?        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Thanks for the responses on this. I had to sit and think about it for
awhile. One thing that struck me was that alcSuspendContext with
Creative cards allows for batching commands.

As I understand "batching", this will let you queue up OpenAL commands
while the context is suspended. Then when you resume processing, all
the commands (potentially coalesced?) are sent to the card. Is this
correct?

I had not thought of this in terms of alcSuspendContext. For some
reason or another, I was thinking that  a suspended context would just
throw away commands (become no-ops). But after thinking about this and
dealing with an evil corner case on the iPhone with handling phone
call interruptions, I think I like the idea of queuing up commands to
be run when processing resumes.

However, re-reading the spec, I don't think any of this behavior is
actually specified. Again, talking about 1.2 wishlists, I think this
needs to be drawn up.

Thanks,
Eric
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

ForwardSourceID:NT0006E27E

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal