[SDL] SDL_LockAudio and MacOS

Darrell Walisser dwaliss1 at purdue.edu
Mon Apr 23 07:48:44 PDT 2001

On Mon, 23 Apr 2001, David Olofson wrote:

> > I've thought about this problem a bit, and I think I have a solution:
> >
> > Modify the Carbon sound driver as follows:
> >
> > make SDL_LockAudio set a flag audio_locked to true.
> >
> > in the callback, if the audio is locked, don't send any new data to the
> > chip, and stop the callback cycle. In other words, do nothing in this
> > case.
> >
> > make SDL_UnlockAudio send data to the chip and also send the interrupt
> > command to start the callback cycle over again.
> >
> >
> > As long as you can process all of your data between
> >
> > SDL_LockAudio() and SDL_UnLockAudio() faster than the current sound
> > buffer takes to play, you shouldn't get any clicks or have synchronization
> > problems.
> >
> >
> > What do you think?
> 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.

> BTW, both the audio callback and SDL_UnlockAudio() could perhaps use the same
> code, unless of course, the audio API as to be used differently from outside
> the callback. Don't know enough about Mac OS or Mac OS X to tell, but it's a
> common way of doing it inside drivers for various other platforms.

Sure, I could use the same code in both places. But it's only 10 lines, so
I don't know how much difference that really makes (well, easier to
maintain at least).

> (As to application code, the only system I've programmed that uses real
> callbacks from the driver is Win16 - and there, you *cannot* queue new audio
> buffers from within such callbacks! Now, is that useless, or is that
> useless...?)

Not a problem. I've done it both ways. Actually the PLIB MacOS audio
driver doesn't send any samples in the interrupt and seems to work OK.

More information about the SDL mailing list