On Thu, May 03, 2012 at 02:22:55PM -0400, S. Massy wrote: > It's fairly straightforward code: the only bit I couldn't wrap my > (admittedly small) mind around is this cascading assignment: > $setup->{sibling_latency}->{$_->wet_name} > = $setup->{sibling_latency}->{$_->dry_name} > = $setup->{track_latency}->{$_->wet_name} > = track_ops_latency($::tn{$_->wet_name}) > + $additional_latency Welcome to the funhouse! In brief, the maximum latency for the two arms is the latency of any effects on the wet track plus the additional latency of the JACK client and JACK connection. (We assume send/receive from the same client.) Here is the long explanation: We need to calculate and compensate the latency of the two arms of the insert. $setup->{sibling_latency} is the maximum latency value measured among a group of parallel tracks (i.e. bus members). For example, Low, Mid and High tracks for mastering are siblings. When we get the maximum for the group, we set $setup->{sibling_latency}->{track_name} = $max $setup->{track_latency}->{track_name} is the latency calculated for a track (including predecessor tracks when that is significant.) So later on, when we get to adjusting latency, the amount is given by $setup->{sibling_latency}->{track_name} - $setup->{track_latency}->{track_name} Capische? > The code indeed needs to be fixed for mismatched units, as you say. Note > that frame/srate will give you a value in microseconds, not miliseconds, > so the code in loop_device_latency needs to be modified. Perhaps it > would make more sense to tally latency in samples separately and convert > it to miliseconds just once? I believe frames/srate gives a value in seconds. I recall you've previously mentioned a preference for calculations in samples :-) Cheers to you, for looking at my snake's nest (better than spagetti, I suppose. :-) Your charmer and frequent bite victim of said snakes, Joel > Cheers, > S.M. > -- Joel Roth