Re: FFT demo and some questions

I'd like to throw in my vote for configurable sample rates as well.  I'm
recording audio from the microphone via webrtc and I have to resample the
stream if it isn't at the desired sample rate (44100).  This causes major
performance issues if the default sample rate is too high.  It is also very
unintuitive to figure out how to adjust the sample rate at the OS level for
most people.

On Fri, Sep 11, 2015 at 10:09 AM, Raymond Toy <rtoy@google.com> wrote:

> First, this is the wrong list. This list is for issues with the spec. You
> should probably be posting to public-audio-dev.
>
>
> However,...
>
> On Tue, Sep 8, 2015 at 1:21 PM, Stephen C Phillips <steve@scphillips.com>
> wrote:
>
>> Hi,
>>
>> I've only just joined the mailing list, so please accept my apologies if
>> I ask questions already resolved - I can't find answers from my searches.
>>
>>
>> First, I'd love it if you took a look at an application I have just
>> published on my Morse code website to listen to the microphone and attempt
>> to decode any Morse code sounds that are audible. It uses the Web Audio API
>> of course and the FFT function in particular. I haven't seen many (any?)
>> demos that have a practical use of the FFT so I did wonder if you'd like to
>> add it to the demos list?
>>
>> The page is here: http://morsecode.scphillips.com/labs/decoder/
>>
>
> That's a really neat demo with a nice explanation of what's going on!
>
>
>>
>>
>> Secondly, in writing the application I came across some limitations with
>> the API and wondered if they had been discussed:
>>
>>
>> 1. It would be useful to set the sample rate.
>>
>> Chrome has it set to 48 kHz which of course gives a maximum sampled
>> frequency of 24 kHz. For the Morse code decoder, a max frequency of 4 kHz
>> would have been fine. The reason it might matter is that my application
>> uses a 512 point FFT which gives a time-step of 10ms (between samples) and
>> a frequency resolution of 93 Hz. if it was sampled at 6 kHz (say) then you
>> could do a 64 point FFT to give the same resolutions while still having a
>> max frequency higher than required - saving some processing time.
>>
>
> Selectable sample rates (on output) have been considered but no one has
> actually done the work to spec it. I don't think we've considered being
> able to select the sample rate on the input side.
>
> Also, many OSes allow you to set the audio sample rate. Perhaps you can
> change that on your OS for the rate that you want.  WebAudio should be able
> to use the new sample rate.
>
>>
>>
>> 2. The time resolution of the analysis is limited by the fact that the
>> FFT input data samples cannot overlap.
>>
>> Or at least I assume this to be so. My application uses the AnalyzerNode
>> with a 512 point buffer and a ScriptProcessorNode of the same size. When
>> the ScriptProcessorNode is called (every 512 frames) it inspects the
>> contents of the AnalyzerNode to get the frequency-domain data..
>>
>> What I'd like, is to be able to do a FFT using a moving window of input
>> data (i.e. a FIFO queue of samples) in order to get a higher time
>> resolution. Combined with a slower sampling period (see (1)) this might be
>> feasible.
>>
>> I'm wondering whether it would be fast enough to use a
>> ScriptProcessorNode to do the FFT itself in this way (i.e. implement the
>> FFT in JavaScript) but have not tried yet.
>>
>
> You don't get higher resolution by overlapping frames.  You just get a
> smoother resulting FFT.  The only way to get higher resolution is to use a
> larger FFT and to sample fast enough.
>
> You could certainly do the FFT in Javascript, but it probably won't be as
> fast as the FFT built into WebAudio, but you'd have more control over
> exactly how you want to do your FFT overlapping and smoothing.
>
>


-- 
Thanks,
Josh Nielsen
@joshontheweb <http://twitter.com/joshontheweb>
joshontheweb.com