[Openal] suggestions on c++ game design with openAL most welcome

[Jason Daly]

Pingwah Leronz wrote:
>
> and Cars are to be able to emit several sounds at once , an ambient 
> engine roar, horn beeps, drivers yelling etc.
> /Also there's to be literally _millions_ of cars /(OK, in the project 
> itself , they're not cars :) ), so a method of culling sound emitters 
> from the set needs to be there. 
> Criteria for adding and removing Cars from the audio set is simply 
> proximity to a viewing position, and the cars themselves are stored in 
> something like

Wow.  _/Millions/_ is a lot of cars (or whatever :-) ).

You're obviously not going to be able to mix and play that many sounds 
in real time, so there will be some culling done.  You've got the right 
approach in either case, in that you're allocating buffers and 
dynamically assigning them to sources.  Either way would work, but the 
second method is probably closer to the "better" way.  I've referred to 
this as "virtualized sources", because you effectively are representing 
lots of logical sources and then assigning real sources to them dynamically.

Listener proximity is often an adequate metric for determining which 
sounds should be auralized.  In my case, each update cycle I actually 
compute the effective gain (using the attenuation formula from the spec) 
for each virtual source, and then sort them by effective gain.  I also 
throw in a user-defined "priority" metric (picked from LOW, NORMAL, 
HIGH, and ALWAYS_ON).  The sounds with ALWAYS_ON priority are guaranteed 
sources, regardless of effective gain (obviously, you can't have too 
many of these). First, each virtual source is checked to see if it is in 
a playing state (it is removed from further processing if not).  Next, 
the sounds are sorted by priority, then by effective gain.  Finally, 
real sources are assigned to the sounds at the top of the list.

This method is probably a bit too expensive for you if you really have 
to deal with millions of virtual sources.  You might need to add in an 
extra layer of cheap, coarse level processing to deal with culling out 
most of the sources before you get to a method as fine-grained as this.  
This might involve some kind of spatial subdivision, where you ignore 
sounds that lie outside of some radius, or something like that.

You might also consider a form of clustering.  This technique pre-mixes 
sounds that lie some distance away, but are roughly in the same 
direction.  Say you have three sources to the northeast,  two to the 
west and five to the south.  You could effectively auralize all of these 
virtual sources using only three real sources.  You simply pre-mix the 
sound from the first three into one buffer, the next two into a second 
buffer, and the last five into a third buffer, and then play those three 
buffers on three real sources.

In your case, I'm thinking you might not get enough of a soundfield by 
just picking, say, the sixteen closest sources.  You might try 
pre-mixing some number of sources that are moderately distant into a 
single, non-directional "ambient" buffer.  This might better represent 
the soundfield you'd really hear in that kind of situation.  An easy way 
to make a non-directional buffer is to mix the sounds into a stereo 
buffer, with the same data in both left and right channels.

That's all I can think of right now.  Hope this helps!

--"J"



>  
>  
> multimap <classCoord*, classCar*> mapCars;
>  
> (again, they're not cars- let's say the track consists of 
> many discrete positions, each of which can contain many cars).
>  
> I've been experimenting with two methods of handling this - the first 
> with a global controller:
>  
> *Method 1*
> *---------------------------------*
> class classAudioController()
> {
>      int MAX_SOUNDS = 150;
>      multimap <classCar*, ALuint> mapSounds;     //where ALuint here 
> is a ref to the standard openal source[MAX_SOURCES]
>  
>      //functions
>      void AddCar(classCar* newCar, ALuint* newAudioSource);
>      bool AssignBufferToSource(ALuint *intSource, ALbyte* filename);
>      void UpdateAllPositionsAndVelocities();
>      void UpdateCarsPositionAndVelocity(classCar* findCar);
>      etc.
>  
>  
> };
>  
>  
> and also by a more object oriented
>  
> *Method 2*
> *----------------------------------*
> classCar
> {
>    //position, fuel, health etc.
>    //....
>    classAudioSource *soundSource[MAX_SOURCES];   //remember, each car 
> can emit many simultaneous sounds
>  
>  
> }
>  
> where classAudioSource is
> {
>    ALuint intSource
>  
>    //funcs
>    bool AssignBufferToThis(ALbyte *filename);
>    void UpdatePosition(float x, float y, float z);
>    void Play();
>    void Stop();
>    void PitchMod(float fltMod);
>    void GainMod(float fltMod);
>    void SetLooping(bool boolLooping);
>    
>    etc.
>  
> }
>  
>  
>  
> With Method 1, Cars are added and removed from the emitters map on 
> movement events, In method 2 classAudioSources are triggered to 
> Play/Stop based on listener proximity , again on movement events.
> I'm running into problems with both, mainly from unfamiliarity.
>  
> If anyone here has input into handling large sets of sound sources in 
> a good OO-heavy way, or can point me to any reading that does I'd be 
> massively grateful.
>  
> Thanks,
> Pingwah
>  
>  
>  
>  
>  
>
> ------------------------------------------------------------------------
> Find car news, reviews and more Looking to change your car this year? 
> <http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal/attachments/20090602/aab56e0a/attachment.html