Working on adding projectile sound. 3d looping sound issues
by Duncan Gray · in Torque Game Engine · 01/22/2004 (7:45 pm) · 8 replies
A search through the forums reveals that 3d sound for LOOPING audio is not working correctly and has been a problem for a long time. According to some posts, vehicle engines sounds don't work either. I have not tested vehicle sounds at all but I think the problem will be the same as the one I'm looking at. I am posting my research here so that more experienced members can perhaps provide some insight to the problem.
First let me clarify "not working properly". I'm using the latest HEAD and referring to the updatesound function in the projectile.cc file. Older versions have an empty function here so you will need the latest HEAD. I saw in this code that you can add sound to a projectile so I tried it by taking the crossbow bolt and setting it's speed to 20m/s and adding a "sound=projectilesound " line to the datablock. Obviously I also created the corresponding audioprofile. I then tried it in the game and heard the sound but it did not fade away or "follow" the projectile. It just continued to play at a constant volume until the projectile exploded.
So it worked but the position updates did not. I then spent long hours going through audio.cc to look for any flaws in looping audio and referenced the openal docs to understand what was happening in audio.cc. Conclusion: audio.cc is working correctly per the openal docs. The updatescore function and some other, seem to indulge in some overkill with regard to estimating 3d volumes so that it can cull the buffers as sounds "expire". I say overkill because according to the openal docs, you can read the current audio gain level for any buffer just by calling an openal function. But I'm sure the audio.cc author knows more about what he is doing than I can pickup in a short time.
I now started to suspect the openal library as being the problem, so I bypassed the audio.cc wrappers and called openal functions directly in the projectile.cc updatesound function. I got the same result when I tested it in the game which seems to confirm my suspicion.
I'm now hoping that the latest openal source will cure the problem so I got a copy, compiled it and tested it with torque. Crash! I traced the 1st problem to alcGetString function in alc.cpp
A few lines below "case ALC_DEFAULT_DEVICE_SPECIFIER:" you will find :
UINT uDeviceID;
change it to
UINT uDeviceID=0; // MUST init to zero
Next crash came when I moved the mouse over a menu button. I traced that to alGetBufferi function in albuffer.c. It seems torque is now sending 0 buffer values. To continue debugging I added ;
if(buffer==0){*value=-1;return;} // it happens...
to the top of this function which allowed me to continue loading the game. The game now loaded fully, streaming audio works i.e. "menumusic"
but no other sounds worked at all. I have not continued debugging mainly because I'd like to be certain that I'm not "barking up the wrong tree"
with regard to openal being the problem.
The linux openal code is completely different which means that positioning of 3d sounds may well be working in Linux and Mac. Has anyone tried this?
First let me clarify "not working properly". I'm using the latest HEAD and referring to the updatesound function in the projectile.cc file. Older versions have an empty function here so you will need the latest HEAD. I saw in this code that you can add sound to a projectile so I tried it by taking the crossbow bolt and setting it's speed to 20m/s and adding a "sound=projectilesound " line to the datablock. Obviously I also created the corresponding audioprofile. I then tried it in the game and heard the sound but it did not fade away or "follow" the projectile. It just continued to play at a constant volume until the projectile exploded.
So it worked but the position updates did not. I then spent long hours going through audio.cc to look for any flaws in looping audio and referenced the openal docs to understand what was happening in audio.cc. Conclusion: audio.cc is working correctly per the openal docs. The updatescore function and some other, seem to indulge in some overkill with regard to estimating 3d volumes so that it can cull the buffers as sounds "expire". I say overkill because according to the openal docs, you can read the current audio gain level for any buffer just by calling an openal function. But I'm sure the audio.cc author knows more about what he is doing than I can pickup in a short time.
I now started to suspect the openal library as being the problem, so I bypassed the audio.cc wrappers and called openal functions directly in the projectile.cc updatesound function. I got the same result when I tested it in the game which seems to confirm my suspicion.
I'm now hoping that the latest openal source will cure the problem so I got a copy, compiled it and tested it with torque. Crash! I traced the 1st problem to alcGetString function in alc.cpp
A few lines below "case ALC_DEFAULT_DEVICE_SPECIFIER:" you will find :
UINT uDeviceID;
change it to
UINT uDeviceID=0; // MUST init to zero
Next crash came when I moved the mouse over a menu button. I traced that to alGetBufferi function in albuffer.c. It seems torque is now sending 0 buffer values. To continue debugging I added ;
if(buffer==0){*value=-1;return;} // it happens...
to the top of this function which allowed me to continue loading the game. The game now loaded fully, streaming audio works i.e. "menumusic"
but no other sounds worked at all. I have not continued debugging mainly because I'd like to be certain that I'm not "barking up the wrong tree"
with regard to openal being the problem.
The linux openal code is completely different which means that positioning of 3d sounds may well be working in Linux and Mac. Has anyone tried this?
About the author
#2
The only problems I've been having is sound distortion at high speeds. The vehicle code increases the speed of the sound along with the wheel RPM (actually, the torqueScale in wheeledVehicle.cc). But at high speeds, it starts to distort. Another problem; the sounds are SUPPOSED to fade out then disappear the farther you get from the source (defined as MaxDistance in your AudioDescription datablocks). They do fade, but only so much, at least with my experience. You can still hear the sound really faintly. I searched the forums and have found other people with the same problem, but there's no real solution yet.
Hope some of that helps. If there's anything else I can check, just let me know and I'll get back to you here.
- Dark
01/23/2004 (4:07 pm)
As a matter of fact, I've been working with wheeled vehicles lately, including their sounds. The sounds need to be mono. If they're stereo then they can be heard from anywhere and everywhere.The only problems I've been having is sound distortion at high speeds. The vehicle code increases the speed of the sound along with the wheel RPM (actually, the torqueScale in wheeledVehicle.cc). But at high speeds, it starts to distort. Another problem; the sounds are SUPPOSED to fade out then disappear the farther you get from the source (defined as MaxDistance in your AudioDescription datablocks). They do fade, but only so much, at least with my experience. You can still hear the sound really faintly. I searched the forums and have found other people with the same problem, but there's no real solution yet.
Hope some of that helps. If there's anything else I can check, just let me know and I'll get back to you here.
- Dark
#3
I am using a mono sound file for the projectile but it did not solve the problem.
Regarding vehicle sound fading to zero, there was a post in December which claims to have fixed it. I have not tested it, can't find that post again either, but here is what it said.
In audio.cc, find the alxUpdateMaxDistance function and replace it with this one.
void alxUpdateMaxDistance()
{
Point3F listener;
alGetListener3f(AL_POSITION, &listener.x, &listener.y, &listener.z);
for(U32 i = 0; i < mNumSources; i++)
{
if(mHandle[i] == NULL_AUDIOHANDLE)
continue;
LoopingList::iterator itr = mLoopingList.findImage(mHandle[i]);
if(itr && (*itr)->mDescription.mIs3D)
{
Point3F pos = (*itr)->mPosition - listener;
F32 dist = pos.magnitudeSafe();
F32 min = (*itr)->mDescription.mReferenceDistance;
F32 max = (*itr)->mDescription.mMaxDistance;
if(dist > max)
mSourceVolume[i] = 0.0f;
else if(dist > min)
mSourceVolume[i] = (*itr)->mDescription.mVolume * (min / dist);
else
mSourceVolume[i] = (*itr)->mDescription.mVolume;
F32 vol = mSourceVolume[i] * mAudioTypeVolume[mType[i]] * mMasterVolume;
alSourcef(mSource[i], AL_GAIN, vol);
}
}
}
Hope it works for you.
01/23/2004 (4:23 pm)
Chris, thanks for the reply. I guess that means that the openal dll is working fine and I need to look elewhere. Is that the 59k size file which come with the Torque SDK?I am using a mono sound file for the projectile but it did not solve the problem.
Regarding vehicle sound fading to zero, there was a post in December which claims to have fixed it. I have not tested it, can't find that post again either, but here is what it said.
In audio.cc, find the alxUpdateMaxDistance function and replace it with this one.
void alxUpdateMaxDistance()
{
Point3F listener;
alGetListener3f(AL_POSITION, &listener.x, &listener.y, &listener.z);
for(U32 i = 0; i < mNumSources; i++)
{
if(mHandle[i] == NULL_AUDIOHANDLE)
continue;
LoopingList::iterator itr = mLoopingList.findImage(mHandle[i]);
if(itr && (*itr)->mDescription.mIs3D)
{
Point3F pos = (*itr)->mPosition - listener;
F32 dist = pos.magnitudeSafe();
F32 min = (*itr)->mDescription.mReferenceDistance;
F32 max = (*itr)->mDescription.mMaxDistance;
if(dist > max)
mSourceVolume[i] = 0.0f;
else if(dist > min)
mSourceVolume[i] = (*itr)->mDescription.mVolume * (min / dist);
else
mSourceVolume[i] = (*itr)->mDescription.mVolume;
F32 vol = mSourceVolume[i] * mAudioTypeVolume[mType[i]] * mMasterVolume;
alSourcef(mSource[i], AL_GAIN, vol);
}
}
}
Hope it works for you.
#4
alxUpdateMaxDistance partially fixes the problem, but once you reach the maxdistance the sound just cuts off. I'm pretty sure that's why it's commented out in the first place. The problems are these:
In the alxUpdateScores function. They're supposed to make it fade slowly until you reach maxDistance, eventually fading to 0. But if MaxDistance - ReferenceDistance is smaller than 150-200m, then it doesn't really work right. The camera usually moves too fast for it to calculate a small enough number to mute the audio, then when the camera moves out of the maxDistance range, it has no reason to calculate anything anymore, and the audio just gets stuck on.
I honestly have no idea what the hell I'm doing. Well, I do, but I don't know the correct terms to use, so I can't really put it into words. I can explain it better in code. I see the problem in my head, and the solution, I just have to program it. It shouldn't take more than a few minutes, IF I'm right...
01/23/2004 (5:52 pm)
Yeah, that's part of it, but that's not the whole problem. Your post got me thinking of a place to look, and I think I found why it keeps playing even after you pass the maxDistance.alxUpdateMaxDistance partially fixes the problem, but once you reach the maxdistance the sound just cuts off. I'm pretty sure that's why it's commented out in the first place. The problems are these:
mScore[i] *= (max-dist) / (max-min); (*itr)->mScore *= (max-dist) / (max-min);
In the alxUpdateScores function. They're supposed to make it fade slowly until you reach maxDistance, eventually fading to 0. But if MaxDistance - ReferenceDistance is smaller than 150-200m, then it doesn't really work right. The camera usually moves too fast for it to calculate a small enough number to mute the audio, then when the camera moves out of the maxDistance range, it has no reason to calculate anything anymore, and the audio just gets stuck on.
I honestly have no idea what the hell I'm doing. Well, I do, but I don't know the correct terms to use, so I can't really put it into words. I can explain it better in code. I see the problem in my head, and the solution, I just have to program it. It shouldn't take more than a few minutes, IF I'm right...
#5
01/23/2004 (5:57 pm)
In HEAD the sounds used are heard full volume anywhere within the profiles distance.. is this because the .ogg files are in stereo?
#6
Night, guys....
01/23/2004 (8:31 pm)
This strings don't do crap to the volume. After working on them for a couple hours, I finally decided to set them to 0, and there's no effect on the audio. I'm too tired and impatient to do this right now, maybe I'll work on it tomorrow.Night, guys....
#7
Anyway, I'm using an integrated soundcard and this is the OpelAl initializacion (it may be useful)
OpenAL Driver Init:
OpenAL
Vendor: Creative Labs Inc.
Version: OpenAL 1.0
Renderer: Software
Extensions: EAX 2.0, EAX 3.0, EAX Unified, and EAX-AC3
I don't know if it would change to 'Hardware' if I were using a nicer card...
05/19/2004 (2:00 am)
What happened with this issue? I also heared looping sounds (really softly, but they were clearly there), even being kilometers away. I tried commenting, in void alxUpdate() (audio.cc), the mForceMaxDistanceUpdate check:{
//if(mForceMaxDistanceUpdate)
alxUpdateMaxDistance();and it -seems- to be working properly now... I don't hear looping souds if I am over the maxDistance. Anyway, I'm using an integrated soundcard and this is the OpelAl initializacion (it may be useful)
OpenAL Driver Init:
OpenAL
Vendor: Creative Labs Inc.
Version: OpenAL 1.0
Renderer: Software
Extensions: EAX 2.0, EAX 3.0, EAX Unified, and EAX-AC3
I don't know if it would change to 'Hardware' if I were using a nicer card...
#8
All distance sounds work fine for me doesnt matter how far or close they are.
Wonder why its not commented out in the Head,but maybe its becuase of linux and mac versions i dont know.
But it works really good in windows.
And some information of mono files that most people have problem with.
Obs ! A mono file is single channel file,not a dual mono file !!
Greetings
Billy
05/19/2004 (6:34 am)
I commented out that alxupdatemaxdistance long time ago.All distance sounds work fine for me doesnt matter how far or close they are.
Wonder why its not commented out in the Head,but maybe its becuase of linux and mac versions i dont know.
But it works really good in windows.
And some information of mono files that most people have problem with.
Obs ! A mono file is single channel file,not a dual mono file !!
Greetings
Billy
Torque Owner Duncan Gray
My point being if it works correctly then the openal code is working and the problem with projectile sound is not in the openal area.