[nama] Re: Latency compensation
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Tue, 24 Apr 2012 18:31:49 -0400
On Mon, Apr 16, 2012 at 02:06:57PM -1000, Joel Roth wrote:
> On Mon, Apr 16, 2012 at 04:44:19PM -0400, S. Massy wrote:
> > On Sun, Apr 15, 2012 at 10:22:06AM -1000, Joel Roth wrote:
> > > Thought about this issue last night. Here's an outline:
> > >
> > > Case 1 - ordinary tracks, no buses except Main
> > >
> > > + Get latency for each user track by querying LADSPA effects
> > > + Adjust each track to suit highest latency found
> > >
> > > Case 2 - sub-buses
> > >
> > > + if track is mix track for a sub-bus, add latency of the loop device
> > > + Recurse over member tracks, adjust latencies to match max latency
> > > + Add max to mix track's total
> > I guess I'm stating the obvious here, but, as far as I can see, the
> > formula would be: latency_comp = max_latency-this_track_latency. The only
> > tracks exempt from compensation would be those with max_latency.
> >
> > Other thoughts/questions:
> > - Do we compensate on the sub-buss user-track or pre-compensate on the
> > member tracks themselves? The latter seems simpler.
>
> The key to my (necessarily recursive) thinking, probably expressed poorly
> above, is that all member tracks of a bus (all nodes that
> immediately precede another node) must have equal
> latency. That leads to the next question:
Yes, thinking recursively or incrementally has never been a strong point
of mine. :(
>
> > - How do we handle sub-busses on sub-busses?
>
> max_latency( track ) = sum_latency( track->effects ) + max_latency(
> track->predecessors )
>
> > - What about ssend busses, insert tracks, etc.
>
> Does anyone even use send busses? The principle of
> divide-and-conquer says 'worry about this later'.
Send busses can be practical, especially for reverb. But I like your
philosophical approach to these things. :)
[...]
> I believe most if not all cases can be addressed by starting
> with the Master track and recursing over its predecessors.
Great!
> > I'd prefer no processing at all for compensation, but, if that's the
> > only way, I suggest using processing across the board, i.e on every
> > track to minimise jitter and other possible side effects, as well aas
> > simplify the process. The problem is, of course, I don't know how CPU
> > hungry that processing would be.
>
> I didn't think about jitter. I plan for the case that there
> are enough cycles available for processing. I doubt that
> delays cost anything more than amplifying a signal, which
> I consider to be cheap.
As I posted earlier, I experimented with -etd and the results seemed
promising. Using jack_delay, it seemed to be able to introduce very
stable latency, even down to values like 0.25ms. I even generated a test
setup with 100 chains with an etd effect each all feeding into a loop
and ecasound consumed about 30% of CPU on my dual-core 2.2ghz system and
took about 120Mb of RAM.
Cheers,
S.M.
Other related posts:
