Re: FFT demo and some questions

Thank you for replying even though I am perhaps on the wrong list. I hope
you will indulge me if I post one more time. The public-audio-dev list
seems to be very quiet.

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!
>

Thank you. I've updated it with a little more info and a selectable FFT
size now.

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.
>

Although I do not know if I am nearing the speed limitation of my machine
with my current application, it just seems wasteful to be sampling 8 times
faster than is necessary. If the API let me do FFTs of overlapping windows
then an unnecessarily high sample rate might then become a problem.

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.
>

When I say "time resolution" I mean that an FFT provides frequency domain
data about the time period that it has sampled. Given that the FFT is
windowed with a Blackman window, the bias of the frequency domain output it
towards the centre point of the time domain input. The non-overlapping FFTs
therefore give information primarily about the frequencies present in the
centre of each sampling period. If the windows overlap then you do get more
information. In my application I need to detect precisely when the sound of
a certain frequency has started or stopped. A moving window would be able
to pin-point those moments more precisely (I believe) with a suitable
analysis and threshold.

Certainly, sampling faster would also achieve a smaller time resolution but
I don't have that option in the API.

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.
>

Indeed - I'd rather avoid it. I've adapted my application now so that you
can choose a 256, 512 or 1024 point FFT and the 256 point FFT (with a time
step of 5.3ms) seem to work effectively.

Regards,
Stephen Phillips.