- From: Marcus Geelnard <mage@opera.com>
- Date: Sun, 29 Sep 2013 17:56:11 +0200
- To: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
- Cc: Chris Lilley <chris@w3.org>, Chris Lowis <chris.lowis@gmail.com>, public-audio@w3.org
Here's what I think... First of all I don't think that using an AnalyzerNode as a source for audio will work very well since it's not in sync with the rest of the audio engine (afaict). You really need to use a ScriptProcessorNode for that. With that said I think that getting full complex data from the analyzer node is a good thing. On the other hand I think that the most generic solution would be for the node to deliver full resolution time domain data and leave the fft details to the JS developer. /Marcus 2013/9/28, Srikumar Karaikudi Subramanian <srikumarks@gmail.com>: > (replying inline) > > On 27 Sep, 2013, at 10:48 PM, Chris Lilley <chris@w3.org> wrote: > >> Hello Chris, >> >> Friday, September 27, 2013, 11:22:52 AM, you wrote: >> >>> i) Allow getFloatFrequencyData() to return an array of complex values >>> somehow. >> >> Seems more technically correct and less likely to be implemented (oh >> no, complex numbers) >> >>> ii) Add methods for getRealFrequencyData() and >>> getImaginaryFrequencyData() >> >> ditto (name is correct but scary) > > An independent getComplexFrequencyData(realArray, imagArray) would serve > these purposes I think. > >>> iii) Add getFloatPhaseData() which would return the phase of the >>> calculated spectrum, and leave getFloatFrequencyData() returning the >>> magnitude. >> >> That seems like the best option to me. And yes, getting the phase is >> useful. What about an allpass filter as an example? Square waves in, >> tilted square waves out, that sort of thing. > > If such a getFloatPhaseData() is specified, then the standard would need > to include a specific way of dealing with phase continuity - i.e. phase is > modulo range [-PI, PI] or [0, 2PI] or decide that jumps across the 2PI > boundary > are resolved by offsetting the phase to be continuous, etc. The Real/Imag > split would simplify these decisions and put the power in the hands of the > dev. R/I would also be computationally simpler (no log->exp and > arctan->sin/cos > ops) when passing to an IFFT function for synthesis. > > -Kumar > >> -- >> Best regards, >> Chris mailto:chris@w3.org >> >> > >
Received on Sunday, 29 September 2013 15:56:38 UTC