Re: [ecasound] LADSPA latency ouput value

From: Joel Roth <joelz@email-addr-hidden>
Date: Fri Feb 20 2009 - 20:49:56 EET

On Fri, Feb 20, 2009 at 07:10:23AM -0800, Sergei Steshenko wrote:
> Let's forget for a time being about LADSPA and 'ecasound' and let's think
> about the following:
> 1) there may be more than one plugin in chain setup;
> 2) the plugins can be connected in various topologies (serially, in parallel).
> Given the above, what latency should be reported/used/compensated for ?

Hi Sergei,

Ecasound is attempting to be a general-purpose software.
Considering all the possible application scenarios,
I'm not sure that it makes sense for Ecasound to attempt
any latency compensation.

I was writing with regard to Nama, an application that uses

Nama has tracks and buses. No one is using buses, at the
moment, except as required internally for Nama's mixer. So,
I'm dealing with a group of tracks that are implemented as
parallel chains.

Each track can have one of several sources:

* The soundcard via ALSA
* The soundcard via JACK
* Another JACK client
* A WAV file from disk

Differences in the latencies of these sources need to be
considered at some point.

If I'm recording a live performance by close miking the
performers using several soundcard channels I can neglect
the relative latencies, since all signal chains have the
same latency.

If I'm recording while monitoring a backing track--a very
common scenario--then latency is an issue even with no
effects applied.

WAV file 1 --> buffering --> soundcard DAC --> monitor --> performer

                microphone/line input --> soundcard ADC --> buffering --> WAV file 2

It would be great to have a simple tool to measure the
latency of this signal path, perhaps comparing the positions
of peaks of a click track. (Something automatic would be
sweet.) Then the playack of backing track (WAV file 1) could
be delayed by this amount, in order to be correctly aligned
with WAV file 2.

Next is the latency related to the signal processing that
occurs for each track.

Each track in Nama is a chain, and each chain can have
a series of plugins. Many LADSPA plugins report their
latency, so it's easy to sum up the plugin latencies for
each chain and add compensation so each chain adds
the same latency as the chain which add the most latency.

The latter is the immediate case that I am dealing with.

Does this make sense? Am I missing something?



> Regards,
> Sergei.

Joel Roth
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
Ecasound-list mailing list
Received on Sat Feb 21 00:15:01 2009

This archive was generated by hypermail 2.1.8 : Sat Feb 21 2009 - 00:15:01 EET