Re: AnalyzerNode - magnitude/phase

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