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