[Pdmtl] Analyse audio en C?

Stephen Sinclair radarsat1 at gmail.com
Wed May 20 11:01:51 EDT 2009

2009/5/20 Michal Seta <mis at artengine.ca>:
> Le 17 mai 2009 16:30, Alexandre Quessy <alexandre at quessy.net> a écrit :
>> Quelqu'un connaît une bonne librarie audio en C ou C++ ?
>> C'est pour faire du fiddle~ avec le moins de latence possible.
> Note, que faire du  "fiddle~" à l'extérieur de Pd tu vas épargner
> seulement la longueur du block de Pd.  C'est à dire, 64 échantillons
> par défaut.  À part de ça, FFT impose une fenêtre de x échantillons,
> et en plus une grande fenêtre donne des meilleurs résultats.  As-tu
> essayé de rouler [fiddle~] à l'intérieur d'un subpatch avec [block~
> 1]?  Évidemment on compromet la performance mais possiblement moins de
> latence.  Peut-être CSound ou SC peut faire ça mieux...  je ne sais
> pas.

Yes, that's it.  It's important not to confused optimization and
latency.  Latency comes from a variety of sources, suboptimal code
being only one.  Things like buffer sizes and FFT windows are much
more important sources of latency than function pointer dereferencing.

I was curious about Alex's comment only because in my opinion Pd is
actually quite close to optimal in this regard... once you connect a
chain of DSP blocks, they are essentially just called one after the
other, by walking down a list of function pointers.  From my
understanding it's effectively as fast as C++ virtual functions.

One step better is if you don't need to dereference a pointer, i.e.,
call a function directly (like non-virtual functions, or normal C
functions), and one step better (the best possible) is when functions
are inlined, which removes the function call overhead completely.

But when you have an audio buffer of X milliseconds, function pointer
dereferencing doesn't matter so much.  It's more of a problem in an
architecture like STK where a series of functions are called literally
for every sample, but in Pd everything is oriented around block
processing so I wouldn't worry about it.

But again, there may be _other_, perfectly valid reasons for wanting
to use a Pd external's code outside of Pd.  For example I once got an
algorithm that was designed as a Pd external running on a DSP card by
calling its perform() function directly, which was pretty cool.. :)


More information about the Pdmtl mailing list