Game Development Community

Tips for long-range audio?

by Daniel Buckmaster · in Torque Game Engine · 01/07/2010 (11:10 pm) · 10 replies

How would you recommend I go about simulating the sound of explosions at large distances? Most important, I guess, is the slight time-lag between seeing the explosion and hearing it. Is this something that can be handled in Torque, or does it need to be implemented within OpenAL itself?

I guess it could be done within the classes that use audio emitters - specifically Explosion, since that would be most important, and the most likely to be heard at long range - by just applying a little delay before the sound is played.

I've found doing some tests that there seems to be some sort of cutoff for audio files to be played - if I shoot a projectile a long way off, I can't hear its sound, even though its description is set with a max range of 500. Is there an overall pref or hardcoded limitation preventing sounds from playing beyond a certain range?

Client/server sync is another issue. If a projectile explodes behind a hill, clients might now know about it to play the sound. It seems like audio should be handled by creating separate audio objects (like the AudioEmitters you can place in the world editor) rather than just getting objects to call alxPlay at the right time. (Or, 'should be handled' to get my desired soundscape working.)

About the author

Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!


#1
01/10/2010 (1:50 pm)
Adding a delay offset is an old-school movie sound trick. Just use the rule of thumb that audio travels about 20 feet per millisecond [roughly]. Calculate the offset in game units and add a timer to offset the play command [however you do it] accordingly and it'll greatly enhance the realism...

...please post if you figure it out before I do ;)
#2
01/10/2010 (2:00 pm)
'nother thought. Most gaming hardware, and even a lot of exensive DAWs still use the 128 increments from the MIDI standard. The code sends a level to the hardware and at some point as it fades out is interpolated as '0' and you get nothing. In addition, after about .75 miles you exponentially loose the ability to discern direction. Perhaps at that point you could add a delay and play an ambient sound, saving resources...
#3
01/10/2010 (9:04 pm)
Quote:audio travels about 20 feet per millisecond [roughly]
Or 340m/s in metric, baby! ;)

Quote:Calculate the offset in game units and add a timer to offset the play command [however you do it] accordingly
I figured that'd do - when I first had the idea my head went spinning with all sorts of crazy sound-propagation algorithms to capture all cases (moving source, moving observer, whatever)... which is completely, utterly, ludicrously unnecessary. I'm going to see what I can do about putting sound effects on schedules ;P.
I guess the simplest solution would be to literally use a schedule... though those usually operate on objects, not independently.
Net event? Like the server-side explosion resource. Hmm... I'd almost prefer to somehow work this directly into the alxPlay function/s somehow.

EDIT: I do like the idea of adding a different sound at long range. Not sure how to go about doing it :P. And there does seem to be this strange problem I mentioned - I can't hear sounds past about 200 units, for some reason. They don't even fade out at that distance - I've set the maximum distance at 500, and the sounds gradually fade down as they get further away... then suddenly go silent somewhere less than 500 away.

EDIT: I think I solved that problem. AL_MAX_DISTANCE is defined as 0x1023, which from what I can determine is 256 in decimal. So sounds are being cut off 256m away. If we want sounds out to 1000m, I think that's a hex value of 3e8.




EDIT
My idea for sound delays is to basically jump into alxPlay. Somehow we need to keep track of how long the sound has been playing for and how far the camera is from the sound. Using these two, we can determine whether the camera should be able to hear the sound yet. If yes, then we don't need to do anything. If not, then we just don't call alxSourcePlay, but return everything as normal.
Problem is, I really don't know how the audio update system works very well :P.
#4
01/13/2010 (12:30 am)
I looked into this sound delay before, and I think everything you need to do it is in OpenAL.
I never actually got it working as I've changed engine versions so many times and keep starting over. But it is something I will eventually need for my project.
#5
01/13/2010 (1:43 am)
If it's in OpenAL already, that's great news - I'll see what I can find out from the OAL website. That wouldn't be the first time a feature that's in OAL has been missing in TGE - the other one I'm thinking of is the Doppler effect, which someone did a nice resource on enabling. Hopefully this delay stuff is a similar sort of change!

EDIT: Hmm. That was December 2005, though.
#6
01/18/2010 (4:50 am)
One of the things you can do with different sounds played over different distances is to simulate real life frequency changes in audio over time. Sounds at far distances tend to have their high-end frequencies attenuated, and allow the lower bass end to stand out. You don't really need separate sounds in order to do this really, just fiddle with the high frequency and low frequency as sounds get farther out.
#7
01/18/2010 (5:42 am)
Thanks for the tip! That sounds like a good solution, but any idea how to do that in Torque? I guess that'd be something that would have to be managed through OpenAL, and just needs to be exposed to the engine. I'll check the OAL specs I downloaded to see if there's anything that looks remotely like that.
#8
09/20/2010 (10:01 am)
Hey Daniel, I've been looking into longrange audio myself and have also noticed the maxDistance being hardcode-limited somewhere as well.

I've tried looking for the define you speak of and im not sure how you found the hex value or how you modified it to 1000tq/m.

This is all im able to find using the vs2008 search:
...engineaudioaudio.cc(514):   alSourcef(source, AL_MAX_DISTANCE, desc->mMaxDistance);
  ...engineaudioaudio.cc(593):   alSourcef(source, AL_MAX_DISTANCE, desc->mMaxDistance);
  ...engineaudioaudio.cc(1935):         alGetSourcef(mSource[i], AL_MAX_DISTANCE, &max);
  ...engineaudioaudio.cc(2036):      alGetSourcef(mSource[i], AL_MAX_DISTANCE, &dist);
  ...engineaudioaudioFunctions.cc(48):      { "AL_MAX_DISTANCE",                AL_MAX_DISTANCE,                 (Source|Get|Set|Float) },
  ...enginegameaudioEmitter.cc(249):         alxSourcef(mAudioHandle, AL_MAX_DISTANCE, desc->mMaxDistance);
  ...enginegameaudioEmitter.cc(559):           alGetSourcef(source, AL_MAX_DISTANCE, &dist);

Any help would be appreciated.
#9
09/20/2010 (9:16 pm)
Hmm, that's odd. Did you try doing a 'go to declaration/definition' on one of those references to AL_MAX_DISTANCE?

I've just gone back and tested in my latest build - changing 0x1023 to 0x3e8 actually managed to completely screw up the audio somehow :P. I experienced this last time, and didn't manage to fix it (though changing the define back unmessed the audio in this case, thankfully). I think more investigation is required.

EDIT: Also, for some reason I discovered that 0x1023 is actually giving a max distance of something like 4,000m. Don't know why I thought it was only 256 :P. But for some reason, sounds are definitely being chopped off at some short range!
#10
09/21/2010 (9:16 am)
Well I'll be, 'Go To Declaration' led me straight there even though the search returned nothing(strange but good to know!).

I've tried searching many phrases for any other threads about this problem but few seem to have actually noticed it.

P.S.: 4,000m! That would be great, complete overkill but great none-the-less lmao.