Re: FFT demo and some questions

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.