Re: Multitrack mode latency effects

Kai Vehmanen <[email protected]>
Newsgroups gmane.comp.audio.ecasound.general
Message-ID <[email protected]>
Hi,

On Wed, 2 May 2012, Joel Roth wrote:

> I'm in the midst of working on latency compensation
> for Nama, to equalize the latency in all parallel
[...]
> My understanding is that in multitrack mode,
> Ecasound slightly offsets the WAV inputs to keep the
> signals in sync with device inputs.

In short, yes.

> My questions are:
>
> * how is Ecasound multitrack mode compensation calculated?

You can either pass the offset manually (but limited to multiples of 
buffersize), or let ecasound calculate (the usual case).

The algorithm looks at the reported latency of real-time inputs and 
outputs (e.g. ALSA or JACK reported latencies), and calculates the 
difference. This diff reflect how many input samples are recorded before 
the matching reference output (the existing tracks) were actually played 
out (so samples recorded when the musician could not have heared anything 
yet). This is adjusted by skipping some frames of recorded input.

> * Are there any reasons to manually determine the offset?

While the latency system is hooked to JACK latency APIs (so it works at 
least simple setups), there might be cases (with complicated JACK setups) 
where it does not do the right thing.

> * Is this distinct from the latency adjustment functions
>  provided to jackd through the -I and -O arguments?

Yes. The ecasound multitrack compensation only deals wih internal delays, 
e.g. the ALSA/JACK buffering. It does not cover for external delays (e.g. 
if you route the monitor signal via external gear that adds significant 
delay). Jackd's -I and -O were added to "publish" these external delays to 
the rest of the JACK system.

So in theory ecasound should be able to utilize the values passed with -I 
and -O. One catch is that currently, ecasound's delay compensation is
buffersize-based, and this probably becomes a problem with -I and -O 
(unlike the typical delays with soundcard i/o, these delays rarely are 
multiples of buffersize/interrupt-interval. There's no blocking reasons 
why this could not be fixed, just some added work to send partial buffers 
dpwn the pipeline in these cases.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ecasound-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.