Hello, I’m making a web app with the HTML5 wasm version of FMOD 2.02.19 and was wondering if FFT DSP is supported in the non-reduced version? Using the logging version, whenever I get the spectrum data, length and numchannels is always zero, so I thought it might not be supported. I couldn’t find it explicitly stated in the docs, so I just wanted to make sure.
Thank you for your time.
After trying around, I couldn’t get it to work, but I found a workaround using the browser WebAudio API for anyone who might find it useful:
On the JS frontend, you can get the AudioContext from Module.mContext and the AudioWorkletNode from which FMOD outputs, from Module.mWorkletNode some time after the module initializes. With the AudioContext you can then create an AnalyserNode, then connect the worklet node to it 
I think this might break later on if the API changes though. Accessing the mWorkletNode and mContext breaks into the private implementation.
Hi,
The FFT DSP is supported by both non-reduced and reduced HTML5 versions of FMOD. However, after doing some digging, and the parameters appear to be bugged: while the window size and type parameters are exposed to the API, the spectrum data and dominant frequency parameters are not. I’ve passed this along to the development team for further investigation.
I’m happy to hear you managed to find a workaround in the meantime!
Thanks for looking into the issue, that’s great to hear it’s supported! I was trying to use the length and numchannels to iterate over the spectrum data so I wouldn’t make a bad access. Would it be safe for now to set these parameters even if I can’t read it, or just rely on the default parameters listed in the docs?
As a side question relating to the workaround, it’s nice to be able to access the AudioContext and AudioWorklet - would these possibly ever be exposed in an official way?
Unfortunately FMOD_DSP_PARAMETER_FFT cannot be get/set at all at the moment, so attempting to do anything with it/its members or the dominant frequency parameter will do nothing - in that respect, it should be safe.
There is precedent with System::getOutputHandle, so it’s possible. I’ve added it to our internal feature/improvement tracker.
I understand, thanks for confirming that. The WebAudio solution is working great, but it would be cool to be able to attach the FFT at any point in the signal chain instead of at the end, like if the user changes the master bus gain for volume control, the signal won’t get diminished. (With web audio, the audio graph points only in one direction, so unless you have ownership of the audio nodes further down the graph you can’t access them.)
That would be interesting to see the System::getOutputHandle interface incorporated 
Anyway, thanks again for your helpful answers.