This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Audio-ISSUE-62 (AudioPannerNodeUnits): AudioPannerNode units are underspecified [Web Audio API] http://www.w3.org/2011/audio/track/issues/62 Raised by: Marcus Geelnard On product: Web Audio API https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#AudioPannerNode What are the units of the set* vectors? AudioListener.speedOfSound has the unit m/s. If that is correct (?), the set* vectors should use meters and meters / second too. Suggestion: Don't use meters (not in AudioPannerNode, and not in AudioListener), to allow for custom unit systems. Also, the units of coneInnerAngle, coneOuterAngle and coneOuterGain are undefined.
Similar to OpenAL, the units used in the coordinate system are not defined, and do not need to be. Quoting from the OpenAL spec: http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.pdf 3.3. Space and Distance OpenAL does not define the units of measurement for distances. The application is free to use its own units, for example, meters, inches, or parsecs. OpenAL provides means for simulating the natural attenuation of sound according to distance, and to exaggerate or reduce this effect. However, the resulting effects do not depend on the distance unit used by the application to express source and listener coordinates. OpenAL calculations are scale invariant. Fixed: https://dvcs.w3.org/hg/audio/rev/b21b04a1ec0e
One more thing: Section 4.15. The AudioListener Interface reads "// in meters / second (default 343.3)" for the speedOfSound attribute, which is obviously wrong, then.
(In reply to comment #2) > One more thing: Section 4.15. The AudioListener Interface reads "// in > meters / second (default 343.3)" for the speedOfSound attribute, which is > obviously wrong, then. Sorry Marcus, I wasn't clear about that part. The doppler effect uses the .speedOfSound attribute in conjunction with the velocity vectors for both the AudioPannerNode and the AudioListener. These velocity vectors are in meters/second and are independent of the units used for position and orientation. This is taken directly from the OpenAL specification. Added more specific text for the setVelocity() methods and also added the doppler shift algorithm which uses these values. Fixed: https://dvcs.w3.org/hg/audio/rev/f4bef40f3efe
(In reply to comment #3) > Sorry Marcus, I wasn't clear about that part. The doppler effect uses the > .speedOfSound attribute in conjunction with the velocity vectors for both > the AudioPannerNode and the AudioListener. These velocity vectors are in > meters/second and are independent of the units used for position and > orientation. This is taken directly from the OpenAL specification. I still don't understand why we need to have a unit at all (I see nothing in the algorithm that depends on actual units). Could it not be unit-less, and work just as it is? It would be confusing (IMO) to force the usage of m/s for some vectors, and then let people use whatever they want (e.g. inches or miles) for other vectors. I'd personally prefer an all-or-nothing solution: either all vectors are in m and m/s, or they are all in [custom] and [custom]/s, or possibly even [custom_length] and [custom_length]/[custom_time] (like miles/h).
(In reply to comment #4) > (In reply to comment #3) > > Sorry Marcus, I wasn't clear about that part. The doppler effect uses the > > .speedOfSound attribute in conjunction with the velocity vectors for both > > the AudioPannerNode and the AudioListener. These velocity vectors are in > > meters/second and are independent of the units used for position and > > orientation. This is taken directly from the OpenAL specification. > > I still don't understand why we need to have a unit at all (I see nothing in > the algorithm that depends on actual units). Could it not be unit-less, and > work just as it is? It would be confusing (IMO) to force the usage of m/s > for some vectors, and then let people use whatever they want (e.g. inches or > miles) for other vectors. > > I'd personally prefer an all-or-nothing solution: either all vectors are in > m and m/s, or they are all in [custom] and [custom]/s, or possibly even > [custom_length] and [custom_length]/[custom_time] (like miles/h). I'm just taking this interpretation from the OpenAL specification. But you're right, we could just say that .speedOfSound is the speed in arbitrary units which are also used by the velocity vectors. These units are independent of the units used for position and orientation vectors. How does that sound?
(In reply to comment #5) > I'm just taking this interpretation from the OpenAL specification. But > you're right, we could just say that .speedOfSound is the speed in arbitrary > units which are also used by the velocity vectors. These units are > independent of the units used for position and orientation vectors. > > How does that sound? That sounds like the better choice, yes. I'm sure there are some reasons why OpenAL uses m/s, but unless we know why and it's a strong enough reason, I don't think that it's enough for us to just duplicate that part. PS. One guess as to why OpenAL want to use m/s it so that the default speed of sound = 343.3 makes sense. On the other hand, this is kind of similar to the gravity property in the Bullet physics library, which defaults to a unit-less 10 (all things are unit-less in Bullet).
Web Audio API issues have been migrated to Github. See https://github.com/WebAudio/web-audio-api/issues
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.