On Mon, Apr 16, 2012 at 04:54:45PM -0400, Paul Davis wrote: > On Mon, Apr 16, 2012 at 3:31 PM, S. Massy <lists@xxxxxxxxxxxx> wrote: > > Hello, > > > > Here is the use-case. Sending audio from one application to be processed > > by another jack client before being sent back, the processed signal > > being mixed back in, possibly with a copy of itself. How would one go > > about estimating by how much the processed signal was delayed? > > you don't have to estimate it. JACK will tell you. > > > 1) JACK base latency: > > My understanding is that JACK will always introduce a latency of > > buffer_size*period_size*nperiods, is that correct? > > no, just period_size * nperiods. Okay, so for a standard 2 periods of 128 frames each, my nominal dddelay is 256 frames or 5.3ms at a sr of 48k, twice that for a round-trip. > > > > If the signal is > > sent, processed, then sent back, the acquired delay would at least be > > twice the nominal jack latency, right? > > yep. > > > - Problem: On the practical side, how could we calculate the base > > latency using available jack utilities? There's jack_bufsize and > > jack_samplerate, but no way to find the number of periods, I think. > > you don't. you use the part of the API that is specifically designed > for this. read the docs for jack_port_get_latency_range() I did, but clearly, I'm missing something. When using "jack_lsp -l" to get latency, I get: 384 frames for system:playback_*, which is right for my set-up, 128 frames for system:capture_*, and 0 frames for jconvolver, which can't be rright. Shouldn't the least it can be 384 frames (-p128 -n3)? > > > > 2) Latency of the processing client. > > That would depend largely on the client, I guess. The README.CONFIG for > > jconvolver states that setting the partition number to be equal to the > > jack period size would result in zero latency, for example... > > it does depend on the client. a well behaved client will use > jack_port_set_latency_range() to let the rest of the world know what > is going on. Is that value an absolute or relative to the nominal latency? Cheers, S.M. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
