- From: Chris Marrin <cmarrin@apple.com>
- Date: Wed, 16 Jun 2010 08:36:54 -0700
- To: Yves Raimond <Yves.Raimond@bbc.co.uk>
- Cc: robert@ocallahan.org, Chris Grigg <chris@chrisgrigg.org>, public-xg-audio@w3.org
On Jun 16, 2010, at 4:00 AM, Yves Raimond wrote: > On Tue, Jun 15, 2010 at 04:09:55PM -0700, Chris Marrin wrote: >> >> On Jun 15, 2010, at 1:49 PM, Robert O'Callahan wrote: >> >>> On Wed, Jun 16, 2010 at 8:22 AM, Chris Grigg <chris@chrisgrigg.org> wrote: >>> Further to my comment on the separate "Target platforms?" thread, on what range of target platforms did you find the performance to be equivalent? Are there any of our target platforms that are not capable of realtime performance with that FFT implementation? I would worry about very skinny clients not only for FFT but for any compute intensive operations. >>> >>> Vlad's tests were on a desktop machine. We should do experiments on a mobile device and report back. However, I see no fundamental reason why the observed closeness in performance between JS and C would be unattainable in lower-end devices. Our ARM backend is less mature but that will improve. >> >> This makes the presumption that C performance would be sufficient. I think it's important we take into consideration audio hardware, especially GPU based audio processing. A design like Chris' accommodates hardware implementation while a direct JavaScript implementation does not. > > Sorry, I am not sure I understand correctly - it looks to me like GPU based optimisation is an orthogonal issue to either design (Chris's or direct Javascript implementation). Most GPU-based computations, at least for audio, are pretty low-level and could be used to optimise a vector-based computation library in a JS interpreter. I don't see Chris's design as a prerequesite for using hardware optimisation? Chris' proposal is node based. As such, it can easily be optimized for a given platform. The Mozilla proposal simply provides audio samples which can be used by JavaScript and then played (or not in the case of audio visualizers). It sounds like you're advocating an API to go with the Mozilla proposal. That can be optimized too, but it's not currently being proposed. If it were, it would be an SVG (Chris' proposal) vs Canvas (Mozilla's proposal with an API) discussion. Either way, I don't believe access to the audio samples with pure JavaScript processing is sufficient. ----- ~Chris cmarrin@apple.com
Received on Wednesday, 16 June 2010 15:37:28 UTC