[Clam-devel] does ladspa increase latency ?

[globot]

>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
>>
>>    
>>