osgAudio makes me nervous sometimes
Chris 'Xenon' Hanson
// At 70 the gain will be half of full!
sound_state->setReferenceDistance(70);
Nope. That 70 means that at 70 units away, it will be the FULL specified gain volume.
I'm not even sure the original author fully understood what they were doing.
To recap for posterity some of what Doug and I discussed, the Rolloff factor allows you
muck about with the inverse-distance-square attenuation model. In the real world, this is
unrealistic, as the normal model is how sound really attenuates. openAL lets you mess with
this. FMOD doesn't give you a single value to twiddle -- most of the time it forces you to
use the realistic model. Except that you can load a custom mapping table if you really want.
I presume FMOD does this (prevents you from messing with the log attenuation model)
because if audio is being done in hardware, you can't rely on being able to twiddle that
factor, of perhaps if you do, you'd fall off the "fast path" and into software.
Presumably FMOD assumes that if you want a custom table, you understand and are prepared
to be off the fast path.
Also, I had heard about Windows releases after Vista doing a substantially greater
amount of audio work in software, to alleviate inconsistencies of support by various
hardware, and because software and CPU processing is fast enough now. I don't know how
true this is.
--
Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/
Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting.
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
Doug McCorkle
There's this comment in osgaudio.cpp, which dates from the osgal.cpp days:
// At 70 the gain will be half of full!
sound_state->setReferenceDistance(70);
Nope. That 70 means that at 70 units away, it will be the FULL specified gain volume.
I'm not even sure the original author fully understood what they were doing.
Doug
Chris 'Xenon' Hanson
> I just tested the osgaudio example with OpenAL and I set the RollOff to one and there is a
> HUGE difference. I think all examples should be set to 1 to clarify our example and
> testing usage. If a user wants to play with it they can but at least all of the examples
> are starting from the same base usage no matter what backend is chosen.
I've already done this.
Even after that, I still haven't figured out why FMOD attenuation isn't working as
expect. I've debugged right down to
_FMODChannel->set3DMinMaxDistance(_minDistance, _maxDistance);
and it seems legit. I'm looking for other causes.
> Doug
Doug McCorkle
On 3/16/2011 3:56 PM, Doug McCorkle wrote:I've already done this.
> I just tested the osgaudio example with OpenAL and I set the RollOff to one and there is a
> HUGE difference. I think all examples should be set to 1 to clarify our example and
> testing usage. If a user wants to play with it they can but at least all of the examples
> are starting from the same base usage no matter what backend is chosen.
Even after that, I still haven't figured out why FMOD attenuation isn't working as
expect. I've debugged right down to
_FMODChannel->set3DMinMaxDistance(_minDistance, _maxDistance);
If you change the refe distance to 10 do you get the attenuation you expect?
Doug
Chris 'Xenon' Hanson
> If you change the refe distance to 10 do you get the attenuation you expect?
Err, yes, but the behavior still didn't really seem rational.
I finally found the king's horse's horseshoe nail.
Dating all the way back to osgAL, the SoundState constructor has set the maxDistance to
100. In the IASIG I3DL2 Inverse Distance Clamped Model that openAL offers, which is
similar to FMOD's FMOD_3D_LOGROLLOFF, this means at distances beyond maxDistance,
attenuation will be clamped to what it was at maxDistance.
So, beyond 100 units, attenuation was non-varying.
When reference (min) distance was small, like 10, this gave SOME range for attenuation,
but it still wouldn't go all the way away. At reference distances of 70, this gave only a
30-unit range where attenuation could work, basically undetectable.
I have altered the constructor to initialize it to FLT_MAX, and now attenuation works
lovely. You could have set it manually on the SoundState with setMaxDistance(), but I
don't see why you should have to override a silly the default all the time.
I'm not sure how or why this would have worked well in openAL though. The end of section
3.4 of the openAL spec says "The default attenuation model is
AL_INVERSE_DISTANCE_CLAMPED." and osgaudio.cpp explicitly does:
osgAudio::SoundManager::instance()->getEnvironment()->setDistanceModel(osgAudio::InverseDistance);
So, I would think they ought to behave roughly the same.
Anyway, I think distance attenuation should work properly in FMOD backend now.
I'll see about putting in Linear functionality next.
Doug McCorkle
On Mar 16, 2011, at 8:30 PM, Chris 'Xenon' Hanson wrote:
> On 3/16/2011 4:33 PM, Doug McCorkle wrote:
>> If you change the refe distance to 10 do you get the attenuation you expect?
>
> Err, yes, but the behavior still didn't really seem rational.
>
> I finally found the king's horse's horseshoe nail.
>
> Dating all the way back to osgAL, the SoundState constructor has set the maxDistance to
> 100. In the IASIG I3DL2 Inverse Distance Clamped Model that openAL offers, which is
> similar to FMOD's FMOD_3D_LOGROLLOFF, this means at distances beyond maxDistance,
> attenuation will be clamped to what it was at maxDistance.
>
> So, beyond 100 units, attenuation was non-varying.
>
> When reference (min) distance was small, like 10, this gave SOME range for attenuation,
> but it still wouldn't go all the way away. At reference distances of 70, this gave only a
> 30-unit range where attenuation could work, basically undetectable.
>
> I have altered the constructor to initialize it to FLT_MAX, and now attenuation works
> lovely. You could have set it manually on the SoundState with setMaxDistance(), but I
> don't see why you should have to override a silly the default all the time.
>
> I'm not sure how or why this would have worked well in openAL though. The end of section
> 3.4 of the openAL spec says "The default attenuation model is
> AL_INVERSE_DISTANCE_CLAMPED." and osgaudio.cpp explicitly does:
> osgAudio::SoundManager::instance()->getEnvironment()->setDistanceModel(osgAudio::InverseDistance);
>
> So, I would think they ought to behave roughly the same.
>
> Anyway, I think distance attenuation should work properly in FMOD backend now.
>
> I'll see about putting in Linear functionality next.
This one sort of torques me off because I was on that same track Tues and Wed but I saw this in in SourceFMOD.cpp:
_maxDistance = std::numeric_limits<float>::max();
and thought it was being used but in reality it was being overriden by SoundState. That is very confusing. If there is a way to make this more clear that would be very helpful. I am not sure how we do that but it would have saved us all a bunch of time.
Doug
Doug McCorkle
On Mar 16, 2011, at 8:30 PM, Chris 'Xenon' Hanson wrote:
> On 3/16/2011 4:33 PM, Doug McCorkle wrote:
>> If you change the refe distance to 10 do you get the attenuation you expect?
>
> Err, yes, but the behavior still didn't really seem rational.
>
> I finally found the king's horse's horseshoe nail.
>
> Dating all the way back to osgAL, the SoundState constructor has set the maxDistance to
> 100. In the IASIG I3DL2 Inverse Distance Clamped Model that openAL offers, which is
> similar to FMOD's FMOD_3D_LOGROLLOFF, this means at distances beyond maxDistance,
> attenuation will be clamped to what it was at maxDistance.
>
> So, beyond 100 units, attenuation was non-varying.
>
> When reference (min) distance was small, like 10, this gave SOME range for attenuation,
> but it still wouldn't go all the way away. At reference distances of 70, this gave only a
> 30-unit range where attenuation could work, basically undetectable.
>
> I have altered the constructor to initialize it to FLT_MAX, and now attenuation works
> lovely. You could have set it manually on the SoundState with setMaxDistance(), but I
> don't see why you should have to override a silly the default all the time.
>
> I'm not sure how or why this would have worked well in openAL though. The end of section
> 3.4 of the openAL spec says "The default attenuation model is
> AL_INVERSE_DISTANCE_CLAMPED." and osgaudio.cpp explicitly does:
> osgAudio::SoundManager::instance()->getEnvironment()->setDistanceModel(osgAudio::InverseDistance);
>
> So, I would think they ought to behave roughly the same.
>
> Anyway, I think distance attenuation should work properly in FMOD backend now.
>
> I'll see about putting in Linear functionality next.
This works like a champ. Thanks for tracking this issue down. I still have the problem at 1.0 x 10^9 but I think that one is out of our control.
Doug
Doug McCorkle
I was just thinking about this issue and we could greatly reduce confusion if we put all of these constants in the Config.h file. That way no matter which backend is being used or which class is setting a member variable they would all be referencing the same source. Thoughts?
Doug
Chris 'Xenon' Hanson
> This one sort of torques me off because I was on that same track Tues and Wed but I saw this in in SourceFMOD.cpp:
> _maxDistance = std::numeric_limits<float>::max();
> and thought it was being used but in reality it was being overriden by SoundState. That is very confusing. If there is a way to make this more clear that would be very helpful. I am not sure how we do that but it would have saved us all a bunch of time.
Yup.
The problem is that a SoundState sort of wraps the lower object. Maybe refactor
something out so that there is a common table of init parameters or something?
Chris 'Xenon' Hanson
> I still have the problem at 1.0 x 10^9 but I think that one is out of our control.
Since it seems like such a "human" limit, I inquired about it on the FMOD forum:
http://www.fmod.org/forum/viewtopic.php?f=7&t=14285
Chris 'Xenon' Hanson
> I was just thinking about this issue and we could greatly reduce confusion if we put all of these constants in the Config.h file. That way no matter which backend is being used or which class is setting a member variable they would all be referencing the same source. Thoughts?
You beat me to it.
It seems like this would be a good way to do it. The trouble would be with non-numeric
constants that are different for FMOD and openAL. Maybe there could be a sub-config file
for each subsystem for enums that can't be compiled in the other subsystem?
Doug McCorkle
On Mar 16, 2011, at 9:41 PM, Chris 'Xenon' Hanson wrote:
> On 3/16/2011 8:20 PM, Doug McCorkle wrote:
>> I was just thinking about this issue and we could greatly reduce confusion if we put all of these constants in the Config.h file. That way no matter which backend is being used or which class is setting a member variable they would all be referencing the same source. Thoughts?
>
> You beat me to it.
>
> It seems like this would be a good way to do it. The trouble would be with non-numeric
> constants that are different for FMOD and openAL. Maybe there could be a sub-config file
> for each subsystem for enums that can't be compiled in the other subsystem?
Yeah, that sounds like a good idea. It could be included after the definition of the backend define in the Config.h file.
Doug
Paul Martz
> On 3/16/2011 8:19 PM, Doug McCorkle wrote:
>> I still have the problem at 1.0 x 10^9 but I think that one is out of our control.
>
> Since it seems like such a "human" limit, I inquired about it on the FMOD forum:
> http://www.fmod.org/forum/viewtopic.php?f=7&t=14285
In that post, you said you get "full attenuation" at a distance of 1x10^9; did
you mean full gain? I'd think "full attenuation" would mean minimum gain. I just
don't want your post to be misunderstood. (Hey, maybe I'm the one that's
confused...)
-Paul
Chris 'Xenon' Hanson
> In that post, you said you get "full attenuation" at a distance of 1x10^9; did you mean
> full gain? I'd think "full attenuation" would mean minimum gain. I just don't want your
> post to be misunderstood. (Hey, maybe I'm the one that's confused...)
Sorry, you're right, full gain. I've corrected it.
> -Paul