On 08/10/2014 06:24 PM, Len Ovens wrote:
...and port latencies! Sadly, many jack applications ignore those which
leads to offsets, even though they share transport position.
> Is there a record enable in there?
No, there isn't.
> It seems to me it would be worthwhile
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
Then, there's also the requirement: "We want to provide for ongoing
binary compatibility as the transport design evolves."  (IOW: "don't
break existing jack applications") which complicates the actual
That being said, yes, it would be cool. Multiple independent transports
would be very nice as well, and I want a pony, too :)
Linux-audio-user mailing list