Sign in to follow this  
Richy2k

Sound subsystem design

Recommended Posts

Richy2k    313
I'm working on a game engine with a few friends at uni, and we have gotten to the point that we are designing and implementing the different subsystems (graphics, sound, input, physics, so on). I am currently designing and writing the sound subsystem, before I start writing out code, I thought I'd come here to ask for some advice, see if people agree I'm heading in the right direction with this, bear in mind the diagram isn't complete yet, its still missing a fair amount, but all the basics should be there. Incase you are wondering for this implementation of the subsystem I will be using OpenAL, which is what the ALuint and such are: Also, if I have any errors in the diagram, please let me know.

Share this post


Link to post
Share on other sites
SpreeTree    396
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster

I'm currently using OpenAL and I just wanted to share some experience.

- Setting pitch too high can cause BSOD (too me a while to understand).
- Only correct way of detecting maximum amount of sound sources is to create them one by one. Like my current card supports like 31 sources or so.

- Some cards (like mine) aren't totally compatible with OpenAL. Standard OpenAl implementation crashes with X-mystique.

Good luck!

Share this post


Link to post
Share on other sites
SpreeTree    396
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

Share this post


Link to post
Share on other sites
James Trotter    432
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.

Share this post


Link to post
Share on other sites
Richy2k    313
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]

Share this post


Link to post
Share on other sites
James Trotter    432
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?

Share this post


Link to post
Share on other sites
Richy2k    313
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this