On 4/4/19 6:51 PM, Ralf Mardorf wrote: The calculation seems fine to me, but do you get the same latency reported by jack to the clients? This is the issue. Alex.

On 4/4/19 8:41 PM, Thomas Brand wrote: Here it works so this is the output: jack_lsp -l -L system:capture_1 port latency = 2048 frames port playback latency = [ 0 0 ] frames port capture latency = [ 2048 2048 ] frames total latency = 2048 frames system:capture_2 port latency = 2048 frames port playback latency = [ 0 0 ] frames port capture latency = [ 2048 2048 ] frames total latency = 2048 frames system:playback_1 port latency = 24576 frames port playback latency = [ 24576 24576 ] frames port capture latency = [ 0 0 ] frames total latency = 24576 frames system:monitor_1 port latency = 0 frames port playback latency = [ 0 0 ] frames port capture latency = [ 2048 2048 ] frames total latency = 0 frames system:playback_2 port latency = 24576 frames port playback latency = [ 24576 24576 ] frames port capture latency = [ 0 0 ] frames total latency = 24576 frames system:monitor_2 port latency = 0 frames port playback latency = [ 0 0 ] frames port capture latency = [ 2048 2048 ] frames total latency = 0 frames PulseAudio JACK Sink:front-left port latency = 0 frames port playback latency = [ 24576 24576 ] frames port capture latency = [ 0 0 ] frames total latency = 24576 frames PulseAudio JACK Sink:front-right port latency = 0 frames port playback latency = [ 24576 24576 ] frames port capture latency = [ 0 0 ] frames total latency = 24576 frames PulseAudio JACK Source:front-left port latency = 0 frames port playback latency = [ 0 0 ] frames port capture latency = [ 2048 2048 ] frames total latency = 2048 frames PulseAudio JACK Source:front-right port latency = 0 frames port playback latency = [ 0 0 ] frames port capture latency = [ 2048 2048 ] frames total latency = 2048 frames Yes, and in my case I would be directly connected to the system playback and I would have a latency of 24576 frames which seems correct. But this value does not seem to include the hardware latency itself right? I believe that there is a few micro seconds of hardware latency that can be reported by the driver somehow? I think ASIOGetLatencies does that right? Thank you for your answer. Regards, Alexandre

On Fri, April 5, 2019 00:28, Alexandre BIQUE wrote: This page has a nice diagram: http://manual.ardour.org/synchronization/latency-and-latency-compensation/ I don't know how accurate the delay from data leaving jack until it is heard at the analog output can be known. It's around 2.5 ms. But is it the same for every ALSA device and driver? jack_iodelay can measure round-trip latency and you could adjust your system based on jack_iodely output. Greetings Thomas

On Fri, 5 Apr 2019 10:36:02 +0200, Alexandre BIQUE wrote: A lot of people don't care about it. A digital guitar stomp box might allready add additional 5 ms and people often don't notice it. On Linux Ardour suggests to measure the round trip latency and on iOS Auria Pro suggests to do a measurement, too. The gearslutz.com forums discussed this and recommend to measure if "you really need to have sample accurate timing". It's not unusual to connect a cable and to push a button and perhaps to manually add a value to a dialog, if it shouldn't be automated. How should the additional device's latency be reported for e.g. an ADAT device connected to the audio interface, even if all other latency would be reported?

On Fri, Apr 05, 2019 at 10:36:02AM +0200, Alexandre BIQUE wrote: The driver has no way of knowing the latency of the ADC and DAC circuitry. That has to be measured. (As an example, think of a PCI(e) MADI or ADAT card which can be used with a variety of different external DACs or ADCs). John

On 4/5/19 11:27 AM, Alexandre BIQUE wrote: No, it should propagate latencies. But in this simple case it's not relevant at all. A better example is [HW Input] -> [App1] -> [App2] -> [HW Output] Each App is interested in two things: - how long has it been since the data read from a port arrived at the edge of the graph (capture, from hw-input) - how long will it be until the data written to a given port will arrive at the edge of the graph (playback, to hw-output) App1 should read the HW input *capture*-latency from its input port, add its own latency and inform App2 about the sum by setting the capture latency of App1's output port. Likewise, App2 should add its latency to the *playback* latency of its output port and forward that to App1 by setting the playback latency of App2's input port. Please see http://jackaudio.org/api/group__LatencyFunctions.html#ga7a8f181fcec32945db7… That outlines above algorithm One example use-case is Overdubs: e.g. App1 plays back, App2 adds some latent effect (e.g. a Limiter). A musician listens to HW output, sings along into the HW-input and App1 records it. The recording should be in sync with the playack. Yes, the port latencies, which may or may not be related to hardware. -=- As for absolute alignment, that's jack-transport or jack-time, which provides a clock based on the soundcard's oscillator. -- unrelated to the operating-system's time. http://jackaudio.org/api/group__TimeFunctions.html Hope that helps, robin

On 4/5/19 1:13 PM, Robin Gareus wrote: What about this one: [HW Input] -> [App1] -> [App2] -> [HW Output] `-----------^ How is App2 supposed to work out its input latency?

On 4/5/19 6:15 PM, Robin Gareus wrote: Yeah that's my issue, the latency problem can't be solved. Maybe jack would be clearer without the port's latency and a simple way to query the audio driver latency. Thanks, Alex

On 4/6/19 1:13 AM, Robin Gareus wrote: You explained it well, jack is a patch bay and does not intent to solve the latency compensation, it is not its purpose right? jack allows situations where the latency compensation can't be solved, and it will sum different inputs with different latencies, so you can't do anything about it as a client. That being said I'm not complaining about jack working that way. It is a patch bay and it is fine. I'm complaining about port's having latency, which would let anyone reading the API think that they should and could implement latency compensation, while in the end I can't see a way to implement it as a jack client. So a jack client can't make the promise to the user that it will compensate the latency. Which led me to the conclusion "less is more": strip down the latency from the ports, make it clear that you can't write a jack client which does correct latency compensation. Then let the client query the audio interface latency and job done. It is simple to understand and easy to implement as a client. It will work well for clients that uses jack as an audio interface: HW In -> App -> HW Out. To sum up in one sentence, in my opinion it is better to not have latency compensation than having it working half of the time. Regards, Alexandre

On 4/6/19 2:30 PM, Robin Gareus wrote: So I did not understand how to cope with the latency range. Please could explain it to me (again?)? I would be really interested to read the fix of Ableton Link's LinkHut with jack backend regarding latency compensation. Thank you, Alex

On Sat, Apr 06, 2019 at 01:13:58AM +0200, Robin Gareus wrote: It's not really that far-fetched. I have this sort of situations all the time. Assuming the two inputs to App2 are mixed on a single Jack port, that port will show different values for min and max latency. Now is this a problem ? That depends on the actual use case. In many cases it doesn't. To the OP: *If* the different latencies matter, there are two solutions. 1. Insert a delay in the HW -> App2 connection. 2. Use separate inputs on App2, each will report its latency and App2 can compensate for the difference. Note that 2. would be entirely automatic if App2 is designed to do this. That is why Jack's latency reporting works the way it does. -- FA