RE: [GD-General] Writing an audio mixer

[Tom H. <to...@3d...>]

At 04:41 PM 3/18/2002, Brian Hook wrote:
>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.

Yup ... Long file I/O kills that kind of sound system. It's often ok to 
shut off background music during long IO though.

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

Yes .. I'd do everything I could to avoid such a thing.

>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.

Unless you're doing the mixing on another CPU or are running into 
situations where you're taking up double interrupt hits (something that can 
happen on the Mac and make things slower than they should be .. not 100% 
clear on this one myself), it doesn't really matter when/where you do the 
work. It's still going to take the same amount of time. Unless I'm missing 
something, I don't really see how this is relevant.

>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.

Yeah ... somethin like that ;)

Tom