Sound player

[NecroDOME]

Hi all,

I started working on a sound player my games. I want to use DirectSound cause I used it in other project. I didn't made the sound in my other projects, so I have no clue on where to start for making a nice sound player.

From this point I only know that sound uses buffers and channel. You load a buffer and play it in one or more channels. And on the channels you can set the volume n stuff.

So what would be a good approach to create a sound player that uses channels and buffers combined with Doppler effects and all.

My first thought was to make something like this:


SoundBuffer = class
Buffer: Buffer to direct sound;
function CreateSound : returns a new sound
function LoadFromFile(FileName: string): boolean;
end

Sound = Class
Buffer: Pointer to SoundBuffer;
Position : Vector3;
Speed : integer;
Volume : integer
Channel : integer; / read only!! tis is set by the "play" function

procedure Play;
procedure stop;
end

For now I want to use DirectSound.

[Pyrogine]

Hi,

Here (http://pyroginegames.com/downloads/GVAudio.zip) are some sources from and older version of my audio engine.

* Uses DirectSound for sample playback
* Uses MikMod for MOD playback
* Uses Ogg for OGG playback
* Uses DirectShow for MP3 playback
* Shows how to setup and use all these different playback engines via abstraction layer so that usage is seamless
* Uses a thread for background operations
* Manages up to 256 loaded samples and can manage up to 32 playing samples
* Shows how to load an uncompressed WAV file directly to a DirectSound buffer
* Shows how to decode OGG directly to a DirectSound buffer (via the background thread)
* Dynamic 2D sounds (pan, pitch, Doppler shift)
* Much more

Lots of great stuff in there. Hope that it can help you.

[NecroDOME]

thnx, I took a quick look at it and it seems it has some useful data.

The only thing I have a question about is why you have limited the sound buffers to 256?

[Pyrogine]

No reason other than at the time 256 loaded sound samples was plenty. Have you every had more than 256 samples loaded into memory for any game you've made? So far I've not so this seemed like a good upper limit. Loaded samples are one thing, but dynamic playing buffers are another. You want to keep those to a reasonable amount for performance sake. At first I had them set to 256 as well. Having up to 32 sound buffers all playing at the same time, is/was plenty. You can however set what ever values that you need for you project. For me those were good numbers that worked well over the years. I never got around removing the hard limits because the need never came up.

[NecroDOME]

well, playing 32 sounds at the same time is quite a lot. Also loading 256 sound into the memory is also quit a lot. I got an editor where I want to play sounds if I double click them. However when I load a sound into the "sound browser" it just loads the sound. This is also the way my "texture browser" works. Not the most efficient way cause it consumes lots of memory, but in-game it would be more "limited".

You said it was an old version of your audio engine. What are the specs of your new audio engine?

[Pyrogine]

Yes, those limits are high enough to support most projects. You want to load your samples into memory for reference, then when you play them, copy it to the mix buffer. You then monitor this, either in the main thread or from a background worker thread (or simply from a timer event) to update channels, clear played sounds, decode the next chuck of streaming music etc.

The latest (in PGSDK) supports more music formats, more optimized, now operates in a safe timer event rather than a thread. Supports music streaming from an archive and more. It's now an ECOM object so can easily be extended on the client side to add new features. For example, if you derive a new audio class that adds support for fading in/out music, to make it work with the rest of the SDK you would do this:

Pyro.Audio := TMyAudio.Create;

The old Audio instance will be destroyed and replaced with the new version and everything will continue to work throughout the SDK as normal. In fact all the singleton objects in the Pyro application instance can be upgraded in this way (DisplayDevice, RenderDevice, Input etc). Since memory is shared between the client and the DLL the DLL will destroy the Audio object as it normally would do and all will be fine.

As you develop your audio engine, think in terms of abstraction layers, this way you can add new audio playback formats as needed. In fact as you develop your projects in general think in terms of expansion and code in such a way that if you have to rewrite a section you can minimize having to rip out large portions of code or having to start all over. Often times it become easier to rewrite the whole thing than to maintain it. This is usually a sign of poor design up front. As it's impossible to know all the possible scenarios that you may encounter during development, we have to start to apply some agile methodologies to help make software development more manageable. I was going to say less complex, but the fact of the matter is that software design/coding is a complex beast.

So, grab a coke, beer or what ever your beverage of choice and begin think about what you want to accomplish with your audio engine. Resist the temptation to try and code it in your mind (at this point) as your working out the design, just consider all that you want it to accomplish. Now, break this down in to smaller and smaller (manageable) parts that you can code (and finish) and see the results. It's important that we see some results to give the brain the feedback it needs else we get bored and loose interest. Keep going until you have something that meets your goals. Note, as you do this, always keep in mind of how can an end-user (or yourself) expand up this to add new functionality without having to recode it. As we start to retrain ourself to work within these agile concepts the overall development process (should) becomes more efficient. I wish you success and keep us posted on your progress.