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

Re: Resolution to republish MSP as a note

From: Marcus Geelnard <mage@opera.com>
Date: Mon, 06 Aug 2012 20:48:13 +0000
Message-ID: <20120806204813.qffupsjci25cckkg@staff.opera.com>
To: public-audio@w3.org
Citerar Chris Wilson <cwilso@google.com>:

> On Mon, Aug 6, 2012 at 11:31 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
> 2) Can you elaborate on how the performance can be "at least"  
> equaled? I don't see how you expect to get significantly better  
> performance than
> natively-implemented code doing DSP operations on a separate high-priority
> thread.

Actually, that's not how I read it - not sure what Jussi meant - but  
anyway, I can imagine some cases where you'd actually get better  
performance with a custom node, if:

- You have a native implementation of the DSP API (i.e. the custom  
code should be about as fast as the corresponding native nodes when  
doing the same tasks).
- You can bunch together a number of native nodes into a single custom  
node (i.e. less routing/mixing overhead).
- You can optimize/eliminate some operations, since you have more  
freedom to deal with data/operations as you wish, without being  
confined to the routing interfaces of audio nodes.

Now, this is purely speculation, since I have no concrete examples of  
such cases. I just know from experience that low-level usually offers  
more optimization opportunities than high-level (e.g. assembler vs.  
C++), so I'm just pointing at the possibilities here.

In general, and especially for common operations, my bet would be that  
native nodes will be faster than custom nodes.

Received on Monday, 6 August 2012 20:48:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:01 UTC