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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
