[nama] Re: Latency compensation
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Mon, 16 Apr 2012 16:44:19 -0400
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.
- How do we handle sub-busses on sub-busses?
- What about ssend busses, insert tracks, etc. What cases, besides
external inserts, employ loops?
- Latency compensation for recording? Master bus adds another loop hop,
so recorded material should probably be compensated for that.
>
> Case 3 - inserts
>
> + Ask Massy to figure this one out. :-)
>
> Seriously, for JACK client programs I think it will be:
> + loop devices
> + JACK I/O latencies
> + JACK client latencies
> + soundcard loopback latency (for hardware inserts)
Yes, I wrote on LAU to try and find out how we could estimate that. I
think fixing this will help the sound quality of inserts.
>
>
> Now, we can implement compensation in two ways
> + adding an extra offset term to 'playat'
I like this because it does not involve extra processing.
> + using LADSPA 1436 (lcrDelay)
I haven't looked into it, but aren't there simpler delay plugins?
>
> lcrDelay is the most general solution, since playat can only
> be used for WAV file playback.
- What would be examples of non-wave playback? Compensating between two
paths using the same source file but introducing different delays,
such as external inserts?
- LCR_Delay might introduce a latency of it own.
>
> In terms of cycles, the cheapest would be to use lcrDelay
> only when necessary.
- LCR_Delay may introduce its own latency.
- LCR_Delay may introduce sound colouration (no idea).
- If one track introduces latency, all other tracks need compensation,
so tracks are more likely to need compensation than not.
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.
That's it for now.
Cheers,
S.M.
Other related posts:
