AudioEmitter distance problem

#1 le bump

#2 I have only done 1 audio emitter so I am not sure on this one. When I did it, it worked perfectly (I puta bird sound in a grove of trees, lame I know lol).

What release are you using?

#3 release 1.1.1 - I'm just about to test it out on the latest head.

#4 I am using head....no issues...

#5 hmm just dl'd latest head 30 mins ago. Still broken. Works fine when you approach it for the first time. Once the sound starts looping, it never stops, no matter how far away you are.

Here is my mission file entry:

new AudioEmitter() {
      position = "-67.6419 51.1173 241.818";
      rotation = "1 0 0 0";
      scale = "1 1 1";
      profile = "OceanWaveNormal";
      description = "AudioDefaultLooping3d";
      fileName = "0";
      useProfileDescription = "1";
      outsideAmbient = "1";
      volume = "1";
      isLooping = "1";
      is3D = "1";
      referenceDistance = "1";
      maxDistance = "10";
      coneInsideAngle = "360";
      coneOutsideAngle = "360";
      coneOutsideVolume = "1";
      coneVector = "0 0 1";
      loopCount = "-1";
      minLoopGap = "0";
      maxLoopGap = "0";
      type = "0";
         minDistance = "5.0";
   };

and here is my emitter profile:

datablock AudioProfile(OceanWaveNormal)
{
   filename = "~/data/sound/testing.wav";
   description = "AudioDefaultLooping3d";
	preload = false;
};

#6 Ken,

I am getting the same problem. Audio that chases me down all over the world. Funny thing, for our pirate racing game, its an ocean wave sound. I have messed with a bunch of numbers and looked at your datablock. We're on the same failed path.

Has anyone got this working correctly? Thanks.

-Adam

#7 Misery loves company :-) I've tried it with 2d & 3d looping sounds. The wav files are mono files. Still no joy.

#8 This is the same problem we faced in Tribes2. The outer falloff is not necessarily handled correctly by the audio driver (making an assumption here that the current OpenAL driver is essentially the same as the Miles driver for this issue).

The 'driver' (OpenAL/Miles) creates a DirectSound 3D audio buffer with the DSBCAPS_MUTE3DATMAXDISTANCE cap set. This is supposed to mute the sound when the listener-source distance is greater than the outer falloff distance that the user sets. Unfortunately, most every 3d audio card out there ignores this flag (software audio renderers do not have this problem) and default to using the outer falloff distance as the 'distance beyond which the sound does not get any quieter'. Doh!

For Tribes2 we just pushed out the outer falloff distances so that the sound would essentially be attenuated to nothing before reaching the outer falloff (at which point it would stay constant).

--- john

#9 So, do you mean, extend the MaxDistance way beyond what I want it to be, and control the attenuation by dropping the driving gain (volume setting)?

#10 Bump for Rick O's attention !

#11 bump

#12 I have been bumped. I have a ton of things on my mind and on my plate as of late. If you guys can do the investigation it would greatly improve my abillity to squeeze in a fix in the near future.

--Rick

#13 No problem Rick. Just wanted to make sure you were aware of it, in case you might have said -
"oh yeah, that's the framistrance, you just need to enable the Gegglizer, that's all" or something like that :-)

#14 Yes and no. The MaxDistance does not control the attenuation factor for a given source - only the inner falloff is responsible for that. You should push out the outer falloff distance so that the source's gain is not audibly clamped to it (unfortunately an incorrect behavior since the audio buffer is created with the cap set to mute the sound at MaxDistance - not clamp it).

Like you mentioned, you could alter the gain per-source to achieve a more correct behavior. There will be artifacts which will only be minimized if the update period is rather frequent - and possibly rather expensive (hell, the hardware is supposed to be providing you with this service). You might actually find it to be faster to use the software audio providers and not use the EAX/A3D ones (no idea if this is currently exposed through OpenAL).

Good luck,

--- john

#15 *bump* Anyone tackling this?

#16 I've been mucking about in the audio code a lot lately. I'll take a look and see if I can figure anything out.

#17 I had this problem in Trakers.

The only way I could get it to work correctly was to NOT use an audio description datablock.

When I declared everything in the emmitter itself it worked fine.

Might help guys :)

#18 WOOHOO!!! Daniel - that did the trick ! here is my emitter from the mission file:


new AudioEmitter(soundWater01) {
position = "-2399.6 -1410.8 49.2";
rotation = "1 0 0 0";
scale = "1 1 1";
fileName = "~/data/sound/WavesDay.wav";
useProfileDescription = "0";
outsideAmbient = "1";
volume = "1";
isLooping = "1";
is3d = "1";
referenceDistance = "10";
maxDistance = "20";
coneInsideAngle = "180";
coneOutsideAngle = "180";
coneOutsideVolume = "1";
coneVector = "0 0 1";
loopCount = "-1";
minLoopGap = "2";
maxLoopGap = "3";
type = "30";
};

Not sure about the cone angle stuff, but this works !!!

note: I had to set the actual profile field to NULL as well as setting useProfileDescription to 0 ...

Thanks Daniel !

#19 I was digging in the audio code and I found these lines commented out in alxUpdate() in audio.cc:


if(mForceMaxDistanceUpdate)
alxUpdateMaxDistance();

if you uncomment them and set mForceMaxDistanceUpdate = true, it will mute sound sources when they hit the max distance. I'm not sure why it was commented out, except that the attenuated gain at max distance is still loud enough that you can hear the mute.

#20 ring a bell for Daniel and Kurtis