- From: Yves Raimond <Yves.Raimond@bbc.co.uk>
- Date: Wed, 16 Jun 2010 12:00:59 +0100
- To: Chris Marrin <cmarrin@apple.com>
- Cc: robert@ocallahan.org, Chris Grigg <chris@chrisgrigg.org>, public-xg-audio@w3.org
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? Best, y > > ----- > ~Chris > cmarrin@apple.com > > > > >
Received on Wednesday, 16 June 2010 11:01:36 UTC