[Jack-Devel] I'm confused about latency
Locked
12
12
[Jack-Devel] I'm confused about latency
 
|
Hi,
I've been reading the code of Ableon's LinkHut's jack backend. https://github.com/Ableton/link/blob/master/examples/linkaudio/AudioPlatform_Jack.hpp https://github.com/Ableton/link/blob/master/examples/linkaudio/AudioPlatform_Jack.cpp And I was quite surprised because I did not find any latency compensation there. So for real-time beat time synchronization this is quite important right? BTW, if any jack expert finds the time and motivation to fix the jack back-end of Link's example that would be awesome and a great example. Then I've read the documentation: http://jackaudio.org/api/group__LatencyFunctions.html And I am totally confused. Why a latency range? What is the use case for it? How is the application supposed to work with multiple inputs and outputs having each a different latency range? What's the point of a latency range? If you're concerned about the shortest path and the longest path, why wouldn't you be concerned about any path in between? How to know at which time on a given a clock (CLOCK_REALTIME or CLOCK_MONOTONIC) a sample in the current process block will be played on the sound card's output? I've tried with qjackctl to set the periods/buffer to 12 with 2048 samples per buffer at 44100 Hz which is about half a second of latency. Do you manage to get the correct latency reported with those settings? See https://imgur.com/w45wsp8 Jack allows feedback routing, how do you deal with latency with such a graph? I've been testing with Jack 1.9.12-8 on Archlinux and QJackCtl 0.5.6-1 Many thanks for your answer and your time, Alexandre Bique _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote:
> I've tried with qjackctl to set the periods/buffer to 12 with 2048 > samples per buffer at 44100 Hz which is about half a second of > latency. Do you manage to get the correct latency reported with those > settings? See https://imgur.com/w45wsp8 Hi, what's wrong with QjackCtl's calculation? For the calculation I found a page that seemingly contains a typo. "(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" - https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface It should read "s" not "ms". (2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms Regards, Ralf _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
On 4/4/19 6:51 PM, Ralf Mardorf wrote:
> On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote: >> I've tried with qjackctl to set the periods/buffer to 12 with 2048 >> samples per buffer at 44100 Hz which is about half a second of >> latency. Do you manage to get the correct latency reported with those >> settings? See https://imgur.com/w45wsp8 > > Hi, > > what's wrong with QjackCtl's calculation? > > For the calculation I found a page that seemingly contains a typo. > > "(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" - > https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface > > It should read "s" not "ms". > > (2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms The calculation seems fine to me, but do you get the same latency reported by jack to the clients? This is the issue. Alex. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On Thu, April 4, 2019 20:23, Alexandre BIQUE wrote:
> On 4/4/19 6:51 PM, Ralf Mardorf wrote: > >> On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote: >> >>> I've tried with qjackctl to set the periods/buffer to 12 with 2048 >>> samples per buffer at 44100 Hz which is about half a second of latency. >>> Do you manage to get the correct latency reported with those >>> settings? See https://imgur.com/w45wsp8 >> >> Hi, >> >> >> what's wrong with QjackCtl's calculation? >> >> For the calculation I found a page that seemingly contains a typo. >> >> >> "(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" - >> https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_idea >> l_for_usb_interface >> >> It should read "s" not "ms". >> >> >> (2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms >> > > The calculation seems fine to me, but do you get the same latency > reported by jack to the clients? This is the issue. > I just tried with the same setting to start jackd, and it only works for n<=2<=4. Anything above 4 will not start server ("ALSA: got smaller periods 4 than 5 for capture"). However changing n is reflected on ports: jack_lsp -l -L system:capture_1 port playback latency = [ 0 0 ] frames port capture latency = [ 2048 2048 ] frames total latency = 2048 frames ... system:playback_1 port playback latency = [ 4096 4096 ] frames port capture latency = [ 0 0 ] frames total latency = 4096 frames .. I think latency in a graph is confusing per se. The points you made for "shortest path" etc. make sense to me. I'm not sure if the semantics of latency for ports and latency ranges are well enough documented. It can get very complicated considering a graph with many ports each of which can have another latency and a mixture of different latencies depending on routing etc. I want to say you're not the only one confused here. On the search of example clients or clients that make use of the latency features inside jack, I didn't find anything quickly. I speculate that this API isn't used much and could probably be a candidate to remove. It's not unlike the session API that's sitting there but isn't used (much). Did I understand your use case correctly: you want to be able to tell (from a client's perspective) how long it will take from *now* (this cycle) until the start of the buffer is played out (eg. the first sample of buffer hits the DAC) ~ ?? Greetings Thomas _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
On 4/4/19 8:41 PM, Thomas Brand wrote:
> On Thu, April 4, 2019 20:23, Alexandre BIQUE wrote: >> On 4/4/19 6:51 PM, Ralf Mardorf wrote: >> >>> On Thu, 2019-04-04 at 18:19 +0200, Alexandre Bique wrote: >>> >>>> I've tried with qjackctl to set the periods/buffer to 12 with 2048 >>>> samples per buffer at 44100 Hz which is about half a second of latency. >>>> Do you manage to get the correct latency reported with those >>>> settings? See https://imgur.com/w45wsp8 >>> >>> Hi, >>> >>> >>> what's wrong with QjackCtl's calculation? >>> >>> For the calculation I found a page that seemingly contains a typo. >>> >>> >>> "(Frames [or buffer] / Sample Rate ) * Periods = Latency in ms" - >>> https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_idea >>> l_for_usb_interface >>> >>> It should read "s" not "ms". >>> >>> >>> (2048 frames / 44100 Hz sample rate) * 12 periods = 0.557 s IOW 557 ms >>> >> >> The calculation seems fine to me, but do you get the same latency >> reported by jack to the clients? This is the issue. >> > > I just tried with the same setting to start jackd, and it only works for > n<=2<=4. Anything above 4 will not start server ("ALSA: got smaller > periods 4 than 5 for capture"). However changing n is reflected on ports: > jack_lsp -l -L > > system:capture_1 > port playback latency = [ 0 0 ] frames > port capture latency = [ 2048 2048 ] frames > total latency = 2048 frames > ... > system:playback_1 > port playback latency = [ 4096 4096 ] frames > port capture latency = [ 0 0 ] frames > total latency = 4096 frames > .. 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 > I think latency in a graph is confusing per se. The points you made for > "shortest path" etc. make sense to me. I'm not sure if the semantics of > latency for ports and latency ranges are well enough documented. It can > get very complicated considering a graph with many ports each of which can > have another latency and a mixture of different latencies depending on > routing etc. I want to say you're not the only one confused here. > > On the search of example clients or clients that make use of the latency > features inside jack, I didn't find anything quickly. I speculate that > this API isn't used much and could probably be a candidate to remove. It's > not unlike the session API that's sitting there but isn't used (much). > > Did I understand your use case correctly: you want to be able to tell > (from a client's perspective) how long it will take from *now* (this > cycle) until the start of the buffer is played out (eg. the first sample > of buffer hits the DAC) ~ ?? 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 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
In reply to this post by Thomas Brand
On 4/4/19 8:41 PM, Thomas Brand wrote:
> Did I understand your use case correctly: you want to be able to tell > (from a client's perspective) how long it will take from *now* (this > cycle) until the start of the buffer is played out (eg. the first sample > of buffer hits the DAC) ~ ?? Yes, something equivalent to snd_pcm_htimestamp(). _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On Fri, April 5, 2019 00:28, Alexandre BIQUE wrote:
> On 4/4/19 8:41 PM, Thomas Brand wrote: > >> Did I understand your use case correctly: you want to be able to tell >> (from a client's perspective) how long it will take from *now* (this >> cycle) until the start of the buffer is played out (eg. the first sample >> of buffer hits the DAC) ~ ?? > > Yes, something equivalent to snd_pcm_htimestamp(). > > 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 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
On 4/5/19 2:56 AM, Thomas Brand wrote:
> On Fri, April 5, 2019 00:28, Alexandre BIQUE wrote: >> On 4/4/19 8:41 PM, Thomas Brand wrote: >> >>> Did I understand your use case correctly: you want to be able to tell >>> (from a client's perspective) how long it will take from *now* (this >>> cycle) until the start of the buffer is played out (eg. the first sample >>> of buffer hits the DAC) ~ ?? >> >> Yes, something equivalent to snd_pcm_htimestamp(). >> >> > 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. 2.5 ms is quite a lot, and should be somehow reported by device API (ALSA, ASIO, CoreAudio, ...): - the driver should have a rough idea of how much hardware latency is introduced by the audio interface - the OS should have a rough idea of how much scheduling/internals latency is introduced Even if those values are not correct if they can reduce the "error" it is worth it right? I'm skeptical that people want to put a feedback cable into their audio interface and measure exactly how much latency is introduced, and then configure their tools with some mystic latency compensation. I really think that if we can get some values from the OS which minimize the error that would be better. Cheers, Alexandre _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
In reply to this post by Thomas Brand
On 4/4/19 8:41 PM, Thomas Brand wrote:
> I just tried with the same setting to start jackd, and it only works for > n<=2<=4. Anything above 4 will not start server ("ALSA: got smaller > periods 4 than 5 for capture"). However changing n is reflected on ports: > jack_lsp -l -L > > system:capture_1 > port playback latency = [ 0 0 ] frames > port capture latency = [ 2048 2048 ] frames > total latency = 2048 frames > ... > system:playback_1 > port playback latency = [ 4096 4096 ] frames > port capture latency = [ 0 0 ] frames > total latency = 4096 frames > .. > > I think latency in a graph is confusing per se. The points you made for > "shortest path" etc. make sense to me. I'm not sure if the semantics of > latency for ports and latency ranges are well enough documented. It can > get very complicated considering a graph with many ports each of which can > have another latency and a mixture of different latencies depending on > routing etc. I want to say you're not the only one confused here. > > On the search of example clients or clients that make use of the latency > features inside jack, I didn't find anything quickly. I speculate that > this API isn't used much and could probably be a candidate to remove. It's > not unlike the session API that's sitting there but isn't used (much). > > Did I understand your use case correctly: you want to be able to tell > (from a client's perspective) how long it will take from *now* (this > cycle) until the start of the buffer is played out (eg. the first sample > of buffer hits the DAC) ~ ?? To get back to the port's latency configuration here a simple case: [HW Input] -> [App] -> [HW Output] Should the App set its input and output port latency to 0? Or should the App set its port latency as follow: app.in.latency = hw_in.out.latency; app.out.latency = app.in.latency + app.internal_latency; Or something else? And internally the application would use the hw input latency and hw output latency. Is that all correct? Are my questions clear? Thank you very much! Alex. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Alexandre Bique
On Fri, 5 Apr 2019 10:36:02 +0200, Alexandre BIQUE wrote:
>2.5 ms is quite a lot 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. >I'm skeptical that people want to put a feedback cable into their audio >interface and measure exactly how much latency is introduced, and then >configure their tools with some mystic latency compensation. I really >think that if we can get some values from the OS which minimize the >error that would be better. 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? _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
On 4/5/19 11:48 AM, Ralf Mardorf wrote:
> On Fri, 5 Apr 2019 10:36:02 +0200, Alexandre BIQUE wrote: >> 2.5 ms is quite a lot > > 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. The use case are Ableton link and midi clock, of course it won't be perfect but any best effort we can do to make it more accurate is welcomed. >> I'm skeptical that people want to put a feedback cable into their audio >> interface and measure exactly how much latency is introduced, and then >> configure their tools with some mystic latency compensation. I really >> think that if we can get some values from the OS which minimize the >> error that would be better. > > 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? Yes I also think that if one can achieve this in a user friendly way it can be interesting. Thank you, Alex. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Alexandre Bique
On 4/5/19 11:27 AM, Alexandre BIQUE wrote:
> To get back to the port's latency configuration here a simple case: > > [HW Input] -> [App] -> [HW Output] > > Should the App set its input and output port latency to 0? 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#ga7a8f181fcec32945db7b8e06ee1ca94b 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. > And internally the application would use the hw input latency and hw > output latency. 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 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
On 4/5/19 1:13 PM, Robin Gareus wrote:
> 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. Which API is jack using to access the soundcard's clock? Thank your for your answer, yes that helps. Alex. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
In reply to this post by Robin Gareus
On 4/5/19 1:13 PM, Robin Gareus wrote:
> A better example is > > [HW Input] -> [App1] -> [App2] -> [HW Output] What about this one: [HW Input] -> [App1] -> [App2] -> [HW Output] `-----------^ How is App2 supposed to work out its input latency? _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On 4/5/19 2:35 PM, Alexandre BIQUE wrote:
> On 4/5/19 1:13 PM, Robin Gareus wrote: >> A better example is >> >> [HW Input] -> [App1] -> [App2] -> [HW Output] > > What about this one: > > [HW Input] -> [App1] -> [App2] -> [HW Output] > `-----------^ > > How is App2 supposed to work out its input latency? > It just looks up the value(s) from its input port(s): jack_port_get_latency_range(port, JackCaptureLatency, &latency_range); If you meant that App1 is latent, and App2's input-port is connected to the sum of App1's output and the HW's capture port. Then the latency is ambiguous (jack reports a range). If App1 doesn't introduce a latency. App2 will see a single value for the capture-latency on its input port. jack does not include a "delay in the wire" to align paths. JACK is a patchbay. It provides mechanism for efficient inter-application connections, jackd itself does not enforce a policy on the user. Cheers! robin _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
On 4/5/19 6:15 PM, Robin Gareus wrote:
> If you meant that App1 is latent, and App2's input-port is connected to > the sum of App1's output and the HW's capture port. Then the latency is > ambiguous (jack reports a range). > > If App1 doesn't introduce a latency. App2 will see a single value for > the capture-latency on its input port. > > jack does not include a "delay in the wire" to align paths. JACK is a > patchbay. It provides mechanism for efficient inter-application > connections, jackd itself does not enforce a policy on the user. 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 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On 4/5/19 10:32 PM, Alexandre BIQUE wrote:
> On 4/5/19 6:15 PM, Robin Gareus wrote: >> If you meant that App1 is latent, and App2's input-port is connected to >> the sum of App1's output and the HW's capture port. Then the latency is >> ambiguous (jack reports a range). >> >> If App1 doesn't introduce a latency. App2 will see a single value for >> the capture-latency on its input port. >> >> jack does not include a "delay in the wire" to align paths. JACK is a >> patchbay. It provides mechanism for efficient inter-application >> connections, jackd itself does not enforce a policy on the user. > > Yeah that's my issue, the latency problem can't be solved. Why is this a problem? If you want to shoot yourself in the foot you can do the exact same with an analog patchbay. Comb filter galore! :) The jack UI front-end can try to educate a user why some routing situations may not make sense. It may also suggest to the user to add a no-op, delayline to compensate for the ambiguity -- but JACK itself doesn't care. > Maybe jack would be clearer without the port's latency and a simple way > to query the audio driver latency. Why and how would that help? Would you mind elaborating why you think that querying an application's *port* capture and playback latencies is not the correct solution in an anywhere to anywhere routing system? In some cases there may not be any hardware involved at all, and in the vast majority of cases port latencies are not ambiguous. The case of a direct parallel bypass around a latent App1 like HW Input] -> [App1] -> [App2] -> [HW Output] `-----------^ is really a constructed situation. JACK is not a modular synth, but a patchbay. 2c, robin _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
On 4/6/19 1:13 AM, Robin Gareus wrote:
> On 4/5/19 10:32 PM, Alexandre BIQUE wrote: >> On 4/5/19 6:15 PM, Robin Gareus wrote: >>> If you meant that App1 is latent, and App2's input-port is connected to >>> the sum of App1's output and the HW's capture port. Then the latency is >>> ambiguous (jack reports a range). >>> >>> If App1 doesn't introduce a latency. App2 will see a single value for >>> the capture-latency on its input port. >>> >>> jack does not include a "delay in the wire" to align paths. JACK is a >>> patchbay. It provides mechanism for efficient inter-application >>> connections, jackd itself does not enforce a policy on the user. >> >> Yeah that's my issue, the latency problem can't be solved. > > Why is this a problem? If you want to shoot yourself in the foot you can > do the exact same with an analog patchbay. Comb filter galore! :) > > The jack UI front-end can try to educate a user why some routing > situations may not make sense. It may also suggest to the user to add a > no-op, delayline to compensate for the ambiguity -- but JACK itself > doesn't care. > >> Maybe jack would be clearer without the port's latency and a simple way >> to query the audio driver latency. > > Why and how would that help? > > Would you mind elaborating why you think that querying an application's > *port* capture and playback latencies is not the correct solution in an > anywhere to anywhere routing system? > > In some cases there may not be any hardware involved at all, and in the > vast majority of cases port latencies are not ambiguous. > > > The case of a direct parallel bypass around a latent App1 like > HW Input] -> [App1] -> [App2] -> [HW Output] > `-----------^ > is really a constructed situation. JACK is not a modular synth, but a > patchbay. 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 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: I'm confused about latency
|
|
In reply to this post by Robin Gareus
On Sat, Apr 06, 2019 at 01:13:58AM +0200, Robin Gareus wrote:
> The case of a direct parallel bypass around a latent App1 like > HW Input] -> [App1] -> [App2] -> [HW Output] > `-----------^ > is really a constructed situation. JACK is not a modular synth, but a > patchbay. 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 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Alexandre Bique
On 4/6/19 7:07 AM, Alexandre BIQUE wrote:
> 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. That would be counter-productive. You statement is also not correct. jack clients can correctly compensate for latency, and also do that in situations when no audio hardware is involved. The fact that not all jack clients do this is not reason to constrain others. > Then let the client query the audio interface latency and job done. Only MacOS/X offers an interface to query systemic latency from hardware interfaces. > It will work well for clients that uses jack as an audio interface: If you don't need to do inter-application routing, I would highly recommend against using JACK only to abstract a single audio interface. > 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. A user asking for ambiguous latency situations is not an design issue with JACK. The 'range' was specifically added to account for this and allow jack-clients to cope with it. 2c, robin _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
«
Return to Jackit
|
1 view|%1 views
| Free forum by Nabble | Edit this page |