Bug 76397 – HRTFPanner not rendering correctly on mac port

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Audio

[Chris Rogers]

Steps to reproduce

1. Visit http://chromium.googlecode.com/svn/trunk/samples/audio/simple.html
2. Move the red dot around the center.  The panning is no longer smooth, but jumps around erratically.

I believe this was likely caused by:
http://trac.webkit.org/changeset/104859

It sounds like the azimuth and elevation are reversed, but it may be a different problem.

This may also be an issue on the GTK port where this code has also been used for awhile.

Unfortunately, we currently have no layout test for HRTFPanner...

[Jer Noble]

Is it possible the bug is in the way that Composite.wav was generated?  Should generating Composite.wav be a compile-time step?

[Chris Rogers]

You may want to try a quick test to see if it's simply that the ordering of the azimuth and elevations are reversed.  In HRTFElevation.cpp check out:


    // The concatenated impulse response is a bus containing all
    // the elevations per azimuth, for all azimuths by increasing
    // order. So for a given azimuth and elevation we need to compute
    // the index of the wanted audio frames in the concatenated table.
    unsigned index = ((azimuth / AzimuthSpacing) * HRTFDatabase::NumberOfRawElevations) + elevationIndex;


If you try reversing the roles of azimuth and elevation, it *might* fix the problem - worth checking

Philippe?

[Jer Noble]

I regenerated the composite file, and that appeared to take care of the erratic sound.  Here's the command I used:

sox $( \
  for azimuth in {0..23}; do \
    for elevation in 315 330 345 0 15 30 45 60 75 90; do \
      printf "IRC_Composite_C_R0195_T%03d_P%03d.wav\n" "$(expr $azimuth \* 15)" "$elevation"; \
    done; \
  done;) \
Composite.wav

[Jer Noble]

So it appears the root of the problem is that the description of the Composite.wav file inside HRTFElevation.cpp doesn't match the generated Composite.wav.  This could be as easy a fix as committing a new Composite.wav.

[Chris Rogers]

Sounds reasonable to me.

[Jer Noble]

Created attachment 122680 [details]
Patch

[Jer Noble]

You can check the Composite.wav file by downloading it and placing it in the appropriate location.  (At least on the mac, this means in WebCore.framework/Resources/audio/Composite.wav.  Other ports may add this file as a resource during compile time.)

[Eric Carlson]

Comment on attachment 122680 [details]
Patch

rs=me

[Philippe Normand]

Thanks for taking care of this issue! I indeed wrongly generated Composite.wav :(

[Philippe Normand]

Jer, do you plan to land this or can we use the cq?

[Jer Noble]

Sorry, yes, the cq is fine.

[WebKit Review Bot]

Comment on attachment 122680 [details]
Patch

Clearing flags on attachment: 122680

Committed r105421: <http://trac.webkit.org/changeset/105421>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.