[LAU] [Bulk] Re: Jack transport - was - Ardour/Muse Jack tempo lock

Tim E. Real termtech at rogers.com
Sun Aug 10 17:47:50 UTC 2014


On August 10, 2014 07:11:24 PM Robin Gareus wrote:
> On 08/10/2014 06:24 PM, Len Ovens wrote:
> > Tim E. Real wrote:
> >> I believe it is crucial that all the apps (MusE included) use the
> >> complete
> >> full feature set of the Jack Transport API for the best accuracy.
> 
> ...and port latencies! Sadly, many jack applications ignore those which
> leads to offsets, even though they share transport position.

Yeah I know. Bummer. Recorded waves are incorrectly shifted etc.

I'm working very hard at the moment on adding automatic + manual 
 latency compensation to MusE. 

It is sooo crucial  - currently the top priority for me !

Man, it sure ain't easy, at least in MusE's case...


PS: While on the subject...

Regarding LADSPA and DSSI and VST DSSI plugins:

Many of them report a latency through a 'latency' output port.
But is there a standard? 
Do some report frames of latency while others report in milliseconds?

Tim.

> 
> > Is there a record enable in there?
> 
> No, there isn't.
> 
> > It seems to me it would be worthwhile
> > for recording audio in one application and MIDI in another or for punch in
> > out. The application would choose to see or ignore such a signal.
> 
> It's not that easy.
> Record enable is an application state not a position in time.
> Rec-arm needs to allocate buffers, prepare files on disk etc etc. It's
> not realtime-safe. For playback there's already a special state:
> JackTransportStarting. Applications should acknowledge that they're
> ready to roll before jack goes into "play". A lot of jack-clients forgo
> this which is already trouble enough, though not directly harmful in
> this case (just possibly out of sync playback).
> 
> Adding ranges (loop, punch), application state (rec-en), or even
> varispeed support would likely increase the mess rather than solve
> anything. All clients need to explicitly agree in order for that to work
> properly.
> 
> Then, there's also the requirement: "We want to provide for ongoing
> binary compatibility as the transport design evolves." [1] (IOW: "don't
> break existing jack applications") which complicates the actual
> implementation.
> 
> That being said, yes, it would be cool. Multiple independent transports
> would be very nice as well, and I want a pony, too :)
> 
> ciao,
> robin
> 
> [1] http://jackaudio.org/api/transport-design.html



More information about the Linux-audio-user mailing list