W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: AnalyzerNode - magnitude/phase

From: Marcus Geelnard <mage@opera.com>
Date: Sun, 29 Sep 2013 17:56:11 +0200
Message-ID: <CAL8YEv50m7OVbJHTQK9EGi80MgowwmrWQEmpykoo2BbHOVUnOQ@mail.gmail.com>
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:25 UTC