I am wondering how many DirectSound buffers I should maintain to find a good balance between constant reading of sound files and hanging on to upwards of 30-50 sound effects at once?

I am making a small 2D game engine using OpenGL, DirectSound and Win32 APIs. I am thinking I would only need two buffers for music so that I can fade them in and out, maybe adding a third for those instances where there is competing music (think of a character walking past someone's radio).

As for sound, I originally thought I could allow myself to set the number of sound buffers at the audio classes' initialization, storing them in an array for faster access, and then keeping a queue of audio requests that take up the first free buffer. Then I worried about a string of the same sound playing and thought maybe I should keep two buffers for every currently loaded sound effect, and whenever that sound effect is called while it is already playing I could do an extremely fast fade between the two buffers set aside for that sound effect.

I am sure I am just over-thinking this. I would imagine having three streaming buffers for music and a sound effects queue with 8 buffers is more than enough, but I have never really dealt with low-level sound before. What would people who have worked with lower-level audio recommend?

Thank you for your time.

I've not really played with DirectSound for years, but the principles are the same whatever the API. This is how I typically do it:

• Load all the small sounds up at startup
• Have a pool of sound 'players' that can play any of the sounds, this could return an ID to the caller so it can stop the sound later if necessary (this is also important for looping environment sounds)
• Have another totally separate layer which does the 'sound AI'

For instance, if you have a sound like a groan from being hit, you don't want an actor having 2 of these playing (ideally). On the other hand you might have several actors able to play the same groan sound. So you need some kind of logic outside the sound which takes care of this for you. You could have on an actor a means to query whether he is already playing a certain sound, or a record of what he is playing so he can cut it out and restart a new sound (or blend into one).

Not all games bother to deal with the multiple playing sounds of the same type. I certainly am not in my tower defence game (and it shows lol). If the sounds are short, sometimes an AI state machine will automagically prevent these sound overlap issues by having delays built in, so it is not always an issue in practice.

To discount an entire library and write an entire audio library from scratch because of a few roadblocks is a bit extreme.

4 hours ago, lawnjelly said:

Have another totally separate layer which does the 'sound AI':  For instance, if you have a sound like a groan from being hit, you do n't want an actor having 2 of these playing (ideally). On the other hand you might have several actors able to play the same groan sound. So you need some kind of logic outside the sound which takes care of this for you.

This right here is the most important piece.  At this layer you can also control the audio dynamics:  Post processing effects, mastering, and loudness control.