Re: About AudioPannerNode

Some more comments with regards to 3d audio and panning:

In section 11 it is stated that "The units used in the coordinate system
are not defined, and do not need to be because the effects calculated with
these coordinates are independent/invariant of any particular units such as
meters or feet".

This is not true. There are near-field effects with almost any source or
receiver of sound, and the head and ears are no exception. For this and for
other reasons, in order to make a convincing binaural illusion of a very
close sound source it will be necessary to know the distance to that source
in physical units.

Also, this is inconsistent with the whole idea of relative velocities and
Doppler shift based on the speed of sound.


Using a vector for the orientation of an AudioPannerNode hard-codes the
assumption that the sound source radiates sound in a cylindrically
symmetric manner. There are objects, such as line-array speakers, that do
not fit this assumption. It would be better to consistently make
orientations always described by two vectors.


Although the use of sound cones is common in video gaming, it is completely
unphysical and unrealistic. No actual sound source radiates that way. Real
sound sources are better described by (frequency-dependent) 1st order polar
patterns, such as are used to describe microphones. These can be computed
without any angle conversions and trigonometry.


For 3d audio, the sound source would normally be called an emitter. Calling
it a AudioPannerNode is odd and confusing and obscures the fact that it is
a source of audio in the virtual world.


Sincerely,
   Frederick


On Wed, Jan 23, 2013 at 1:08 AM, Frederick Umminger <
frederick.umminger@gmail.com> wrote:

> I'm pretty late responding to this, but I would recommend ONLY supporting
> developer-supplied HRTFs.
>
> From experience, doing good, convincing 3d audio with HRTFs is not as easy
> or obvious as many research papers might lead you to believe.
> I know of only one vendor (http://smyth-research.com/index.html) selling
> a product that provides truly convincing HRTF-based processing.
> Most implementations have poor externalization, not to mention the usual
> font-back and height confusions.
>
> As a result, a normative HRTF implementation will most likely end up being
> a mediocre implementation.
>
> But since it will be standardized, there is a big risk it will permanently
> kill innovation in 3d audio for WebAudio.
>
> It is guaranteed to do this if there is no support for developer-supplied
> HRTFs.
>
> On the other hand, if developer-supplied HRTFs are supported, it is no big
> deal for a developer to use one of the free HRTF sets
> that might have been the basis for the normative HRTF.
>
> Sincerely,
>    Frederick
>
>
> On Wed, Jun 27, 2012 at 12:41 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>> Den 2012-06-27 07:50:31 skrev Robert O'Callahan <robert@ocallahan.org>:
>>
>>
>>  On Wed, Jun 20, 2012 at 5:39 AM, Chris Rogers <crogers@google.com>
>>> wrote:
>>>
>>>  I'm happy to share the measured HRTF files that we use in WebKit.  I'm
>>>> not
>>>> sure if they should be normative or not...
>>>>
>>>>
>>> If the HRTFs aren't standardized then it will make testing much harder
>>> and
>>> developers won't be able to get predictable results. So there should be
>>> normative HRTFs.
>>>
>>> If later there is a need to support alternative (perhaps "better") HRTFs
>>> then we could add a way for developers to use their own HRTFs, or choices
>>> of additional built-in HRTFs.
>>>
>>>
>> +1
>>
>>
>>
>> --
>> Marcus Geelnard
>> Core Graphics Developer
>> Opera Software ASA
>>
>>
>