Sound subsystem design

Hi

I have had a look at your diagram, and while I can't see any particular errors, I'll give any suggestions I have from implemented (far too many) sound systems over the years :)

Regarding OpenAL and sources. You have in your diagram that you can have up to 128 sources. This is not neccesarlily true. The number of sources is wholely dependant on your sound card. My card at home supports up to 16 sources :( but this pile or rubbish I am using now supports up to 1024 sources! So you will need to check how many sources you have available to you at runtime.

A sound buffer, in OpenAL (and most systems I have used), is assigned to source on a 1 to many relationship (Source * ------- 1 Buffer), as a sample can be played on as many sources as it wants. Now it obviously depends on your system, but that link is not shown. Are you going to store all buffers in the CSoundSystem, and then reference that from the source, or store the buffer in the source?

This one is about the OO aspect of your design. In your diagram, the ISoundSystem has functions Stop and Start sound. Would this, in a OO design, not be better served being in the Source class. Once the sample has been loaded and assigned a source (usually assinged when it is first played), when you stop, pause or replay the sample, you will be doing this via the source. So will you have a call CSource->Stop, or CSoundSystem->StopSound(CSource& _source)? I personally prefer the former, but thats up to you :)

There are a few things missing, that I am sure you are aware of, but I'll list them anyway :)
* Sources need both an independant volume and frequency setting
* The system itself can set the 'global' volume - OpenAL doesnt have a specifc implementation for this, but is very useful
* Pause source - Stopping and starting a source in OpenAL is not the same as pausing it

Thats all I can see for now. Obviously, you have stated it is not yet completed, so you could have thought about them before hand. But I hope it helps somewhat :)

Spree

Quote:

Original post by Anonymous Poster - Setting pitch too high can cause BSOD (too me a while to understand).

Setting the pitch too absolute zero crashes too, though I have never had BSOD :s

Spree

I was also working on an audio system with OpenAL for a while back. I made a sketch of it in Dia. It was made quite quickly, and I can't remember if it changed during implementation, but maybe you would like to compare our two approaches:


I used the Ogg Vorbis library for streaming the audio data to OpenAL. Also, if you'd like, I could send you the code.

The idea of an audio task seems a bit neater than the way i've been visualising the system. And I didnt realise there was a finite number of sources, but nevermind, me just being stupid. I've just been sat playing with OpenAL, its is pretty damn easy to use, I just need to work out a good design for a sound system so I can actually have something to show for a weekend of work [smile]

Yes, you're right, OpenAL is very easy to use. It took only a few hours after I had the initial design laid out, and it works very well.
As you can see, I have two separate classes, one for loading and decompressing an audio file and playing it right off (CSound), and one for continuously streaming the audio data (CSoundStream). I found that I needed to take a slightly different approach for the two, because while the CSound only needed a single buffer, for a stream you need several buffers in the queue, and you need to constantly refill them and push them back into the queue to keep it going smoothly.

And I borrowed a few ideas (specifically the task thingy) from Richard Fine's Enginuity series of articles. Some good, solid ideas there.

I came to notice that several of the functions defined in the cSoundBuffer and cSoundSource classes in your diagram, for instance cSoundBuffer::Load, are private. This seems a little strange to me. How are these functions called?

friend cSoundSystem;

I only want those classes accessable by cSoundSystem, by no other classes - The idea of the interface is to totally hide the actual implementation from the user - I can change the implementation in any way I like then, stick it on any platform (Will be ported to the GC since I have access to dev kits) and not have to worry about which API I am actually using for sound, just change the implementation to suit the API. Besides that, we've already agreed on how the subsystems will fit into the game engine, and we are sticking with the rules we've set, sadly.