[Clam-devel] does ladspa increase latency ?
globot
gglobot at gmail.com
Sun Aug 19 22:48:08 PDT 2007
>Message: 4
>Date: Fri, 17 Aug 2007 18:19:21 +0200
>From: Pau Arumi <parumi at iua.upf.edu>
>Subject: Re: [Clam-devel] does ladspa increase latency ?
>To: clam-devel at llistes.projectes.lafarga.org
>Message-ID: <46C5CA89.5020408 at iua.upf.edu>
>Content-Type: text/plain; charset="iso-8859-1"
>
>En/na globot ha escrit:
>
>"does ladspa increase latency"
>yes. specifically when jack (or other backend) uses a buffer size <
> 512.
>
>
>
cool i am not day dreaming :)
>the latency is determined by the LadspaWrapper audio in/out port
>sizes, which is hardcoded to 512.
>this is not only limited to ladspas, most time-domain processings
>get the port size from the network wich is also hardcoded to 512.
>
>
>
according to my result it seem to be a little strange cause i got 7 ms
for the whole network processing with ladspa plugins (48000Hz).
512 frames = 10.667ms
>ok, regarding latency, this is an important flaw. it is a known
>flow and fortunately easy to fix as well. it's a matter of exposing
>the host (or backend/network-player) buffer size to the
>processings. and the sample rate as well, for the matter.
>
>
>
nice
>as we use to develop new features driven by necessity i think you
>give us the perfect excuse here :)
>i've been working on a patch this afternoon but didn't had time to
>finish it (found some difficulties with JackNetworkPlayer
>initialization). i'm attaching it as is now just in case anyone
>wants to continue from there. i'm afraid i won't have the chance to
>write code till first of september.
>
>note that the patch is not ready. it will assert on NE loading.
>parameter propagation is still not in place but all needed
>interface is there.
>
>cheers!
>pau
>
>
I would be happy to continue your patch, but i must leave tomorrow for
some family affaires, i won't be able to work before 28.
I will have a look, but my poor knowledge of your code will surely slow
me down :)
perhaps i will concentrate on other part of my project, like database
and network, it is easier to do :)
>
>
>
>>hi,
>>
>>today i was testing ladspa plugins (because there is a lot of usefull
>>things in ladspa), but i still need realtime processing, and i have
>>mesured some increase in latency when using ladspa plugin. The increase
>>is made in such a way i can't get my network running under 310 frames of
>>latency between a micro and outputs.
>>
>>the network is simple: input -> gainIn -> EQ -> gainOut -> output
>>all measurements are done with a sample rate of 48000Hz
>>____________________________________________________
>>if EQ = FFT_fftw3 -> 3BandFilter -> IFFT_fftw3
>>and gain is made with the CLAM::AudioMixer
>>buffersize is set to 32
>>i get around 150 frame of latency.
>>_____________________________________________________
>>if EQ = FFT_fftw3 -> 3BandFilter -> IFFT_fftw3
>>if i remove gainIn and gainOut and connect directly
>>i get aroud 118 frames of latency.
>>_____________________________________________________
>>if EQ = FFT_fftw3 -> 3BandFilter -> IFFT_fftw3
>>if for gainIn and Out i use ladspa plugins (id 1181, simple amplifier)
>>i get around 320 frames of latency
>>_____________________________________________________
>>if EQ = multiBandEQ (ladspa plugin id 1197)
>>and use ladspa plugins (id 1181, simple amplifier) for GainIn and Out
>>with buffer size of 32
>>i get around 329 frames of latency
>>_____________________________________________________
>>if EQ = multiBandEQ (ladspa plugin id 1197)
>>and gain is made with the CLAM::AudioMixer
>>with buffer size of 32
>>i get around 329 frames of latency
>>_____________________________________________________
>>
>>the thing that seem strange here is for the test 4 and 5, because if i
>>increase the buffersize for the ladspa Equalizer, my latency change (if
>>i set 64 for the ladspa EQ buffer size, i got around 360 frames of
>>latency) but i still got a mysterious latency that is added to the theory.
>>
>>All the latency values given are approximative (maybe a few frames of
>>difference) because my eyes was tired of watching supper zoomed in
>>sounds. :)
>>
>>to get those result i take tow computer, divide the micro cable in two
>>one for PC1 input 1, one for PC2 input 2, then i take the output 1 of
>>PC1 to the input 2 of PC2.
>>PC1 is for sound processing, and PC2 is for measurment
>>
>>MIC --o---> (in1)PC1 (out1)
>> | |
>> o---> (in1)PC2 |
>> (in2)<------o
>>
>>
>>PS: use fixed font with to read this message
>>
>>
>>
More information about the clam-devel
mailing list