Extending supported sample rate from 3.0KHz to 192.0KHz for OfflineAudioContext.

Source/platform/audio/HRTFPanner.cpp

Index: Source/platform/audio/HRTFPanner.cpp
diff --git a/Source/platform/audio/HRTFPanner.cpp b/Source/platform/audio/HRTFPanner.cpp
index 04e410dba233decde70c91472d12cf7ba6103ab3..9ec5b9fbbbab99653a9ea41f22047095b487255a 100644
--- a/Source/platform/audio/HRTFPanner.cpp
+++ b/Source/platform/audio/HRTFPanner.cpp
@@ -45,6 +45,8 @@ const double MaxDelayTimeSeconds = 0.002;
 const int UninitializedAzimuth = -1;
 const unsigned RenderingQuantum = 128;
 
+const size_t fftSizes[] = { 64, 128, 256, 512, 1024, 2048, 4096 };
+
 HRTFPanner::HRTFPanner(float sampleRate, HRTFDatabaseLoader* databaseLoader)
     : Panner(PanningModelHRTF)
     , m_databaseLoader(databaseLoader)
@@ -79,8 +81,22 @@ size_t HRTFPanner::fftSizeForSampleRate(float sampleRate)
     // The HRTF impulse responses (loaded as audio resources) are 512 sample-frames @44.1KHz.
     // Currently, we truncate the impulse responses to half this size, but an FFT-size of twice impulse response size is needed (for convolution).
     // So for sample rates around 44.1KHz an FFT size of 512 is good. We double the FFT-size only for sample rates at least double this.
-    ASSERT(sampleRate >= 44100 && sampleRate <= 96000.0);
-    return (sampleRate < 88200.0) ? 512 : 1024;
+    ASSERT(sampleRate >= 3000 && sampleRate <= 192000);
+
+    if (sampleRate <= 5512.5)
+        return fftSizes[0];

[Raymond Toy, 2014/09/05 16:19:52]

Why not just return 64 instead of looking it up in fftSizes[0]? Do the same for
all of the other branches.

[KhNo, 2014/09/05 20:18:14]

Sorry, I misunderstood your previous comment. I fixed

+    if (sampleRate <= 11025)
+        return fftSizes[1];
+    if (sampleRate <= 22050)
+        return fftSizes[2];
+    if (sampleRate <= 44100)
+        return fftSizes[3];
+    if (sampleRate <= 88200)
+        return fftSizes[4];

[Raymond Toy, 2014/09/05 16:19:52]

There's a difference here. In the original the FFT size is 512 if the sample
rate is < 88200. You have 1024 here.

I'm thinking maybe the boundaries should either be the average of the sample
rates you have here, or maybe the geometric mean (sqrt(a*b)) of the sample
rates.  Thus we use a size of 512 for rates between (22050+44100)/2 and
(44100+88200)/2. (33075 to 66150)

Or do you think that a rate of 44101 really needs 1024 instead of 512?

If you do use the average, be sure to use (22050+44100)/2 instead of 33075. It
makes it easier to see where you got these magic numbers.

[KhNo, 2014/09/05 20:18:14]

// So for sample rates around 44.1KHz an FFT size of 512 is good.
The fftsize was 512 for 44100 kHz as above comment.
The fftsize was 1024 for 88200 kHz since condition (sampleRate(88200) < 88200)
is false, original code also had 1024 for 88200 kHz.
Yes, it must have 1024 for 44101. If sampleRate is bigger than 44100, it needs
1024.
fftsize must be a multiple of 2 since fftframe is supporting log2(fftsize)
context size.

So, unfortunately, I think it can not be used your way although 44101 just add 1
from 44100 for convolution.

Do you think I'm still missing something or your comment.

[KhNo, 2014/09/05 20:22:52]

Please ignore above my comment, there  is mistakes, you right.

[Raymond Toy, 2014/09/05 20:28:04]

Ok.  I'm not saying my proposal is the best way, but it seems to give something
closer to the original.
If you want to keep the original behavior with an FFT size of 512 for  22050 <
rate < 88200, that would be ok with me too. I just don't have a good feel right
now for what the FFT size should be for each sample rate.

+    if (sampleRate <= 176400)
+        return fftSizes[5];
+
+    return fftSizes[6];
 }
 
 void HRTFPanner::reset()