18 Nov
2017
18 Nov
'17
2:20 p.m.
Am Samstag, 18. November 2017, 21:55:14 CET schrieb Xavier Mendez:
Ok, a device not knowing exactly its own latency is indeed odd. Thanks for the
explanation!
El 18/11/17 a les 00:50, Markus Grabner ha escrit:
I agree, MIDI
would be nice to have, but the tools would be a useful addition
even without MIDI support. Any opinions of other Jack developers on this?
I vote for adding these tools to the Jack example
clients. What do you
think about this?
It'd be nice if they also supported synchronizing MIDI ports, but that's
TODO for now. For the rest, IMO they're pretty much ready to go. BTW, one
question regarding the "coefficient" parameter: I thought this
should always be "1" (align to maximum latency), but didn't notice any
difference when leaving its default value 0.5 (align to center), both
variants gave correct results. How does this coefficient affect the
behaviour of your client?
The coefficient has no effect when all ports' input
latency has the same
minimum and maximum (i.e. one port [ 337 337 ] and the other [ 867 867
]). That's expected most of the time.
If one port had [ 523 1024 ] latency you'd probably be doing it wrong,
but jack_lsync still has to deal with it, and that's what the parameter
is for. If coefficient was 0, lsync would assume 523 latency when
calculating the delays to apply, if it's 1 it'll assume 1024, and if
it's the default it'll just take the mean of min & max, and assume 773.
So it's only there for those strange cases that should ideally never happen.
PS: If you want to use alsa_out or alsa_in, note this
bug which may make
them report wrong playback/capture latencies in some cases
https://github.com/jackaudio/tools/pull/8
Thanks for the hint, but due to another
self-citation :-) a while ago by Fons
Adriaensen, I ended up using Zita-ajbridge (http://kokkinizita.linuxaudio.org/
linuxaudio/zita-ajbridge-doc/quickguide.html), which works very well for me.
Kind regards,
Markus