2 Jul
2016
2 Jul
'16
8:10 a.m.
Hi there,
I've been happily using the pre-installed Jack2 that comes with Ubuntu
Studio 14.04.3.
Now I require the ability to use more than 64 clients then tried to
compile Jack2 from the package JACK 1.9.10 found at jackaudio.org/downloads
I'm running on a 64 bits machine but would like to get support for 32
bits applications as well.
Configure runs fine with ./waf configure --prefix=/usr --dbus --profile
--mixed --clients=256 --ports-per-application=2048 --alsa
--libdir=/usr/lib/x86_64-linux-gnu/ --libdir32=/usr/lib/i386-linux-gnu/
Then build fails:
(...)
/usr/bin/ld: cannot find -ldbus-1
(...)
I know it has something to do with the 32 bits library of dbus but need
help to find out how to get them properly.
I have already the following installed:
sudo apt-get install build-essential gcc-multilib g++-multilib
fakeroot checkinstall
sudo apt-get build-dep jackd2
sudo apt-get install libdbus-1-3:i386
Am I still missing some libraries?
Is it about some environment variable?
Is it necessary to compile libdbus?
Thanks for your input.
DjZU
2 Jul
2 Jul
8:36 a.m.
Hello
I have recently made stress tests of Jack under load and above +/- 100
clients it starts to behave strange.
Generally speaking it seem to not be designed for such use cases - see my
discussion on this list 2-3 weeks ago.
I am working on replacement and maybe what I do will be helpful, please PM
me at marcin(a)radiokit.org if you want to talk.
Marcin
02.07.2016 3:11 PM "DjZU" <djzu89(a)gmail.com> napisał(a):
Hi there,
I've been happily using the pre-installed Jack2 that comes with Ubuntu
Studio 14.04.3.
Now I require the ability to use more than 64 clients then tried to
compile Jack2 from the package JACK 1.9.10 found at
jackaudio.org/downloads
I'm running on a 64 bits machine but would like to get support for 32 bits
applications as well.
Configure runs fine with ./waf configure --prefix=/usr --dbus --profile
--mixed --clients=256 --ports-per-application=2048 --alsa
--libdir=/usr/lib/x86_64-linux-gnu/ --libdir32=/usr/lib/i386-linux-gnu/
Then build fails:
(...)
/usr/bin/ld: cannot find -ldbus-1
(...)
I know it has something to do with the 32 bits library of dbus but need
help to find out how to get them properly.
I have already the following installed:
sudo apt-get install build-essential gcc-multilib g++-multilib
fakeroot checkinstall
sudo apt-get build-dep jackd2
sudo apt-get install libdbus-1-3:i386
Am I still missing some libraries?
Is it about some environment variable?
Is it necessary to compile libdbus?
Thanks for your input.
DjZU
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
8:45 a.m.
On Sat, Jul 2, 2016 at 9:36 AM, marcin(a)saepia.net <marcin(a)saepia.net> wrote:
Hello
I have recently made stress tests of Jack under load and above +/- 100
clients it starts to behave strange.
Generally speaking it seem to not be designed for such use cases - see my
discussion on this list 2-3 weeks ago.
every external JACK client implies at least 1 context switch.
context switches are not free. their cost varies depending on the size of
the working set of the process (the amount of memory touched by the
process, notably during the JACK process() callback).
they might vary from <10 usecs to as much as 500usecs (the lowest possible
number is dependent on your CPU; the upper bound depends on the clients)
100 * 100 usecs = 10msecs
so, you've just used 10msecs of the time available for the process
callback. That's enormous (quite possibly larger than the actual time
available).
JACK is quite clever, but a process-level design (i.e. context switching
between clients) cannot scale to large numbers of clients. It would require
entirely different OS designs (e.g. 64 bit address space with hardware
protection rather than using an MMU) to reduce the context times to their
bare minimum. But even then, at say 10usec per context switch, 100 clients
is still 1 msec, which is a significant chunk of "very low latency
settings".
I don't know what you have in mind as "a replacement" but nobody who has
worked on JACK (or related ideas) in the last decade and a half has ever
suggested any way around this kind of limitation.
Internal clients (basically, plugins) do not have this issue, since there
is no context switch, just a thread-level switch, which is generally the
same as a fastest-possible context switch (no MMU invalidation). Thus, you
can scale up better, but still not *that* high.
9:28 a.m.
Paul,
By limitations I meant not latency but various undocumented hard-coded
limits such as one with SHM and generally speaking poor error handling if
they are hit, at least in jack2. Latency is not always an issue.
My approach also removes single router such as jackd that has to do loads
of context switches per each cycle if there are many clients and uses more
distributed approach.
But hard sync is not my requirement.
M.
02.07.2016 3:45 PM "Paul Davis" <paul(a)linuxaudiosystems.com> napisał(a):
On Sat, Jul 2, 2016 at 9:36 AM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
Hello
I have recently made stress tests of Jack under load and above +/- 100
clients it starts to behave strange.
Generally speaking it seem to not be designed for such use cases - see
my discussion on this list 2-3 weeks ago.
every external JACK client implies at least 1 context switch.
context switches are not free. their cost varies depending on the size of
the working set of the process (the amount of memory touched by the
process, notably during the JACK process() callback).
they might vary from <10 usecs to as much as 500usecs (the lowest possible
number is dependent on your CPU; the upper bound depends on the clients)
100 * 100 usecs = 10msecs
so, you've just used 10msecs of the time available for the process
callback. That's enormous (quite possibly larger than the actual time
available).
JACK is quite clever, but a process-level design (i.e. context switching
between clients) cannot scale to large numbers of clients. It would require
entirely different OS designs (e.g. 64 bit address space with hardware
protection rather than using an MMU) to reduce the context times to their
bare minimum. But even then, at say 10usec per context switch, 100 clients
is still 1 msec, which is a significant chunk of "very low latency
settings".
I don't know what you have in mind as "a replacement" but nobody who has
worked on JACK (or related ideas) in the last decade and a half has ever
suggested any way around this kind of limitation.
Internal clients (basically, plugins) do not have this issue, since there
is no context switch, just a thread-level switch, which is generally the
same as a fastest-possible context switch (no MMU invalidation). Thus, you
can scale up better, but still not *that* high.
12:58 p.m.
On Sat, Jul 02, 2016 at 09:45:48AM -0400, Paul Davis wrote:
context switches are not free. their cost varies
depending on the size of
the working set of the process (the amount of memory touched by the
process, notably during the JACK process() callback).
they might vary from <10 usecs to as much as 500usecs (the lowest possible
number is dependent on your CPU; the upper bound depends on the clients)
100 * 100 usecs = 10msecs
so, you've just used 10msecs of the time available for the process
callback. That's enormous (quite possibly larger than the actual time
available).
True, assuming you have single linear chain of 100 clients, and
each step involves a context switch.
In practice there are two factors that mitigate this problem:
1. Parts of the graph may run in parallel. And SMP systems
are more or less standard today.
2. Linear chains could be in the same process. In that case,
depending on implementation, you don't even need a thread
switch.
Exploiting both conditions at the same time requires some
intricate logic, but it's certainly possible. I have a
'proof of concept' actually running. The big remaining
question that needs to be resolved before this gets turned
into something real is if I want to support existing Jack
clients (via a replacement libjack on top of the new API).
Doing that complicates things quite a bit, but I haven't
abandoned the idea.
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)
1:04 p.m.
On Sat, Jul 2, 2016 at 1:58 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sat, Jul 02, 2016 at 09:45:48AM -0400, Paul Davis
wrote:
4-8 core systems are more or less standard. So this only reduces the cost
in the best possible scenario by a factor of 4-8. In more common cases, the
improvement is much less.
context switches are not free. their cost varies
depending on the size of
the working set of the process (the amount of memory touched by the
process, notably during the JACK process() callback).
they might vary from <10 usecs to as much as 500usecs (the lowest
possible
number is dependent on your CPU; the upper bound
depends on the clients)
100 * 100 usecs = 10msecs
so, you've just used 10msecs of the time available for the process
callback. That's enormous (quite possibly larger than the actual time
available).
True, assuming you have single linear chain of 100 clients, and
each step involves a context switch.
In practice there are two factors that mitigate this problem:
1. Parts of the graph may run in parallel. And SMP systems
are more or less standard today.
2. Linear chains could be in the same process. In that case,
depending on implementation, you don't even need a thread
switch.
Actually, I misspoke - this is already implemented. Internal clients will
be executed in the same thread if they are part of a serial chain.
IMO, the reality is that chaining together entirely independent signal
processing code is best done via plugins (internal clients, in a JACK
context), not processes. The clever hack that JACK represents is useful for
connecting small numbers of processes, but I don't believe that the design
should be used as an indication that process-level chains are the right way
to composite signal processing elements.
2:04 p.m.
On Sat, Jul 02, 2016 at 02:04:07PM -0400, Paul Davis wrote:
But the same doesn't happen (in current Jack implementations) if you
have a linear chain of clients in the same external process.
4-8 core systems are more or less standard. So this
only reduces the cost
in the best possible scenario by a factor of 4-8. In more common cases, the
improvement is much less.
But in practice still significant.
2. Linear
chains could be in the same process. In that case,
depending on implementation, you don't even need a thread
switch.
Actually, I misspoke - this is already implemented. Internal clients will
be executed in the same thread if they are part of a serial chain. IMO, the reality is that chaining together entirely
independent signal
processing code is best done via plugins (internal clients, in a JACK
context), not processes. The clever hack that JACK represents is useful for
connecting small numbers of processes, but I don't believe that the design
should be used as an indication that process-level chains are the right way
to composite signal processing elements.
So that leads to a two-layer design: a small number of Jack
clients (each of which can be a separate process), and within
each of those a second layer that runs arbitrary graphs of
modules (which can be plugins), in multiple threads.
The problem with this is that the outer layer clients are
always run as a single blob - at the boundary between
the two layers all dependencies are 'ANDed' together, only
because the outer layer can't see the internal graph and
has to assume that all outputs depend on all inputs.
To avoid this, the two layers need to be aware of each other
in some way. It's exactly this that I've been working on.
The internal scheduler becomes part of the user-side client
library, and interacts with the outer one.
The result is for example that an external insert (as in
Ardour) doesn't add latency. Of course, in pathological
cases this can lead to more process switches. In practice
that's quite often not the case - the process which 'calls'
the external processor will be able to continue if it has
independent subgraphs (as would be the case for a mixer
with many channel strips).
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)
3 Jul
3 Jul
11:53 a.m.
Thanks John! libdbus-1-dev:i386 was the one library I was missing.
Now I have troubles to cross compile Opus which I want to be compiled
within Netjack.
I tried different versions of libopus which I grabbed from opus-codec.org
I guess I'm wrong at the configure stage:
./configure --prefix=/usr --enable-custom-modes CFLAGS="-m32"
LDFLAGS="-m32" CPPFLAGS="-m32"
since ld is complaining
(...)
ld: skipping incompatible //usr/lib/libopus.so searching for -lopus
ld: skipping incompatible //usr/lib/libopus.a searching for -lopus
ld: cannot find -lopus
So Jack see opus and opus custom_modes at configure, but failed at build.
Thanks for your input.
DjZU
Le 02/07/2016 15:51, John Rigg a écrit :
On Sat, Jul 02, 2016 at 03:10:54PM +0200, DjZU wrote:
/usr/bin/ld: cannot find -ldbus-1
Do
you have libdbus-1-dev installed?
Do you have a specific need for dbus? If not you could sidestep
the issue by compiling without --dbus.
John
2863
days inactive
2864
days old
jackaudio@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
DjZU -
Fons Adriaensen -
John Rigg -
marcin＠saepia.net -
Paul Davis