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

Re: DSP API proposal/draft

From: Marcus Geelnard <mage@opera.com>
Date: Fri, 27 Jul 2012 09:38:28 +0200
To: "Jussi Kalliokoski" <jussi.kalliokoski@gmail.com>
Cc: public-audio@w3.org
Message-ID: <op.wh3guezum77heq@mage-desktop>
Den 2012-07-27 00:24:41 skrev Jussi Kalliokoski  

> On Tue, Jul 24, 2012 at 12:00 PM, Marcus Geelnard <mage@opera.com> wrote:
> Real men use C FFT libraries. ;)

Yes, I use and love Kiss FFT myself ;)

> You pass in a channel count / stride argument.

Here's the problem (from my point of view): One of the key design goals of  
the API is that for most methods there should be a very clear mapping to a  
pre-written, hand optimized C++/SIMD implementation. Adding things like  
component stride arguments to the methods would likely make it far more  
complex to write optimal routines - you'd probably end up with a couple or  
handful of optimized versions for common cases, and a slower fall back for  
not-so-common cases.

I much more prefer the simple interfaces that are there now, and if you  
need to deal with interleaved data you can use the unpack/pack methods to  
go in to / out from "DSP mode" (the packing / unpacking should be about as  
fast as a memcpy, so usually should be of no concern).

> Yes, I don't really agree with that choice either. Maybe Chris can share
> the rationale behind it when he's back.

I remember that we had a discussion about this, and that Chris managed to  
convince me back then ;)  Too bad I can't find a reference to it now  
(can't remember if it was in a telconf, an issue or a mail conversation)...

> It could be, but doesn't really help as a convolution module can take
> advantage of storing the FFT of the impulse response, whereas here you  
> have two varying signals.

Ah, I wrongfully assumed that the carrier signal would be a fixed  
response. Realize now that it isn't.

> [snipped parts about 2D/3D, though I largely agree with you there]

The more I think about it, the more I'd really like to focus on this API  
as an audio signal processing API at this point. I'm not opposed to adding  
2D, 3D, ND to it, but I think it's much better to do it as a second step  
(and it's probably much better done by someone working specifically with  
2D/3D use cases).

One of the good things about having the audio API as a functional target  
is that it's quite easy to tell if a certain interface will work or not,  
and if all the requited functionality is there to implement key building  

Of course I'd like to keep the door open for future additions (so this  
discussion is good to have), and I think that the current design does not  
prevent extensions into 2D/3D.


Marcus Geelnard
Core Graphics Developer
Opera Software ASA
Received on Friday, 27 July 2012 07:38:58 UTC

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