Bug 98294 – Spatialized panning renders incorrectly with USE_CONCATENATED_IMPULSE_RESPONSES

• Component: Web Audio
• Status: RESOLVED FIXED

[Chris Rogers]

In a recent WebKit mac-port build or Safari 6 try:
http://chromium.googlecode.com/svn/trunk/samples/audio/simple.html

The spatialization is rendering incorrectly (compare to Chrome which doesn't use USE_CONCATENATED_IMPULSE_RESPONSES).
The Doppler demo also illustrates serious problems where up/down are scrambled:
http://chromium.googlecode.com/svn/trunk/samples/audio/doppler.html

This may also be an issue on the GTK port which builds with USE_CONCATENATED_IMPULSE_RESPONSES

[Hajime Morrita]

Created attachment 167228 [details]
Patch

[Hajime Morrita]

Comment on attachment 167228 [details]
Patch

Oops. Wrong bug. Sorry for the noise.

[Philippe Normand]

I've been busy on other things lately but I can maybe find time to check it this week. So Chris, if you disable concatenated impulse responses on mac it works as expected?

[Chris Rogers]

(In reply to comment #3)
> I've been busy on other things lately but I can maybe find time to check it this week. So Chris, if you disable concatenated impulse responses on mac it works as expected?

I didn't try, since it would require a little more tweaking for build, to copy the resources into the right location to properly test.  But, I'm pretty sure it would work as expected since then it would be going through the same path as Chrome, which is still working correctly.

I thought I helped you guys test this when we switched you over to concatenated, and I *seem* to remember it was ok.  But my memory might be wrong.  Whatever has happened, the impulses now seem to be "scrambled" somehow...

[Philippe Normand]

I can confirm the rendering indeed differs between GTK and Chromium. Noticeable especially with the doppler example, when the red dot approaches the green dot there is some kind of of scrambling, not sure how to describe it.

[Philippe Normand]

And that disabling concatenated impulse responses fixes the issue. Not sure I'll have time to work on this issue this week though, busy on other tasks :(

[Jer Noble]

I regenerated the Composite.wav file in <http://trac.webkit.org/changeset/105421>, to fix <https://bugs.webkit.org/show_bug.cgi?id=76397>.  At the time, it appeared the azimuth and elevation orders were backwards.

Has anything in HRTFElevation.cpp changes which might impact the order in which things are pulled from the composite file?

[Chris Rogers]

(In reply to comment #7)
> I regenerated the Composite.wav file in <http://trac.webkit.org/changeset/105421>, to fix <https://bugs.webkit.org/show_bug.cgi?id=76397>.  At the time, it appeared the azimuth and elevation orders were backwards.
> 
> Has anything in HRTFElevation.cpp changes which might impact the order in which things are pulled from the composite file?

Not that I'm aware of.  You could try an "svn log" of this and associated files.  I can't remember if I ever verified the result of <http://trac.webkit.org/changeset/105421>, so it might have been a problem even then.

[Philippe Normand]

Created attachment 171457 [details]
Merged  impulse responses

I noticed that in the previous file the elevations were not correctly ordered. In HRTFElevation, printing the azimuth, elevation and calculated index, for elevation and azimuth = 0, the index is 0. For elevation=15 and azimuth=15 the index is 11 and so on. In the previous Composite.wav file the elevations for 315, 330 and 345 were added at the wrong indexes, I think. Here's how I generated this file:

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

Can you please test again with this file Chris?

[Chris Rogers]

(In reply to comment #9)
> Created an attachment (id=171457) [details]
> Merged  impulse responses
> 
> I noticed that in the previous file the elevations were not correctly ordered. In HRTFElevation, printing the azimuth, elevation and calculated index, for elevation and azimuth = 0, the index is 0. For elevation=15 and azimuth=15 the index is 11 and so on. In the previous Composite.wav file the elevations for 315, 330 and 345 were added at the wrong indexes, I think. Here's how I generated this file:
> 
> AUDIO_DIR="Source/WebCore/platform/audio/resources"
> sox $( \
>   for azimuth in {0..23}; do \
>     for elevation in 0 15 30 45 60 75 90 315 330 345; do \
>       printf "$AUDIO_DIR/IRC_Composite_C_R0195_T%03d_P%03d.wav\n" "$(expr $azimuth \* 15)" "$elevation"; \
>     done; \
>   done;) \
> Composite.wav
> 
> Can you please test again with this file Chris?

The new file sounds good -- I just tested it in Safari 6

[Philippe Normand]

Committed r132993: <http://trac.webkit.org/changeset/132993>