[SDL] SDL_LockAudio and MacOS

[david at ultramaster.com]

> > Should work, but keep in mind that you need a totally reliable way of safely
> > skipping an interrupt without SDL_UnlockAudio() failing to compensate for it.
> > (Another flag might be enough to take care of that.)
>
> Shouldn't be a problem.

How do you work around the following race:

SDL_Lockaudio()
   -> set ignore callback flag to true
do some list manipulations
SDL_Unlockaudio()
   -> check if callback happened while we were locked, nope
     <- callback happens here
   -> set ignore flag to false


We've now dropped a callback.  You can't work around this without a lock
IMHO.

However, there is the pauseCmd, resumeCmd with the SndDoImmediate, as I
posted before.  I'd be willing to bet that these commands will function as
locking primitives around the callback.  The closest I can get to
'semantics' for the call are that they pause all processing of the audio
command queue.  Now since the callback is issued in response to a queued
 'callBackCmd' it should be delayed by the pauseCmd until the resumeCmd is
issued.  Since we can issue these two commands using SndDoImmediate, we
bypass the command queue.  It is also specified that pauseCmd DOES NOT
pause any currently playing sound, it only causes no further queued
commands to be processed.

I've never tried this however.

Since the Mac is single thread w/interrupt model, there is no chance of
setting the pause flag WHILE a callback is in progress.

Do you guys think this is a reasonable model?  Unfortunately,
SDL_LockAudio and SDL_UnlockAudio are not "virtual" methods in SDL 1.2.
Maybe they need to be.  In the meantime, I could hack together a test of
this technique pretty quickly by exposing functions in the SDL_romaudio.c
to do this.

David

-- 
David Mansfield                                           (718) 963-2020
david at ultramaster.com
Ultramaster Group, LLC                               www.ultramaster.com