20 Feb
2014
20 Feb
'14
11:32 p.m.
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
20 Feb
20 Feb
11:45 p.m.
On Thu, Feb 20, 2014 at 5:32 PM, Stefano D'Angelo <zanga.mail(a)gmail.com>wrote;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.
21 Feb
21 Feb
12:05 a.m.
2014-02-21 0:45 GMT+02:00 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Thu, Feb 20, 2014 at 5:32 PM, Stefano D'Angelo <zanga.mail(a)gmail.com>
wrote:
Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be
called from within the process callback too?
Stefano
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.
12:08 a.m.
On Thu, Feb 20, 2014 at 6:05 PM, Stefano D'Angelo <zanga.mail(a)gmail.com>wrote;wrote:
you cannot contact the server from with the process callback, so no.
and yes, it is NOT documented which JACK API calls do this.
reset your
port latencies.
Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be
called from within the process callback too?
12:09 a.m.
2014-02-21 1:08 GMT+02:00 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Thu, Feb 20, 2014 at 6:05 PM, Stefano D'Angelo <zanga.mail(a)gmail.com>
wrote:
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
reset your port latencies.
Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be
called from within the process callback too?
3:38 p.m.
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_lin…
2014-02-21 1:08 GMT+02:00 Stefano D'Angelo <zanga.mail(a)gmail.com>om>:
2014-02-21 1:08 GMT+02:00 Paul Davis
<paul(a)linuxaudiosystems.com>om>:
On Thu, Feb 20, 2014 at 6:05 PM, Stefano D'Angelo <zanga.mail(a)gmail.com>
wrote:
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 reset your port latencies.
Ok, thanks (to Robin too). Can jack_recompute_total_latenices() be
called from within the process callback too?
3:51 p.m.
On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo <zanga.mail(a)gmail.com>wrote;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.
4:04 p.m.
2014-02-21 16:51 GMT+02:00 Paul Davis <paul(a)linuxaudiosystems.com>om>:
I wonder what the jack_set_sample_rate_callback() is for then, but at
this point I don't care.
Stefano
On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo <zanga.mail(a)gmail.com>
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?
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.
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.
4:21 p.m.
On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo <zanga.mail(a)gmail.com>wrote;wrote:
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
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?
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.
4:41 p.m.
2014-02-21 17:21 GMT+02:00 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo <zanga.mail(a)gmail.com>
wrote:
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
Ok, thanks a lot again.
Stefano
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?
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. 
8:34 p.m.
On 02/21/2014 07:52 PM, Lieven Moors 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.
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
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? 
9 p.m.
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)
9:28 p.m.
On Fri, Feb 21, 2014 at 08:34:16PM +0100, Jörn Nettingsmeier wrote:
On 02/21/2014 07:52 PM, Lieven Moors 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.
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
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? 
20 Feb
20 Feb
11:47 p.m.
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
3727
days inactive
3728
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
6 participants
participants (6)
-
Fons Adriaensen -
Jörn Nettingsmeier -
Lieven Moors -
Paul Davis -
Robin Gareus -
Stefano D'Angelo