[Openal] Speed of sound... does it incur propagation delays?

[Stephen J Baker]

Anthony Lovell wrote:
> I see reference within OpenAL to the speed of sound being  configurable, 
> but it only mentions it in combination with doppler  calculation and I 
> see no reference to its use it applying suitable  pre-delays between 
> buffers being passed to the OpenAL and their  actual playback commencing.
> 
> For instance, I'd like to see any sound that I hand to an ALSource  take 
> a full second to start playback if my Listener is 343.3 units  from the 
> Source and I have configured the speed of sound to have  proper metric 
> units.
> 
> Is this part of OpenAL's functionality, or did this vital feature  (much 
> more apparent than doppler effects in day to day life) somehow  miss the 
> boat?

Hmmm - good point!

I strongly suspect it's only used for doppler - although I agree with you
that this effect could (and should) be implemented.

The deal is that in OpenAL 1.0, there was no speed of sound setting and
the doppler was kinda kludged.  I don't think that this kludge could have
implemented the desired delay in startup of the sound.  When OpenAL 1.1
was written, they changed the doppler math to use the speed of sound
(which makes much more sense) - but I'd be suprised if anyone thought
to change the onset time to account for the delat.

If OpenAL 1.1 does implement doppler without the initial delay then the
sound of an object that starts out a long way off and rushes towards you
would end prematurely.

This could have nasty effects on simultenaity.

Suppose we have the sound of a cow being flung by a trebuchet (kindof a
'Mooooooo*SPLAT*!')  Let's suppose the cow takes 5 seconds from launch to
splat so we make a 5 second sound effect that starts with a 'Mmmm' and
ends with a '-ooo*SPLAT*'.

Suppose the trebuchet is 340 meters away (~one second of audio delay)
and shoots the cow such that it lands right at the feet of the poor
listener.

The application will start the sound at the instant the trebuchet is
fired - this is what we expect it to do.

If OpenAL starts the sound (incorrectly) at the precise moment the
application tells it to - then the cow takes 5 seconds to get here
- but the doppler shift will result in the 5 second sound sample
being replayed faster than we expected - so the *SPLAT* sound occurs
too soon...*before* the instant when the cow/hamburger hits the ground
right next to the listener!

If we had delayed the onset of the sound for one second (as in reality),
then correctly calculated doppler would have the splat happening at
exactly the right time.

Wow!  Deep result!  Einstein would have been pleased with this.

However, this makes me wonder (again) about the asymmetry between
listener motion and source motion in the doppler math.  I was sceptical
about this at the outset - and now, I'm even more sceptical.  Since
the end of the sound effect MUST be precisely when the cow hits the
ground, there should be no difference between the cow flying towards
the listener - or the cow staying still and the listener rushing
towards it.  Either way, the doppler shift must exactly compensate
for the initial delay due to the distance between source and listener.
Hence the doppler math should be symmetrical between source velocity
and listener velocity - and the speed of the air (due to wind or
whatever) must be irrelevent.



-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker at link.com           http://www.link.com
Home: sjbaker1 at airmail.net       http://www.sjbaker.org