RE: [GD-General] Writing an audio mixer

[Brian H. <bri...@py...>]

> Lets assume that my frame rate should never drop below 20fps. 

Steady state frame rate situations are easy to support, it's when you
have things like loading screens and long idle periods that you get
hosed.  For example, say you have background music playing and you now
load a map file that's 3MB.  You probably can't pull that up in < 50ms.

To combat that you end up sprinkling "updateMixer()" calls everywhere
you _think_ you might have a long delay.  This becomes error prone and
tedious.

> The other option is to go with a threaded system.

This is conceptually much cleaner, but if supporting a console or MacOS
is important, then you may be out of luck with this direction.
 
> I think if I was to set up a mixer, I would push the issue of how to 
> service the hardware down to the system level. I would stack up play 
> commands from the game side and generate the mixed results in 
> response to a function call:

Yep.  That's pretty much the standard way of doing it.

The problem is that the mixer code can get very, very slow, depending on
how much optimization work you want to put into it.  Panning, volume,
handling repeating sounds, etc. add up to a lot of overhead, especially
on lower end systems.

> This function would need to be interrupt and thread safe.

Actually, you'd need to write that function differently depending on
whether it was interrupt driven or not, since thread sync works
differently than interrupt sync.  In all likelihood the right way to do
it would be write a portable function that had a system specific
synchronization wrapper around it.

Brian