[SDL] Help needed with SDL audio

David Olofson david.olofson at reologica.se
Tue Aug 28 11:25:00 PDT 2001

On Tuesday 28 August 2001 09:50, you wrote:
> Hello,
> I am working on a SDL port of Charles Mac Donald's SMS Plus (emulator
> for Sega Master System & Game Gear). The preliminary version is
> available at
> http://www.student.oulu.fi/~jakarppi/spnew.zip
> I would like some advice on the audio output, which currently doesn't
> work very well.

I don't know what your exact problem is (I haven't tried to run the 
code), but from a quick look at it, the main issue I can see is that 
there are two critical interfaces in the chain; the one between the 
emulator engine and the SDL audio callback, and the one between the SDL 
audio callback and the driver/hardware.

The easiest way in general to get reliable low latency output is to run 
the entire audio engine inside the SDL audio callback, so that audio 
mixing (which must meet all deadlines to avoid drop-outs) can run 
undisturbed. That way, if the main loop (with the graphics etc) stalls, 
it doesn't have to affect audio mixing and output. The main program just 
sends "commands" to the audio engine, that will be picked up and 
processed for the next buffer. (Very similar to how a MIDI sound 
generator is controlled.)

The problem with such a design in conjuction with an emulator is that if 
you move the sound chip emulation to the audio callback (which runs in a 
callback from the driver, or in a separate thread), real world timing 
affects the emulated CPU<->sound timing.

One solution that might work is to add timestamps to the commands sent to 
the audio engine. If commands should arrive late (due to the main loop 
stalling), audio will keep playing in it's current state, and the late 
commands will be processed as soon as they arrive. Usually sounds better 
than total drop-outs...

However, there could be problems with sound quality if there's massive 
traffic from the CPU to the sound chip - delays will case stalls in the 
middle of sound effects, and affect *all* sound effects playing. Further, 
running sound chip and CPU emulation in separate threads is not at all 
possible if the CPU *reads* critical information from the sound chip. 
(The CPU->sound chip communication must be one-way.)

Now, if the hardware emulated hardware has a dedicated CPU for sound (as 
is the case with many arcade machines), you could move emulation of that 
CPU to the audio thread as well. That would ensure that sound effects 
(which usually involve frenetic, time critical fiddling with sound chip 
control registers :-) are generated properly - delayed commands would 
just cause sound effects to start later.

If the original hardware doesn't have a dedicated sound CPU, it *might* 
still be possible to use a variation the above strategy: If the sound 
code runs in interrupt handlers generated by a specific timer (ie one 
that comes with the sound hardware), it might be possible to run only 
those interrupts in a "main CPU" emulator from within the audio callback 
(as if the audio callback was generating those hardware interrupts), 
while keeping all other "main CPU" emulation in the main loop.

If games on your emulated system use various different ways of driving 
their sound code, *and* need bidirectional CPU<->sound chip 
communication, then you're in trouble... You have to run the entire 
emulator in real time with sufficient timing accuracy to drive the sound 
directly, which moves the problem over to the graphics emulation side, 
where you have a lot more data to shuffle around.

I'm not suggesting that any of the proposed solutions would be trivial to 
apply in the case of an emulator! :-) Mixing hard and soft real time with 
good results is inherently complicated in any non-trivial setting. 
Emulators are probably worse, as you can't redesign the game<->audio 
interaction to suit the way your host platform works.

//David Olofson --- Programmer, Reologica Instruments AB

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

More information about the SDL mailing list