Base assumption is that it is not possible to get raw audio into FFT analyser node OR Analyzer node not working correctly at high frequencies (and all frequencies in some cases and versions of Safari) Same code does work in all other major browsers and PWA's other than Mobile/Desktop Safari and iOS mobile PWA's (save to home screen stand alone mobile web apps) This is essentially a continuation of bug 179411 with a different title that makes no assumption as to the cause. The root problem is that by design getUserMedia({audio: true}) enables multiple filters to be by default ON and applied to the raw sampled audio microphone stream requiring the programmer turn them all and individually OFF prior to attaching the stream to an analyzer node for full frequency domain FFT conversion of a sample. In the past, Google and Mozilla used different constraint names and I am not sure that it is still necessary to disable all these but it appears to not hurt anything either. The code below still works, and has for over a year at least (i.e. provides proven correct FFT conversions across the entire audio spectrum based on the available sample rates of 44.1 KHz and 48Khz) as of Nov 2019 in desktop and mobile Chrome (MacOS, iOS, Android), Firefox (MacOS), Opera (MacOS), Firefox (MacOS). It may also work in the above browsers on other platforms but my testing is limited. However, this bug specifically relates to the fact that this code does NOT work in desktop Safari 13.0.3, mobile Safari iOS 13.1.3 or iphone PWA webclip also iOS 31.1.3. I have no way of knowing why it still does not work or how Apple tests that audio filters are disabled or that raw audio is indeed being fed into their FFT analyzer node or even that their analyzer node is performing FFT conversions correctly. However, I can say that using their current Safari Technology Review Release 95 (Safari 13.1, WebKit 15609.1.7) the FFT analyzer is working well enough so that my digital audio demodulator can successfully demodulate 300 ms digit pulsed in 1 KHz bands I use below 9 KHz. But still does not work above 13 Khz (between 9 and 13 is untested). I can also say that above 10 KHz, the frequency domain output from the analyser node is all zeros. This is indicative of the raw audio sample also being strongly attenuated or also all zeros. Which is somewhat compelling that it is a problem with the samples to the analyzer node and not the fft analyzer itself. Feeding the analyser a recorded stream of known high frequencies might prove this absolutely (but I haven't had the time). With respect to this code running in an iOS PWA webclip (aka saved to home screen PWA). AFAIK PWA run standalone web clips still do not support getusermedia or analyser node of any kind. So this is more of a complaint against a non working feature rather than a bug for that specific case. ... analyser = acontext.createAnalyser(); try{ analyser.fftSize = 32768; // Maximum FFT size is 32768 by the standard; Desktop Safari handles this but apparently not mobile }catch(err){ analyser = null; acontext = null; //alert("can't create analyser.fftSize == 32768"); testlog("can't create analyser.fftSize == 32768"); } ... navigator.mediaDevices.getUserMedia({audio: { echoCancellation: false, noiseSuppression: false, autoGainControl: false, googEchoCancellation: false, googAutoGainControl: false, googExperimentalAutoGainControl: false, googNoiseSuppression: false, googExperimentalNoiseSuppression: false, googHighpassFilter: false, googTypingNoiseDetection: false, googBeamforming: false, googArrayGeometry: false, googAudioMirroring: false, googNoiseReduction: false, mozNoiseSuppression: false, mozAutoGainControl: false }, video: false})
It would be good to identify whether ScriptProcessorNode gives the same results on Safari vs. Chrome and Firefox when running in parallel on MacOS. Agreed with testing AnalyzerNode on its own as well.
Thanks for filing the bug btw!
<rdar://problem/57443285>
On MacOS, one possibility would be to use kAudioUnitSubType_HALOutput to disable VPIO processing.