[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.. :)
Steve
More information about the Pdmtl
mailing list