Re: [LAD] JACK latency API clarifications
On Fri, Feb 21, 2014 at 08:34:16PM +0100, Jörn Nettingsmeier wrote: > On 02/21/2014 07:52 PM, Lieven Moors wrote: > >>it was part of the API very early on, then we decided we didn't want to > >>impose the possibility of change on clients. as time goes on, it becomes > >>clear (to me at least) that we should have implemented it. > > > >What would be use cases for changing the sample rate dynamically? > > > having wired up a complex signal graph, which for the most part depends on > the studio, not on the project at hand, and then having to deal with > different projects in different sample rates. > > say your studio involves three monitoring setups, one main stereo, one > nearfield, and one surround, you are using jack to do EQ on those things, in > my case there's an ambisonic decoder in the loop as well. that means the > jack graph is already quite elaborated. in that case, it would be nice to > leave it running while switching from, say, a cd project at 44k1 to a tv > thing at 48k. > > as it is now, i have decided to do _everything_ at 48k (i have no second > thoughts about a final resampling step), but if a client brings material at, > say, 96k, i have to downsample first. sometimes i wish for an easy way to > reclock a graph. obviously, nobody expects this to be gapless. fading > everthing down and then taking a few seconds to reclock everything would be > fine. > > but then, many pieces of software in my chain would need changes. for > instance, an important piece of dsp for me is jconvolver, as it sits in > front of all my speakers. > of course, the impulse responses i use for EQ and room correction only make > sense for a given sample rate - it would have to be changed to swap one set > of IRs for another during a reclocking call, and of course that needs to be > configured and the user actually needs to provide those different IRs. > Yes, I see... I got into the habbit of using the same sample rate for all my projects as well. And I can remember a few times I wished to change the sample rate on the fly. Now I wonder if this would be difficult to implement. Do many clients expect the sample rate to remain stable? Aren't most clients checking for the sample rate in the process callback anyway? Of course, clients depending on samples or IR's would have to play back at the wrong rate... lieven ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
On Fri, Feb 21, 2014 at 08:34:16PM +0100, Jörn Nettingsmeier wrote: > having wired up a complex signal graph, which for the most part > depends on the studio, not on the project at hand, and then having > to deal with different projects in different sample rates. > ... > as it is now, i have decided to do _everything_ at 48k (i have no > second thoughts about a final resampling step), but if a client > brings material at, say, 96k, i have to downsample first. sometimes > i wish for an easy way to reclock a graph. obviously, nobody expects > this to be gapless. fading everthing down and then taking a few > seconds to reclock everything would be fine. OTOH, if the 'studio' setup is not trivial and being used every day, then you probably have a script or something else to set it up, and having to resstart from 'cold and dark' is not a big deal. One very practical reason for running the studio at a fixed sample rate is having ADAT interfaces for example, which reduce to four channels at 96 kHz. One way to do that is using a 'resampling' Jack backend which is itself a Jack client. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
On 02/21/2014 07:52 PM, Lieven Moors wrote: it was part of the API very early on, then we decided we didn't want to impose the possibility of change on clients. as time goes on, it becomes clear (to me at least) that we should have implemented it. What would be use cases for changing the sample rate dynamically? having wired up a complex signal graph, which for the most part depends on the studio, not on the project at hand, and then having to deal with different projects in different sample rates. say your studio involves three monitoring setups, one main stereo, one nearfield, and one surround, you are using jack to do EQ on those things, in my case there's an ambisonic decoder in the loop as well. that means the jack graph is already quite elaborated. in that case, it would be nice to leave it running while switching from, say, a cd project at 44k1 to a tv thing at 48k. as it is now, i have decided to do _everything_ at 48k (i have no second thoughts about a final resampling step), but if a client brings material at, say, 96k, i have to downsample first. sometimes i wish for an easy way to reclock a graph. obviously, nobody expects this to be gapless. fading everthing down and then taking a few seconds to reclock everything would be fine. but then, many pieces of software in my chain would need changes. for instance, an important piece of dsp for me is jconvolver, as it sits in front of all my speakers. of course, the impulse responses i use for EQ and room correction only make sense for a given sample rate - it would have to be changed to swap one set of IRs for another during a reclocking call, and of course that needs to be configured and the user actually needs to provide those different IRs. -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
> it was part of the API very early on, then we decided we didn't want to > impose the possibility of change on clients. as time goes on, it becomes > clear (to me at least) that we should have implemented it. What would be use cases for changing the sample rate dynamically? lieven ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
2014-02-21 17:21 GMT+02:00 Paul Davis : > > > > On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo > wrote: >> >> >> >> Well, here >> http://jackaudio.org/files/docs/html/group__ClientCallbacks.html >> I only see that process has to be RT-safe and thread-init needs not, >> but regarding others I have no clue. Is that stated somewhere else or >> am I missing something? > > > if it doesn't say it has to be RT-safe, it doesn't have to be. That ought to > be obbvious also from the note on Jack2's design. >> >> >> > The threading design described above is specific to Jack2. Jack1 >> > delivers >> > all callbacks to the same thread (which necessarily means that >> > processing >> > audio is blocked by other callbacks). This is one of the major (and >> > largely >> > hidden) design differences between Jack1 and Jack2. >> >> What truly interests me is whether non-process callbacks can block. It >> seems that's not the case with Jack1 then? > > > Jack1 acccepts that other callbacks can block, and that doing so will > interrupt audio. > > I wonder what the jack_set_sample_rate_callback() is for then, but at >> >> this point I don't care. > > > it was part of the API very early on, then we decided we didn't want to > impose the possibility of change on clients. as time goes on, it becomes > clear (to me at least) that we should have implemented it. Ok, thanks a lot again. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo wrote: > > > Well, here > http://jackaudio.org/files/docs/html/group__ClientCallbacks.html > I only see that process has to be RT-safe and thread-init needs not, > but regarding others I have no clue. Is that stated somewhere else or > am I missing something? > if it doesn't say it has to be RT-safe, it doesn't have to be. That ought to be obbvious also from the note on Jack2's design. > > > The threading design described above is specific to Jack2. Jack1 delivers > > all callbacks to the same thread (which necessarily means that processing > > audio is blocked by other callbacks). This is one of the major (and > largely > > hidden) design differences between Jack1 and Jack2. > > What truly interests me is whether non-process callbacks can block. It > seems that's not the case with Jack1 then? > Jack1 acccepts that other callbacks can block, and that doing so will interrupt audio. I wonder what the jack_set_sample_rate_callback() is for then, but at > this point I don't care. > it was part of the API very early on, then we decided we didn't want to impose the possibility of change on clients. as time goes on, it becomes clear (to me at least) that we should have implemented it. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
2014-02-21 16:51 GMT+02:00 Paul Davis : > > > > On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo > wrote: >> >> Sorry guys, other two (silly?) questions: >> >> 1. apart from the process callback, which callbacks need to be >> RT-safe? Looking around I found a master thesis [1] that says: "Apart >> from >> the JackProcessCallback callback, which is called in the realtime >> audio thread for obvious reasons, all other callbacks are called >> asynchronously in a specialized non-realtime thread, to avoid >> notifications to interfere with audio processing", is that true? > > > The documentation does actually state which ones need to be RT, but there is > no list to easily consult. Well, here http://jackaudio.org/files/docs/html/group__ClientCallbacks.html I only see that process has to be RT-safe and thread-init needs not, but regarding others I have no clue. Is that stated somewhere else or am I missing something? > The threading design described above is specific to Jack2. Jack1 delivers > all callbacks to the same thread (which necessarily means that processing > audio is blocked by other callbacks). This is one of the major (and largely > hidden) design differences between Jack1 and Jack2. What truly interests me is whether non-process callbacks can block. It seems that's not the case with Jack1 then? >> 2. may the system sample rate actually change (while a client is running)? > > > JACK to date has never supported changing the sample rate. I wonder what the jack_set_sample_rate_callback() is for then, but at this point I don't care. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo wrote: > Sorry guys, other two (silly?) questions: > > 1. apart from the process callback, which callbacks need to be > RT-safe? Looking around I found a master thesis [1] that says: "Apart > from > the JackProcessCallback callback, which is called in the realtime > audio thread for obvious reasons, all other callbacks are called > asynchronously in a specialized non-realtime thread, to avoid > notifications to interfere with audio processing", is that true? > The documentation does actually state which ones need to be RT, but there is no list to easily consult. The threading design described above is specific to Jack2. Jack1 delivers all callbacks to the same thread (which necessarily means that processing audio is blocked by other callbacks). This is one of the major (and largely hidden) design differences between Jack1 and Jack2. > 2. may the system sample rate actually change (while a client is running)? > JACK to date has never supported changing the sample rate. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
Sorry guys, other two (silly?) questions: 1. apart from the process callback, which callbacks need to be RT-safe? Looking around I found a master thesis [1] that says: "Apart from the JackProcessCallback callback, which is called in the realtime audio thread for obvious reasons, all other callbacks are called asynchronously in a specialized non-realtime thread, to avoid notifications to interfere with audio processing", is that true? 2. may the system sample rate actually change (while a client is running)? [1] http://retis.sssup.it/sites/default/files/realtime_low_latency_audio_on_linux.pdf 2014-02-21 1:08 GMT+02:00 Stefano D'Angelo : > 2014-02-21 1:08 GMT+02:00 Paul Davis : >> >> >> >> On Thu, Feb 20, 2014 at 6:05 PM, Stefano D'Angelo >> wrote: >>> >>> > reset your port latencies. >>> >>> Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be >>> called from within the process callback too? >> >> >> you cannot contact the server from with the process callback, so no. >> >> and yes, it is NOT documented which JACK API calls do this. > > Ok, thanks a lot. > > Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
2014-02-21 1:08 GMT+02:00 Paul Davis : > > > > On Thu, Feb 20, 2014 at 6:05 PM, Stefano D'Angelo > wrote: >> >> > reset your port latencies. >> >> Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be >> called from within the process callback too? > > > you cannot contact the server from with the process callback, so no. > > and yes, it is NOT documented which JACK API calls do this. Ok, thanks a lot. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
On Thu, Feb 20, 2014 at 6:05 PM, Stefano D'Angelo wrote: > > reset your port latencies. > > Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be > called from within the process callback too? > you cannot contact the server from with the process callback, so no. and yes, it is NOT documented which JACK API calls do this. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
2014-02-21 0:45 GMT+02:00 Paul Davis : > > > > On Thu, Feb 20, 2014 at 5:32 PM, Stefano D'Angelo > wrote: >> >> Hi all, >> >> Let's say I have a client that introduces an amount of latency that's >> variable at runtime and potentially unbounded. From JACK's docs it >> seems that you need to recompute the min/max latencies in the latency >> callback that's called "by the server" whenever it feels like, but you >> can force that by calling jack_recompute_total_latencies (right?). >> >> The problem is, you are advised to call this last function only after >> calling jack_port_set_latency_range(), which you should only call in >> the latency callback, which may be called next month... am I dumb >> (probably) or is there a deadly loop? > > > the latency callback will be issued (twice, once for upstream, once for > downstream) after one of two things happens: > >* the graph changes >* a client calls jack_recompute_total_latencies() > > you would call the latter if something happens that alters your clients own > latency (e.g the change to some parameter of an algorithm that causes your > client to change its latency). then you wait for the latency callback and > reset your port latencies. Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be called from within the process callback too? Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
On 02/20/2014 11:32 PM, Stefano D'Angelo wrote: Hi Stefano, You got this right. > Hi all, > > Let's say I have a client that introduces an amount of latency that's > variable at runtime and potentially unbounded. From JACK's docs it > seems that you need to recompute the min/max latencies in the latency > callback that's called "by the server" whenever it feels like, but you > can force that by calling jack_recompute_total_latencies (right?). correct. > The problem is, you are advised to call this last function only after > calling jack_port_set_latency_range(), which you should only call in > the latency callback, which may be called next month... am I dumb > (probably) or is there a deadly loop? It's called whenever the graph changes (e.g. port connections change) or when some client invokes jack_recompute_total_latencies(). So whenever a setting in your app changes that affects the latency, call jack_recompute_total_latencies(), which in turn will trigger the callback set via jack_set_latency_callback(), and there you set the [new] port-latency(ies). ciao, robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK latency API clarifications
On Thu, Feb 20, 2014 at 5:32 PM, Stefano D'Angelo wrote: > Hi all, > > Let's say I have a client that introduces an amount of latency that's > variable at runtime and potentially unbounded. From JACK's docs it > seems that you need to recompute the min/max latencies in the latency > callback that's called "by the server" whenever it feels like, but you > can force that by calling jack_recompute_total_latencies (right?). > > The problem is, you are advised to call this last function only after > calling jack_port_set_latency_range(), which you should only call in > the latency callback, which may be called next month... am I dumb > (probably) or is there a deadly loop? > the latency callback will be issued (twice, once for upstream, once for downstream) after one of two things happens: * the graph changes * a client calls jack_recompute_total_latencies() you would call the latter if something happens that alters your clients own latency (e.g the change to some parameter of an algorithm that causes your client to change its latency). then you wait for the latency callback and reset your port latencies. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JACK latency API clarifications
Hi all, Let's say I have a client that introduces an amount of latency that's variable at runtime and potentially unbounded. From JACK's docs it seems that you need to recompute the min/max latencies in the latency callback that's called "by the server" whenever it feels like, but you can force that by calling jack_recompute_total_latencies (right?). The problem is, you are advised to call this last function only after calling jack_port_set_latency_range(), which you should only call in the latency callback, which may be called next month... am I dumb (probably) or is there a deadly loop? I couldn't find code handling dynamic latencies around and I'm way too lazy to try to understand JACK internals or to make silly tests etc. (also because they would tell nothing since we have multiple implementations of the same JACK API). Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
