[Openal-devel] Distance units (was Re: There is no 343.3 in Linux
and Mac OS X implementations)
James Tomaschke
james at infosemi.com
Mon Mar 14 16:45:03 PST 2005
pclare at sensaura.creative.com wrote:
>Alexandre Mah <Alexandre at OzEmail.com.au> wrote on 10/03/2005 07:41:44:
>
>
>>OpenAL is unit-free. Any parameter for relating EAX units to OpenAL
>>units should be part of the EAX extension and not a part of OpenAL
>>(since all bridges to an extension should be part of the extension and
>>not part of OpenAL). For example, the EAX extension can have a
>>parameter to say what physical distance (in metres) corresponds to one
>>OpenAL distance unit. None of this should be done in the core OpenAL.
>>
>>
>
>True that current OpenAL is unit-free. And true that for basic distance
>rolloff gain calculations we don't need the units. But to say that this
>should never be done in core OpenAL severely restricts where OpenAL can go
>in the future.
>
>
I think that adding distance to OpenAL sould be fine if you also define
the velocities with the same base. The problem is the AL 1.1 spec
defines velocities as unit-neutral yet the doppler equation used m/s. I
would rather see the AL use the same for all, over any opinion on having
distances or not.
>When rendering 3D audio, absolute distance measurements (where we need to
>know the units) are needed for at least the following:
>
>1) Doppler (assuming we want to express this as a velocity rather than just
>the pitch shift multiplier which, deep down in the audio rendering, is all
>we actually end up with).
>
>
You can specify the speed of sound in the same units as your
source/listener velocites and this is not an issue.
It is a benefit to be able to use your own units for AL, you can avoid
needless conversions when integrating with a graphics engine.
>2) Near field effects (e.g. Sensaura's MacroFX). Since this relates to
>actual human head sizes we have to know the units.
>
>3) Air absorption. This could be expressed unit-free -- but then it makes
>it difficult to have standard reverb presets (assuming air absorption is
>part of the preset).
>
>4) Multi-speaker HRTF processing. Arguable whether this is necessary, but
>at Sensaura we chose to use absolute distance information in the
>implementation of our MultiDrive algorithm.
>
>
AL does not spec these out. However, a vendor could add such support as
an extension, along with a distance unit specifier. I think the proper
route would be to:
1. Let implementors create extensions to features not defined in the
AL spec.
2. Review and discuss them for the next AL spec.
I don't see a reason to add distance to the 1.1 spec at this time.
However...
The examples you enumarated are good ones, I would like to see further
discussion on each and a possible proposal to adding them into the AL spec.
>Although a basic 3D renderer may choose to ignore absolute distance it
>should at least be available to more advanced renderers that can make use
>of it (e.g. items 2 & 4 above).
>
>My view is that distance units are such a core concept that being able to
>set them should be part of the core API and not left to any extension. The
>only reason that some things are in extensions rather than the core is that
>that has been the approved way of developing the API. But now that we are
>revising the API to 1.1 spec we have the opportunity (provided we maintain
>the goal of backward compatibility to 1.0) to put some things that have
>been placed in extensions into their "proper" place in the main API.
>Better to do that (and deprecate the use of that particular
>extension/property) than force absolutely everyone to use the extension.
>
>
http://www.openal.org/extensions.html
What extensions are you referring to when you say, "have been placed in
extensions" that should be added to 1.1?
Extensions are a good way to test ideas out before adding them into
stone. OpenGL has had very important features like multitexturing for
quite some time for it was adopted into the GL spec. Let's see some
HRTF extensions in 1.1.. give the community time to work with it and
give some feedback before we require every implementation to adopt it.
Some extensions can be around forever and still should probably be kept
as an extension.. EXT_vorbis for example. Everyone implementation could
support ogg, but there is no need *require* everyone to.
>>It seems the desire for this "distance factor" is for it to relate
>>OpenAL units to EAX units, but that should really be done in the EAX
>>
>>
>No, distance units are potentially needed for much more. OpenAL may
>currently be unit-less but, IMO, it shouldn't be in the future.
>DirectSound3D (from which OpenAL copied) introduced distance units solely
>for the Doppler calculations but subsequently the units information has
>been used for other things.
>
>
The Doppler Effect equation in 1.0 AL does not use distance units, it is
the 1.1 spec that has added it, for what I see, as the purpose of
covering up broken implementations that added a unit into the equation.
However I am open as far as developing the AL to include units. Right
now I see a benefit in being unit-neutral and I have not seen any
problems in it being so.
AL may have taken ideas from DS3D, however the philosophy of AL is taken
from OpenGL. GL has a bit more of a threshold before adopting extensions
into spec. After all GL is reaching 2.0 and DX is going on 10.0, (since
they are running out of major numbers they are calling it Avalon).
I would like to see more on the features you described, is there any way
to get them posted on:
http://www.openal.org/extensions.html
>I've carefully avoided getting into the whole speed of sound thing here.
>My view is that the Doppler calculations and speed of sound constant is a
>separate issue (although likely connected, depending on how one chooses to
>express Doppler shift) from that of setting distance units.
>
>=====================================================================
>Peter Clare |
>Sensaura | Telephone: +44 1784 476755
>Meadlake Place | Facsimile: +44 1784 476770
>Thorpe Lea Road, Egham | Email: pclare at sensaura.creative.com
>Surrey TW20 8HE | WWW: http://www.sensaura.com/
>UNITED KINGDOM | http://www.gamecoda.com/
>=====================================================================
>
>_______________________________________________
>openal-devel mailing list
>openal-devel at opensource.creative.com
>http://opensource.creative.com/mailman/listinfo/openal-devel
>
>
--
James Tomaschke
Snr. Software Engineer
InfoSemiconductor, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://localhost.localdomain/pipermail/openal-devel/attachments/20050314/a511be04/attachment.html
More information about the Openal-devel
mailing list