[Openal-devel] New AL 1.1 Spec and Beta Windows Implementation

[James Tomaschke]

Garin Hiebert wrote:

>>  Remeber that even though there are now units specified in the AL 
>> where it never used to, we still have the ability to override it.  
>> That is a fair compromise, before the draft spec had 343.3 imposed on 
>> us.
>
>
> One small point of clarification -- there is no attempt here to 
> "specify units" in AL.  The default of 343.3 may be convenient for a 
> world where the distance units are expressed in meters, but that does 
> not imply that the units are necessarily in meters.  If you define 
> your world in the arbitrary distance units "oglits," and the speed of 
> sound in that world is 343.3 oglits/second then you're set.  If you 
> define your world in feet, and you want the speed of sound to be 343.3 
> feet/second, then you're set.  So, the AL_SPEED_OF_SOUND parameter 
> does _not_ imply units.  Whatever your units are, set the 
> AL_SPEED_OF_SOUND parameter appropriately and you're set.  AL doesn't 
> need to know how your unit system relates to a "real world" system at 
> all.

Correct, m/s are not required to use AL and that is why I have no issue 
with the current spec.
I belive the new 343.3 value is the only constant in AL that implies a 
unit, which is why Alexandre was wondering about reverting to 1.0 as it 
implies no unit, I would classify it as a look-and-feel issue and not a 
technical problem because it does not impose the value on us.

When I think about this issue I ask myself the question: "Was there a 
reason why 1.0 was used in the first place?"  I don't know what was in 
the heads of the creators, but my guess is that they were simply trying 
to avoid any inclination of units in the spec.

I understand that existing implementations used 343.3 even though it 
wasn't in defined in spec.  I am willing to cede any preference for 1.0 
over 343.3 because I know you guys are trying to make some compromises 
and I'm willing to do so as well.

> In earlier threads of conversation on Doppler, it was brought up that 
> one of the selfish reasons Creative wanted things redefined "our way" 
> was that we wanted to specify the world unit's relationship with 
> meters (for air absorption and other EAX features).  This is actually 
> a point where we have compromised with our detractors in the new 
> spec.  In our new generic effects extension, we will be integrating a 
> "distance factor" parameter to relate the arbitrary AL units to 
> meters, because that information will be useful to the effects extension.

I wouldn't call Creative selfish, it is natural for Creative want to 
leverage it's technology.  I would even like to say that I encourge 
Creative to add their technology into AL because it keeps the it modern 
and feature-rich.  I believe my suggestion/criticism in the previous 
threads was that extensions were the best place to introduce these new 
features instead of changing the base AL and it looks like you are doing 
just that, so no complaints here.

Do you have a draft of the generic effects extension you guys are 
working on? It sounds very interesting.

>> I do think that what the vendors did was wrong, I'm with you on 
>> that.  Not developing the spec before implementing their own version 
>> and then changing the spec to match it is inpolite to say the least.  
>> I know you feel the same way, but I do not see any evil intentions.  
>> In the future I hope to see a sharing of ideas and development of the 
>> spec before implementation, and recently I have seen evidence of that 
>> with the discussions on the new 1.1 draft spec.  That's how we can 
>> prevent incompatibilities from happening in the future.
>
>
> I'm glad you don't see any evil intentions, because there certainly 
> weren't any.  Doppler has always been broken in the 1.0 spec, in 
> various ways.   The development of a specification alone, even in 
> public with a lot of input, will never result in a perfect API.   
> There will always be issues, and many of them won't be seen until 
> there are implementations and people are using them.  It is a huge 
> credit to Bernd and the original participants in the 1.0 spec that 
> there were so _few_ problems.  With the new 1.1 spec and beta Windows 
> SDK from yesterday, I am confident that we now have a specification 
> for an excellent API that can actually be implemented on all our 
> target platforms.
>
> Garin


I realize that the AL will not be exactly what I desire, but that is why 
I am willing to pick my battles.  All I ask for really is that my 
suggests are digested, it would be arrogant to ask for anything more.

I would like to reiterate that I am happy with the compromises in 
regards to the removal of the hardcoded 343.3 value to a customizable 
parameter and moving the distance unit into an extension.  It's basicly 
what I would have done in your situation.  There has been a lot of good 
development in bringing AL to a state where the implementations will 
work the same across different platforms.

I haven't checked, but how active is the linux implementation being 
worked on?  Does it need to be brought up to speed for 1.1?  I could 
start working on some patches if help is needed.

/james

-- 
James Tomaschke
Snr. Software Engineer
InfoSemiconductor, Inc.