Plan for Matthew Overlund
by Matthew Overlund · 12/12/2005 (4:09 pm) · 4 comments
Progress on the abstraction of the audio layer is moving along nicely.
I've modeled the abstraction after the GFX layer in TSE, with some minor changes. Currently there are 3 methods on 1 object that are platform specific and will require porting, but the methods themselves are very simple, more along the lines of subsystem configuration than actual audio specific code.
I'm building in support for multiple active devices, again much like the TSE can render to multiple heads. This is primarily for anyone who wants to support voice communication using a secondary sound device like a USB headset or external sound card. Device enumeration is also added, in fact enumerating devices is a required step before device creation. The enumerated driver and device lists will also be made available to the scripting environment.
My current plans are to keep the existing engine->script interface unchanged as much as possible, and so far I haven't found anything that forces me away from that. I'm currently thinking that I will rename the console methods to reflect the new layer prefix im using (sfx instead of alx), and then add stub functions that call the new function names and post a message to the console logging the deprecated call. The current console functions expose the OpenAL functions for reading and writing properties on audio objects directly (i.e. alGetString, alBufferi, etc) which will have to be changed to support the abstraction, but the 'utility' functions for performing higher level actions on audio objects will remain. The removed property access functions will be reimplemented to give the console access to all the source/listener properties as before but via get/set accessors for each property.
I found some duplicate code between the AudioBuffer and the WaveStreamSource classes. They are each using separate struct definitions for the WAV headers, and separate functions for loading the headers and the data. When I get up to converting those classes I'll clean that up and consolidate it, and review the Ogg code to see if it suffers from the same.
I looked briefly at the BASS api, but it looks like they only support 3D positioning of sounds on Windows, so I struck them from the list.
PortAudio also is lacking 3D sound support.
So for now I'll be implementing DirectSound, OpenAL and FMOD on Windows, OpenAL and FMOD on Mac/Linux. Unfortunately I won't have mac/linux build
environments ready for about 2 weeks, so I may be working on this throughout the month.
As far as input/feedback, I'm really intersted in hearing anyones thoughts on the affect this will have from a scripting standpoint. For example if you are using the console functions that specifically call OpenAL's generic property accessor methods to access and manipulate data outside what you would consider normal practice (i.e. setting position, gain, direction, orientation etc); I'd like to hear from you. As much as possible I want to cover all bases in the abstraction layer on the first pass.
I've modeled the abstraction after the GFX layer in TSE, with some minor changes. Currently there are 3 methods on 1 object that are platform specific and will require porting, but the methods themselves are very simple, more along the lines of subsystem configuration than actual audio specific code.
I'm building in support for multiple active devices, again much like the TSE can render to multiple heads. This is primarily for anyone who wants to support voice communication using a secondary sound device like a USB headset or external sound card. Device enumeration is also added, in fact enumerating devices is a required step before device creation. The enumerated driver and device lists will also be made available to the scripting environment.
My current plans are to keep the existing engine->script interface unchanged as much as possible, and so far I haven't found anything that forces me away from that. I'm currently thinking that I will rename the console methods to reflect the new layer prefix im using (sfx instead of alx), and then add stub functions that call the new function names and post a message to the console logging the deprecated call. The current console functions expose the OpenAL functions for reading and writing properties on audio objects directly (i.e. alGetString, alBufferi, etc) which will have to be changed to support the abstraction, but the 'utility' functions for performing higher level actions on audio objects will remain. The removed property access functions will be reimplemented to give the console access to all the source/listener properties as before but via get/set accessors for each property.
I found some duplicate code between the AudioBuffer and the WaveStreamSource classes. They are each using separate struct definitions for the WAV headers, and separate functions for loading the headers and the data. When I get up to converting those classes I'll clean that up and consolidate it, and review the Ogg code to see if it suffers from the same.
I looked briefly at the BASS api, but it looks like they only support 3D positioning of sounds on Windows, so I struck them from the list.
PortAudio also is lacking 3D sound support.
So for now I'll be implementing DirectSound, OpenAL and FMOD on Windows, OpenAL and FMOD on Mac/Linux. Unfortunately I won't have mac/linux build
environments ready for about 2 weeks, so I may be working on this throughout the month.
As far as input/feedback, I'm really intersted in hearing anyones thoughts on the affect this will have from a scripting standpoint. For example if you are using the console functions that specifically call OpenAL's generic property accessor methods to access and manipulate data outside what you would consider normal practice (i.e. setting position, gain, direction, orientation etc); I'd like to hear from you. As much as possible I want to cover all bases in the abstraction layer on the first pass.
#2
12/13/2005 (1:06 am)
Oh, forgot to mention: I would love to have script methods for attaching a sound to objects so that the sound is moving along with the objects (DTS, Projectiles etc.)
#3
Just from a quick look at the vehicle classes in TGE, I think what you need is already in place.
Take a look at this code from game/vehicles/hoverVehicle.cc ~line 430:
Notice the calls to getTransform(). What this is doing is telling the audio engine to use the current position and velocity of the vehicle as the position and velocity of the sound source. Effectively giving you an "attached" sound. If the player object is moving in sync with the vehicle, you should get a constant sound from the jets, if the player is stationary as the jet flys by, then you should hear the doppler effect.
The key to it being that the sounds dont have a physical body, the only thing you have to do is manage 2 matrices, one to tell the audio layer the position of the listener and one to tell the position of the sound source. Luckily both are handled by Torque automatically :)
12/13/2005 (11:57 am)
@Martin,Just from a quick look at the vehicle classes in TGE, I think what you need is already in place.
Take a look at this code from game/vehicles/hoverVehicle.cc ~line 430:
// Update jetsound...
if(mJetting)
{
if(mJetSound == NULL_AUDIOHANDLE && mDataBlock->sound[HoverVehicleData::JetSound] != NULL)
mJetSound = alxPlay(mDataBlock->sound[HoverVehicleData::JetSound], &getTransform());
if(mJetSound != NULL_AUDIOHANDLE)
alxSourceMatrixF(mJetSound, &getTransform());
}
else
{
if(mJetSound != NULL_AUDIOHANDLE)
{
alxStop(mJetSound);
mJetSound = NULL_AUDIOHANDLE;
}
}Notice the calls to getTransform(). What this is doing is telling the audio engine to use the current position and velocity of the vehicle as the position and velocity of the sound source. Effectively giving you an "attached" sound. If the player object is moving in sync with the vehicle, you should get a constant sound from the jets, if the player is stationary as the jet flys by, then you should hear the doppler effect.
The key to it being that the sounds dont have a physical body, the only thing you have to do is manage 2 matrices, one to tell the audio layer the position of the listener and one to tell the position of the sound source. Luckily both are handled by Torque automatically :)
#4
12/13/2005 (9:41 pm)
Cool, thanks :-)
Torque Owner Martin Schultz
Martin :-)