Re: [ecasound] loop input/output

Rapha??l Mouneyres wrote:
> Hi Joel,
>
> > Hmm. This looks similar to Nama's "send bus" feature,
> > in which the raw or processed signal from all tracks in the bus
> > get sent to another destination (such as a musician's
> > monitor) via auxiliary tracks with faders.
>
> that's exactly what it is. I've been considering nama for a while
> (thanks to Julien help also). But at the end, i do need to remote
> control the system, and ecasound TCP ECI interface is just perfect and
> working as is. Setting up something similar with nama looks too
> complicated to me. On the other hand, nama has really great features.
> I'll see how things are going on.

Thanks. Please keep us posted on your progress!
I'm happy to hear about your use cases.
 
> > Cool. If you do it in separate processes, you have
> > a possibility to change one part without interrupting
> > other parts. If you don't need that flexibility,
> > why not do one mighty chain setup?
>
> thus my experiments. All the static "cables" are within the same
> ecasound sesion (microphones, foh, fx sends, and musicians monitors)
> from jack endpoints to hardware inputs or outputs.
> Then more ecasound sessions are started with various parameters for
> each song (drums submix, audio players, mutitrack audio recorder,
> ecamonitor....) and they won't interrupt the master foh mix and blow
> away the speakers ;)
>
> > Probably you're aware that the Ecasound -b parameter (buffersize
> > in samples) controls the latency of a loop device.
>
> mmm, i haven't played with this one yet. My test with vocals,
> guitar,bass and keyboards where totally acceptable with a 64 buffer on
> jackd settings and ecasound (i use a HDSP9652@email-addr-hidden). I'm just waiting
> for the drummer to come in an complain about the latency ! As we use
> an edrum, there is more latency than only the audio one.
> So i can have a lower latency on the ecasound side and reduce loop
> latency ? It will probably increase the CPU ?

from 'man ecasound'

    -b:buffer size

    Sets the size of buffer in samples (must be an exponent of 2).
    This is quite an important option. For real-time processing, you
    should set this as low as possible to reduce the processing delay.
    Some machines can handle buffer values as low as 64 and 128. In
    some circumstances (for instance when using oscillator envelopes)
    small buffer sizes will make envelopes act more smoothly. When not
    processing in real-time (all inputs and outputs are normal files),
    values between 512 - 4096 often give better results. Default is
    1024.

Kai explained it like this:

    there's always the delay from loop output to its input.
    This follows from the fixed routing logic: 1) read inputs,
    2) process chains, 3) write to outputs. So when we've
    reached (3) and wrote to a loop object, it'll have to wait
    until next engine iteration to read it in phase (1) again.

If you set -b to 64, that's 64/48kHz, that a little over 1ms
per loop device (or IO buffer IIUC).

Regards,

Joel

-- 
Joel Roth
  
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list