[SDL] SDL_LockAudio and MacOS

David Olofson david.olofson at reologica.se
Mon Apr 23 06:31:22 PDT 2001

On Saturday 21 April 2001 19:14, Darrell Walisser wrote:
> On Sat, 21 Apr 2001, David Olofson wrote:
> > On Thursday 19 April 2001 23:36, Darrell Walisser wrote:
> > > > And result in clicks/blank spaces. Unacceptable.  I'm talking about
> > > > blocking the audio interrupt for microseconds at a time, while, for
> > > > example, a link list operation is completed.
> > >
> > > Unfortunately I don't think there is any way to implement it.
> >
> > Why not? There are lock-free solutions for most kind of sync constructs,
> > although most of them are rather messy, uggly and/or awkward to code.
> > Single reader-single writer constructs are rather simple, though, as long
> > as you have atomic reads and/or atomic writes for some usable word size,
> > which is the case with most architectures, even on SMP machines.
> 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.)

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.

(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 


.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david at linuxdj.com -'

More information about the SDL mailing list