On Mon, Apr 16, 2012 at 5:21 PM, S. Massy <lists(a)wolfdream.ca> wrote: you're using an old version of JACK. the output of jack_lsp -l is a *range* of values for each port: audacious-jack_32120_101:out_0 port latency = 0 frames port playback latency = [ 1024 1024 ] frames port capture latency = [ 0 0 ] frames its neither. you must read the docs and understand them to understand what is it telling you. the basic idea is to provide a way to be able to answer one or both of the two questions: * how long has it been since the data i'm handling in a process() callback arrived at the edge of the JACK graph? * how long will it be until the data i'm handing in a process callback() will arrive at the edge of the JACK graph?

On Tue, Apr 17, 2012 at 05:09:52PM +0000, Fons Adriaensen wrote: Thanks for clarifying this. I understand that the round trip delay for the soundcard is the sum of capture port latency and playback port latency, plus whatever additional delay is associated with the AD/DA converters. However I see what appears to be a discrepency for the latencies reported by jackd (2 + 2 periods roundtrip) and by jack_lsp -l (1 + 2 periods round trip). This is for jackd2. jackd says: configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback However, jack_lsp -l says: system:capture_1 port latency = 1024 frames port playback latency = [ 0 0 ] frames port capture latency = [ 1024 1024 ] frames system:capture_2 port latency = 1024 frames port playback latency = [ 0 0 ] frames port capture latency = [ 1024 1024 ] frames system:playback_1 port latency = 2048 frames port playback latency = [ 2048 2048 ] frames port capture latency = [ 0 0 ] frames system:playback_2 port latency = 2048 frames port playback latency = [ 2048 2048 ] frames port capture latency = [ 0 0 ] frames Is this inconistent, or is there some other explanation? Great to have these details available for unschooled developers as myself! Regards, Joel -- Joel Roth

On Tue, Apr 17, 2012 at 05:09:52PM +0000, Fons Adriaensen wrote: If this is correct, Patrick Shirkey should update his page at http://linux-audio.com/jack/ Quote: p affects input latency: how long from when a piece of data arrives at the audio interface connectors until user space software can use it? p*n affects output latency: how long from when a piece of data is delivered by user space data until it leaves the audio interface connectors? Roundtrip latency is combination of these two. -- Joel Roth

On Thu, May 03, 2012 at 10:15:18AM +0000, Fons Adriaensen wrote: Thanks, Fons.. This simple diagram finally pounded the order of things into my head, I hope. Cheers, S.M.

On Mon, Apr 16, 2012 at 04:54:45PM -0400, Paul Davis wrote: Hi, I could use some help with a real example. Example 1. system to ecasound Say I ask Ecasound to route one channel of audio from the sound card input to the null device. ecasound -f:,1 -i:jack,system -o:null How much is the signal delayed on the way from the soundcard into Ecasound's signal-processing engine, as reported by jack_port_get_latency_range() ? The connection (reported by jack_lsp -c) is system:capture_1 to ecasound:in_1 Here is the relevant output of jack_lsp -l: system:capture_1 port latency = 1024 frames port playback latency = [ 0 0 ] frames port capture latency = [ 1024 1024 ] frames ecasound:in_1 port latency = 0 frames port playback latency = [ 0 0 ] frames port capture latency = [ 1024 1024 ] frames Without looking at the source, I can hazard a guess that the "port latency" line may be the output of a deprecated function, perhaps jack_port_get_latency(). So let's remove that for clarity: system:capture_1 port playback latency = [ 0 0 ] frames port capture latency = [ 1024 1024 ] frames ecasound:in_1 port playback latency = [ 0 0 ] frames port capture latency = [ 1024 1024 ] frames Now which of these four ranges contributes to the latency? Reading the docs, my naive guess is that only two ranges play a part, probably the capture latency of the first and the playback latency of the second, for the total of 1024 frames. I'm curious if the other two ranges have any meaning at all, given that ports appear to have only one direction. Well that's the extent of my questions for tonight. TIA, Joel -- Joel Roth