23 Feb
2016
23 Feb
'16
4:11 p.m.
On Tue, February 23, 2016 8:32 am, Jonathan Brickman wrote:
So, if one has a lot of things happening, multiple
JACK
instances could make more use of available resources?
I don't think that follows. That seems to me that you are asking if since
you have a lot of processing going on, would adding additional overhead
help.
If you have multiple processing chains that do not depend on one another,
then using jack2 may help, it can take advantage of multiple processor
cores.
I don't know if that would help with the two yoshimi instances or not, but
since you do not appear to be CPU limited, then probably not.
Real time operation is often more about overhead, the minimum amount of
time it takes for the OS to switch between user mode and kernel mode, the
time it takes the scheduler to determine the next process to run, the
amount of time it takes the kernel to read the current state of the
interrupt controller and call interrupt handlers, things like that. A
lot of those things take fixed amounts of time, so the best thing you can
do for a given system is to try to do them less often, i.e. larger
buffers. For given hardware you may be able to change the system behavior
by modifying firmware settings, like turning off hyperthreading/SMT, or
changing power saving features. Probably those are documented in some
wiki somewhere, but I can't find it on the jackaudio.org wiki at the
moment.
Of course you have to start by making sure that the OS runs the real-time
tasks first, and does not perform general OS housekeeping tasks when there
is real-time work to be done. That is the point of the -RT kernel patches
and to a lesser extent the low-latency config option in the unpatched
kernel tree.
--
Chris Caudle
23 Feb
23 Feb
4:31 p.m.
New subject: What exactly is JACK DSP % usage ?
On Tue, 23 Feb 2016 09:10:43 -0600, Chris Caudle wrote:
Probably those are documented in some wiki somewhere,
but I can't find
it on the jackaudio.org wiki at the moment.
http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-February/103957…
http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-February/103959…
4:35 p.m.
New subject: Multiple asynchronous JACK chains resampled?
So, if one has
a lot of things happening, multiple JACK
instances could make more use of available resources?
I don't think that
follows. That seems to me that you are asking if since
you have a lot of processing going on, would adding additional overhead
help.
If you have multiple processing chains that do not depend on one another,
then using jack2 may help, it can take advantage of multiple processor
cores.
JACK2 is indeed in use. Things are nowhere near as good under JACK1 in
this setup.
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
4:58 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, Feb 23, 2016 at 10:35 AM, Jonathan Brickman <jeb(a)ponderworthy.com>
wrote:
So, if one has a lot of things happening, multiple JACK
instances could make more use of available resources?
I don't think that follows. That seems to me that you are asking if since
you have a lot of processing going on, would adding additional overhead
help.
What I want to do, is to use the resources I have to run multiple signal
generation and processing chains asynchronously, in parallel, and then use
the final audio-hardware-synchronized chain to resample them all into one,
perhaps using the Zita tools. Anyone know if this is possible? I saw this
flow structure work very well in the video domain, quite a few years ago.
That's not what you want to do at all.
JACK is designed to be a *synchronous* system. All clients process audio
corresponding to the same period of time, precisely in sync with each
other. You do not want to "resample them all into one", and certainly not
with the zita tools.
A "correct" digital audio processing and/or synthesis environment consists
of a single audio interface (or at least, a single digital sample ("word")
clock). You can run any number of JACK clients, connected in arbitrary
ways. But using multiple audio interfaces (which is what the zita tools are
related to) is not the right thing to do unless you are forced to by lack
of funds or inappropriate hardware.
5:38 p.m.
New subject: Multiple asynchronous JACK chains resampled?
What I want to do, is to use the resources I have
to run multiple
signal generation and processing chains asynchronously, in
parallel, and then use the final audio-hardware-synchronized chain
to resample them all into one, perhaps using the Zita tools.
Anyone know if this is possible? I saw this flow structure work
very well in the video domain, quite a few years ago.
That's not what you want to do at all.
JACK is designed to be a *synchronous* system. All clients process
audio corresponding to the same period of time, precisely in sync with
each other. You do not want to "resample them all into one", and
certainly not with the zita tools.
A "correct" digital audio processing and/or synthesis environment
consists of a single audio interface (or at least, a single digital
sample ("word") clock). You can run any number of JACK clients,
connected in arbitrary ways. But using multiple audio interfaces
(which is what the zita tools are related to) is not the right thing
to do unless you are forced to by lack of funds or inappropriate hardware.
I do understand that JACK is designed to be completely synchronous. But
a good pipelined architecture, can take multiple synchronous processing
chains running independently (asynchronously to each other), and then
merge them at the output end. What I want to do is the equivalent using
JACK at the synchronous level, so that I take advantage of more of my
computing power. Eventually I will want to do exactly the same using
four or five RPi-compatibles, with just one of them having the audio
output; but right now I have about 75% of my CPU and 6+ gigabytes of RAM
not being touched, so clearly the testbed is waiting :-). The video
processing pipeline I saw a while ago used a proprietary bus (it was a
while ago), I am thinking IP is probably the simplest now, over
localhost within this box, and through a good switch whenever I start
work on RPis (which is probably not soon but is worth contemplating).
And to use the Zita tools, I was going to see if there was an
audio-over-IP transport which delivered ALSA ports :-) I don't quite
remember, it has been about eight months since I looked. If there is, I
would expect the existing Zita tools would do wonderfully for the
resampling connectors. If not, I wonder what best to use for
JACK-to-JACK resampling?
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
5:47 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, Feb 23, 2016 at 11:38 AM, Jonathan Brickman <jeb(a)ponderworthy.com>
wrote:
I do understand that JACK is designed to be completely synchronous. But a
good pipelined architecture, can take multiple synchronous processing
chains running independently (asynchronously to each other), and then merge
them at the output end.
That implies (a) extra CPU load (b) possible loss of quality.
What I want to do is the equivalent using JACK at the
synchronous level,
so that I take advantage of more of my computing power. Eventually I will
want to do exactly the same using four or five RPi-compatibles, with just
one of them having the audio output;
Doing this correctly would imply using a single word clock distributed to
all your R-Pi's. But I doubt that you're going to do that. Instead, you're
going to try to distribute the "JACK clock".
You have two choices:
(1) try to use one of the implementations of netjack, which effectively
distributes the "JACK clock" across the network
(2) the "other" zita tool, zita-njbridge, which is a client that
sends/receives audio over a (local) network and resamples as necessary. You
will still need to run JACK on each R-Pi and decide what to use as the
clock via your choice of backend. No clock sync is assumed.
6:40 p.m.
New subject: Multiple asynchronous JACK chains resampled?
I do understand that JACK is designed to be
completely
synchronous. But a good pipelined architecture, can take multiple
synchronous processing chains running independently
(asynchronously to each other), and then merge them at the output
end.
That implies (a) extra CPU load (b) possible loss of quality.
Yup. No risk and no
resources, no gain :-) But given what I have (and
what is within reach with a stack of RPis), it seems well worth it to try.
What I want to do is the equivalent using JACK at the synchronous
level, so that I take advantage of more of my computing power.
Eventually I will want to do exactly the same using four or five
RPi-compatibles, with just one of them having the audio output;
Doing this correctly would imply using a single word clock distributed
to all your R-Pi's. But I doubt that you're going to do that. Instead,
you're going to try to distribute the "JACK clock".
You have two choices:
(1) try to use one of the implementations of netjack, which
effectively distributes the "JACK clock" across the network
(2) the "other" zita tool, zita-njbridge, which is a client that
sends/receives audio over a (local) network and resamples as
necessary. You will still need to run JACK on each R-Pi and decide
what to use as the clock via your choice of backend. No clock sync is
assumed.
Indeed, that sounds like my starting place. I have to admit that I like
the zita-njbridge approach more, because that way, since I am definitely
resampling before it hits the audio hardware, it is only a very simple
and short chain -- IP inputs to zita-njbridge to hardware -- which has
to be synchronous with the physical audio chipset. So the DSP % usage
on the hardware-connected chain becomes low, because it is as simple as
it is, and each of the chains in action have a lot less also,
distributing the work carefully. If zita-njbridge treats zero input in
the stream as silence, the overall benefit should be enormous :-)
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
6:42 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, February 23, 2016 9:35 am, Jonathan Brickman wrote:
What I want to do, is to use the resources I have to
run multiple signal
generation and processing chains asynchronously, in parallel, and then
use the final audio-hardware-synchronized chain to resample them all
into one, perhaps using the Zita tools.
I think you may be confusing two different concepts.
Running in parallel
running asynchronous processing
You can run multiple independent synchronous processes in parallel, which
is probably what you want. Using jack2 should allow that, but you have to
check the connection graph to make sure it is happening. The original
description you gave was not very detailed, are the Yoshimi instances just
connected to the jack output and that is all? Is there any stage where
both Yoshimi instances connect that would become the processing limit for
the period?
use the final audio-hardware-synchronized chain to
resample them all
into one, perhaps using the Zita tools.
Resampling will always add additional latency. Having unsynchronized
streams that have to be synchronized will always add additional latency.
The zita-nj (network to jack) tools describe this very well in the man
page excerpt below.
I don't recall you relating what current latency setting you are using.
If you are contemplating some complicated scheme which is going to add
additional processing overhead and additional latency anyway, have you
tried just increasing the buffer size? That is very simple to try and may
be all you need.
From man zita-njbridge:
When connecting two Jack
systems with unsynchronised
periods the minimum additional latency under worst case
conditions is the sum of the two period times. Additional
latency means any latency required to make the connection
work without interruption. The round-trip latency from an
ideal (zero excess latency) analog input on the sender to
an ideal (idem) analog output on the receiver will be twice
this value. Worst case conditions means that the both sender
and receiver can run at arbitrary times within their
respective periods.
Zita-njbridge is designed to provide a defined and constant
additional latency. The target value is the sum of the two
periods, plus resampling delay, plus any extra buffering
specified by the user. The actual latency will be this value
plus the average network delay.
--
Chris Caudle
7:27 p.m.
New subject: Multiple asynchronous JACK chains resampled?
What I want to
do, is to use the resources I have to run multiple signal
generation and processing chains asynchronously, in parallel, and then
use the final audio-hardware-synchronized chain to resample them all
into one, perhaps using the Zita tools.
I think you may be confusing two different
concepts.
Running in parallel
running asynchronous processing You can run multiple independent synchronous processes
in parallel, which
is probably what you want. Using jack2 should allow that, but you have to
check the connection graph to make sure it is happening. The original
description you gave was not very detailed, are the Yoshimi instances just
connected to the jack output and that is all? Is there any stage where
both Yoshimi instances connect that would become the processing limit for
the period?
Each Yoshimi instance hits a separate input (thread) in Non-Mixer, this
is one of the things which has made things work as well as they are.
use the final
audio-hardware-synchronized chain to resample them all
into one, perhaps using the Zita tools.
Resampling will always add additional
latency. Having unsynchronized
streams that have to be synchronized will always add additional latency.
The zita-nj (network to jack) tools describe this very well in the man
page excerpt below.
7:31 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, Feb 23, 2016 at 1:27 PM, Jonathan Brickman <jeb(a)ponderworthy.com>
wrote:
No, I know the difference very well. My architecture currently has seven
synchronous parallel chains right now ( see
http://lsn.ponderworthy.com/doku.php/concurrent_patch_management ),
this document is a clear explanation of why the person that made
application-level modular audio possible on Linux now believes in
Monolithic DAWs :)
10:42 p.m.
New subject: Multiple asynchronous JACK chains resampled?
No, I know the difference very well. My architecture currently
has seven synchronous parallel chains right now ( see
http://lsn.ponderworthy.com/doku.php/concurrent_patch_management ),
this document is a clear explanation of why the person that made
application-level modular audio possible on Linux now believes in
Monolithic DAWs :)
I don't doubt it! But there is no monolithic DAW and never
has been,
that could give me half of what you and the folks who designed the rest
of my tools are mostly responsible for producing :-) And that is much
appreciated !!!!!
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
24 Feb
24 Feb
8:21 a.m.
New subject: Multiple asynchronous JACK chains resampled?
On Wed, February 24, 2016 8:42 am, Jonathan Brickman wrote:
FYI, we are using on a very regular basis for a number of years now
numerous instances of JACK running on multiple hosts which communicate via
netjack. So from our experience your goal of running multiple RPi's is
certainly achievable. You may need to get a few spare screens/keyboards to
make things slightly easier for administration purposes.
In our studio the building is the monolithic DAW.
One of the benefits of this approach is that NONE of our computing
hardware ever gets 'end of life'd' and we can add in additional processing
power any time we need to without having to completely rebuild the entire
operation for every new work station.
We literally save hundreds of thousands of dollars compared to our
colleagues who insist on running monolithic solutions at their studios.
The result is that every dollar we spend is expanding the capacity of our
system without sacrificing the progress we have already made. The only
things we have to be concerned with is the cost of electricity and keeping
an eye on the increasingly unusual and extreme weather patterns.
We can leverage the power of the swarm in ways far beyond that of a
monolithic setup. However it probably takes a masters degree or two to
make this kind of thing work well so it is not going to be everyone's cup
of tea.
--
Patrick Shirkey
Boost Hardware Ltd
No, I know the difference very well. My architecture currently
has seven synchronous parallel chains right now ( see
http://lsn.ponderworthy.com/doku.php/concurrent_patch_management ),
this document is a clear explanation of why the person that made
application-level modular audio possible on Linux now believes in
Monolithic DAWs :)
I don't doubt it! But there is no monolithic DAW and never
has been,
that could give me half of what you and the folks who designed the rest
of my tools are mostly responsible for producing :-) And that is much
appreciated !!!!!
4:25 p.m.
New subject: Multiple asynchronous JACK chains resampled?
FYI, we are using on a very regular basis for a number
of years now
numerous instances of JACK running on multiple hosts which communicate via
netjack. So from our experience your goal of running multiple RPi's is
certainly achievable. You may need to get a few spare screens/keyboards to
make things slightly easier for administration purposes.
In our studio the building is the monolithic DAW.
:-) Have been trying to find a
wisecrack for that one, I am still smiling.
One of the benefits of this approach is that NONE of
our computing
hardware ever gets 'end of life'd' and we can add in additional processing
power any time we need to without having to completely rebuild the entire
operation for every new work station.
We literally save hundreds of thousands of dollars compared to our
colleagues who insist on running monolithic solutions at their studios.
The result is that every dollar we spend is expanding the capacity of our
system without sacrificing the progress we have already made. The only
things we have to be concerned with is the cost of electricity and keeping
an eye on the increasingly unusual and extreme weather patterns.
We can leverage the power of the swarm in ways far beyond that of a
monolithic setup. However it probably takes a masters degree or two to
make this kind of thing work well so it is not going to be everyone's cup
of tea.
--
Patrick Shirkey
Boost Hardware Ltd
Patrick, that is really something. Sounds like my daydreams
many years
ago. Can you tell us a bit about what kinds of applications you use
this ("cluster" perhaps, or "building" *grin*) for? And what kind of
latency options do you have available? I'd love to know as much as you
might care to share!
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
6:02 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Thu, February 25, 2016 2:25 am, Jonathan Brickman wrote:
We use this system for a variety of multimedia processing and creation
tasks including music creation, video processing, 3d graphics generation
among other things. Netjack and jack/alsa midi enable us to stream
audio/midi from one machine to another in "realtime". We try not to over
stress the latency settings too much in this context however we generally
run at very low latency on our main audio devices which can handle that
kind of load.
YMMV, with regards to passing video and 3d data around too.
The main concern with this kind of setup is that it takes a little bit of
effort to get into the right headspace to work with it. Once you are up
and running it is a powerful system but if you step away for a few
days/weeks you need some time to refresh on the more difficult tasks.
When the system is running at full clock it is not much different from
being at the helm of a busy cruiseliner or aircraft cockpit. And yes, the
weather is a major concern.
I think your solution to the session issue is a pretty elegant way of
handling the problem. It's similar to how we run our systems too. When we
are on we are on all the way. The main difference is that we can bring up
and take down additional processing power without having a detrimental
effect on the rest of the system.
--
Patrick Shirkey
Boost Hardware Ltd
FYI, we are
using on a very regular basis for a number of years now
numerous instances of JACK running on multiple hosts which communicate
via
netjack. So from our experience your goal of running multiple RPi's is
certainly achievable. You may need to get a few spare screens/keyboards
to
make things slightly easier for administration purposes.
In our studio the building is the monolithic DAW.
:-) Have been trying to find a
wisecrack for that one, I am still
smiling.
One of the benefits of this approach is that NONE
of our computing
hardware ever gets 'end of life'd' and we can add in additional
processing
power any time we need to without having to completely rebuild the
entire
operation for every new work station.
We literally save hundreds of thousands of dollars compared to our
colleagues who insist on running monolithic solutions at their studios.
The result is that every dollar we spend is expanding the capacity of
our
system without sacrificing the progress we have already made. The only
things we have to be concerned with is the cost of electricity and
keeping
an eye on the increasingly unusual and extreme weather patterns.
We can leverage the power of the swarm in ways far beyond that of a
monolithic setup. However it probably takes a masters degree or two to
make this kind of thing work well so it is not going to be everyone's
cup
of tea.
--
Patrick Shirkey
Boost Hardware Ltd
Patrick, that is really something. Sounds like my daydreams
many years
ago. Can you tell us a bit about what kinds of applications you use
this ("cluster" perhaps, or "building" *grin*) for? And what kind
of
latency options do you have available? I'd love to know as much as you
might care to share!
10:17 p.m.
New subject: Multiple asynchronous JACK chains resampled?
The main concern with this kind of setup is that it
takes a little bit of
effort to get into the right headspace to work with it. Once you are up
and running it is a powerful system but if you step away for a few
days/weeks you need some time to refresh on the more difficult tasks.
When the system is running at full clock it is not much different from
being at the helm of a busy cruiseliner or aircraft cockpit. And yes, the
weather is a major concern.
I think your solution to the session issue is a pretty elegant way of
handling the problem. It's similar to how we run our systems too. When we
are on we are on all the way. The main difference is that we can bring up
and take down additional processing power without having a detrimental
effect on the rest of the system.
Well, it is now very clear that the next
order-of-magnitude does exist
in your hands, the way is clear! Real modularity, or better "the DAW is
the building" (I really do like that), is clearly the Qua Non of what I
am looking for. And forewarned, forearmed on the difficulty; I am
rubbing my hands in glee, it may take me quite a while but it will
occur, I can smell it. I will look towards simplifying its oversight if
I possibly can :-) And some day in the more distant future, Real
Programmers will write the flowchart-style GUI!
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
6:37 p.m.
New subject: Jack parallelism? Question.
On February 24, 2016 06:21:44 PM Patrick Shirkey wrote:
On Wed, February 24, 2016 8:42 am, Jonathan Brickman
wrote:
FYI, we are using on a very regular basis for a number of years now
numerous instances of JACK running on multiple hosts which communicate via
netjack. So from our experience your goal of running multiple RPi's is
certainly achievable. You may need to get a few spare screens/keyboards to
make things slightly easier for administration purposes.
In our studio the building is the monolithic DAW.
One of the benefits of this approach is that NONE of our computing
hardware ever gets 'end of life'd' and we can add in additional processing
power any time we need to without having to completely rebuild the entire
operation for every new work station.
We literally save hundreds of thousands of dollars compared to our
colleagues who insist on running monolithic solutions at their studios.
The result is that every dollar we spend is expanding the capacity of our
system without sacrificing the progress we have already made. The only
things we have to be concerned with is the cost of electricity and keeping
an eye on the increasingly unusual and extreme weather patterns.
We can leverage the power of the swarm in ways far beyond that of a
monolithic setup. However it probably takes a masters degree or two to
make this kind of thing work well so it is not going to be everyone's cup
of tea.
--
Patrick Shirkey
Boost Hardware Ltd
Absolutely fascinating!
Question, maybe not exactly on topic:
As I understand, each client that is added in series to
a processing chain adds latency, this is still true?
This is a big reason why I like to use a plugin 'host',
even something a simple as JackRack, because the
processing is done all in one cycle - in 'parallel' I guess
might be the term.
Q: Would it be possible to provide Jack with a mechanism
where selected clients could be run in this 'parallel' mode?
Ie. Clients A B and C are connected in series but we want
B to operate on A's processed data, and C to operate on B's
processed data, all in one cycle.
Just like say, JackRack or any other effects rack system in a host.
If this were possible it could 'revive' the modular approach
and put it on equal footing as the 'parallel' approach, no?
Client apps having no equivalent 'plugin' could be connected
in series with no extra latency.
Thanks.
Tim.
No, I
know the difference very well. My architecture currently
has seven synchronous parallel chains right now ( see
http://lsn.ponderworthy.com/doku.php/concurrent_patch_management ),
this document is a clear explanation of why the person that made
application-level modular audio possible on Linux now believes in
Monolithic DAWs :)
I don't doubt it! But there is no monolithic DAW and never has been,
that could give me half of what you and the folks who designed the rest
of my tools are mostly responsible for producing :-) And that is much
appreciated !!!!!
8:50 p.m.
New subject: Jack parallelism? Question.
On Thu, February 25, 2016 4:36 am, Tim E. Real wrote:
On February 24, 2016 06:21:44 PM Patrick Shirkey
wrote:
It would be a neat feature if it is possible. It would require bypassing
the server temporarily to send data directly between applications. If the
user is prepared to sacrifice some control of the audio stream, Jack
could let the user out of the round trip as long as it knows that there
is a "direct processing chain" to follow.
Without going into it deeply it seems like it could be handled with a flag
on the i/o ports to notify JACK to connect the data directly from/to each
port instead of via the server.
In my experience it is not necessary in order to be productive with a
Linux audio swarm/cluster. Monolithic apps can fulfill that task when
required.
It won't get rid of network latency either. At some point a certain amount
of latency has to be accepted as part of the workflow in a cluster
environment. However the latency introduced via the modular/clustered
system is a minor sacrifice when compared to the real monetary costs that
would be incurred trying to replicate our results with a monolithic app.
--
Patrick Shirkey
Boost Hardware Ltd
On Wed, February 24, 2016 8:42 am, Jonathan
Brickman wrote:
rest
Absolutely fascinating!
Question, maybe not exactly on topic:
As I understand, each client that is added in series to
a processing chain adds latency, this is still true?
This is a big reason why I like to use a plugin 'host',
even something a simple as JackRack, because the
processing is done all in one cycle - in 'parallel' I guess
might be the term.
Q: Would it be possible to provide Jack with a mechanism
where selected clients could be run in this 'parallel' mode?
Ie. Clients A B and C are connected in series but we want
B to operate on A's processed data, and C to operate on B's
processed data, all in one cycle.
Just like say, JackRack or any other effects rack system in a host.
If this were possible it could 'revive' the modular approach
and put it on equal footing as the 'parallel' approach, no?
Client apps having no equivalent 'plugin' could be connected
in series with no extra latency.
> No, I know the difference very well. My
architecture currently
> has seven synchronous parallel chains right now ( see
> http://lsn.ponderworthy.com/doku.php/concurrent_patch_management
),
this document is a clear explanation of why the person that made
application-level modular audio possible on Linux now believes in
Monolithic DAWs :)
I don't doubt it! But there is no monolithic DAW and never has been,
that could give me half of what you and the folks who designed the of my tools are mostly responsible for producing
:-) And that is much
appreciated !!!!!
FYI, we are using on a very regular basis for a number of years now
numerous instances of JACK running on multiple hosts which communicate
via
netjack. So from our experience your goal of running multiple RPi's is
certainly achievable. You may need to get a few spare screens/keyboards
to
make things slightly easier for administration purposes.
In our studio the building is the monolithic DAW.
One of the benefits of this approach is that NONE of our computing
hardware ever gets 'end of life'd' and we can add in additional
processing
power any time we need to without having to completely rebuild the
entire
operation for every new work station.
We literally save hundreds of thousands of dollars compared to our
colleagues who insist on running monolithic solutions at their studios.
The result is that every dollar we spend is expanding the capacity of
our
system without sacrificing the progress we have already made. The only
things we have to be concerned with is the cost of electricity and
keeping
an eye on the increasingly unusual and extreme weather patterns.
We can leverage the power of the swarm in ways far beyond that of a
monolithic setup. However it probably takes a masters degree or two to
make this kind of thing work well so it is not going to be everyone's
cup
of tea.
--
Patrick Shirkey
Boost Hardware Ltd 
9:32 p.m.
New subject: Jack parallelism? Question.
On 24 Feb 2016 17:37, "Tim E. Real" <termtech(a)rogers.com> wrote:
Ie. Clients A B and C are connected in series but we
want
B to operate on A's processed data, and C to operate on B's
processed data, all in one cycle.
That already happens in series in one cycle. Surely the last thing you want
if the clients are data dependent is this to happen in parallel?
Best wishes,
Neil
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
25 Feb
25 Feb
2:14 a.m.
New subject: Jack parallelism? Question.
On February 24, 2016 08:32:56 PM Neil C Smith wrote:
On 24 Feb 2016 17:37, "Tim E. Real"
<termtech(a)rogers.com> wrote:
So no added latency for series clients?
OK good. Sorry, my mistake.
I know that hardware ports are another matter, though.
Thanks.
Tim.
Ie. Clients A B and C are connected in series but
we want
B to operate on A's processed data, and C to operate on B's
processed data, all in one cycle.
That already happens in series in one cycle. Surely the last thing you want
if the clients are data dependent is this to happen in parallel?
Best wishes,
Neil
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
23 Feb
23 Feb
7:40 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, 23 Feb 2016, Jonathan Brickman wrote:
That helped! I now have to wonder what best to do.
At least in theory, I could
run the pre-hardware chains at 192K :-) That could certainly be set up to add
very little latency to the resampling phase, if it worked! We will see :-) I
almost want to go to non-digital electronic audio for the resample phase; it
could tend to simplify...it would mean a lot more output hardware...
That is not nessessarily the case. Lets say you have machine A that has a
midi port with midi in, then you go to midi out and then to midi in on
Machine B. You have just added twice the latency you have just going into
one machine (making it 3 times) and the synth is just getting the play
info. Now the synth makes sound, has latency going out of machine B and
then going into machine A and then out of Machine A... again 3 times the
latency... 6 times all together. Better to use a HW through box from the
keyboard and split it to your various audio boxes... and mix the audio out
directly in analog. Use the network for control... It may be possible to
get lower latency with MIDI in/out/in by bypassing jack in some cases.
(Jack would still be better for recording as the timing is kept)
--
Len Ovens
www.ovenwerks.net
8:17 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, February 23, 2016 12:27 pm, Jonathan Brickman wrote:
No, I know the difference very well. My architecture
currently has
seven synchronous parallel chains right now
OK, now we're getting some details. That is very much different than the
impression I got from earlier emails, that the system was using 85% dsp
with only two Yoshimi instances running.
So actually there are how many applications in the Jack graph? At least
seven sub-graphs, but how many total connections?
There are at least seven instances of calf plugins, right?
Each chain is controlled and modulated by Calf plugin
sets and a single big...Non-Mixer.
I think this may be the source of the high DSP usage:
"All JACK connections, MIDI and audio, which will ever be needed in any
patch, are always connected."
Even when an application such as Yoshimi is not creating any audio data,
jackd has no way of detecting that, so will call the jack process function
for each application during each period. I haven't looked far enough down
into the details, but I assume that some process, either the application
or jackd, has to explicitly put all 0 value samples into the buffer each
period to make sure there is no unwanted audio output. Even staying
silent is not a zero cost operation.
Each Yoshimi instance hits a separate input (thread)
in Non-Mixer, this
is one of the things which has made things work as well as they are.
Paul, Stephane, or J Liles would have to comment on the details of that,
I'm not sure how the final output mixing affects the processing graph with
jack2. Maybe that is the point that ties all the independent graph lines
together and forces everything to happen within one period.
Would it be possible to call jack_disconnect and jack_connect in addition
or in place of changing the MIDI channel of the control keyboard?
At least as an experiment. Possibly there is a high percentage of the
period where jack is just processing empty buffers from all the synth
chains which are connected but not actually generating audio.
I am not sure why I cannot cram more in the JACK
cycle
given my low CPU usage for the JACK process
Each function call takes time, each context switch for a different process
to get run time, any time the OS has to synchronize data structures
between different CPU's, all those things take time.
but I am thinking that this
is probably bound to the audio signal sample rate, and I am already at
96Hz for that very reason.
Have you tried running at 48kHz? For a given amount of time, having a
higher sample rate means more processing to generate or process the audio
samples. For a given number of samples the latency is lower, for a given
latency the work load is higher. Since in live performance you really
care about the latency, it seems like for a given latency you would want
to reduce the CPU load. Maybe that won't matter since you don't seem to
be CPU limited, but could be a useful experiment.
--
Chris Caudle
10:14 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, Feb 23, 2016 at 01:16:32PM -0600, Chris Caudle wrote:
Even staying silent is not a zero cost operation.
But very close. All the process function has to do is to
write zeros to the output buffer. That can be done very
fast. If having to do this is a problem, then actually
generating some sound would be a much bigger one. Which
means that things would fail anyway.
It is of course up to the synth to be aware of inactive
voices and reduce its own processing effort for those.
Maybe some don't do that.
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)
10:32 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, 23 Feb 2016 21:14:00 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Tue, Feb 23, 2016 at 01:16:32PM -0600, Chris Caudle
wrote:
However one must make the distinction between an inactive voice and a
non-sounding one. In the latter case processes will still be running to check if
there are any notes to deal with, and any in-line effects will be fully
operational - reverb being one of the heavyweights.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Even staying silent is not a zero cost operation.
But very close. All the process function has to do is to
write zeros to the output buffer. That can be done very
fast. If having to do this is a problem, then actually
generating some sound would be a much bigger one. Which
means that things would fail anyway.
It is of course up to the synth to be aware of inactive
voices and reduce its own processing effort for those.
Maybe some don't do that.
Ciao,
11:30 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, Feb 23, 2016 at 09:32:46PM +0000, Will Godfrey wrote:
However one must make the distinction between an
inactive voice and a
non-sounding one. In the latter case processes will still be running to check if
there are any notes to deal with, and any in-line effects will be fully
operational - reverb being one of the heavyweights.
As an example zita-rev1 takes 2% of a single CPU on my machine.
And since reverb is a linear process you don't need a separate
one for each note. You would have at most one per instrument
in a multitimbral patch. An even a reverb could be bypassed
some time after the last note has ended, as can all effects.
Checking if there are any notes again doesn't take any
significant time.
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)
8:57 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On 02/23/2016 04:35 PM, Jonathan Brickman wrote:
What I want to do, is to use the resources I have to
run multiple signal
generation and processing chains asynchronously, in parallel, and then
use the final audio-hardware-synchronized chain to resample them all
into one, perhaps using the Zita tools. Anyone know if this is
possible? I saw this flow structure work very well in the video domain,
quite a few years ago.
Video is a lot more forgiving when it comes to timing and the modern CPU
architecture is optimized for bandwidth.
It can be entirely possible to reliably process 4K RGBA images in 40ms
(25fps) ~900MB/s; while the same machine fails to process 128 audio
samples in under 2ms (~256kB/s).
2c,
robin
9:12 p.m.
New subject: Multiple asynchronous JACK chains resampled?
On Tue, 23 Feb 2016, Robin Gareus wrote:
Video is a lot more forgiving when it comes to timing
and the modern CPU
architecture is optimized for bandwidth.
It can be entirely possible to reliably process 4K RGBA images in 40ms
(25fps) ~900MB/s; while the same machine fails to process 128 audio
samples in under 2ms (~256kB/s).
In general a delay of an extra 40ms frame or two doesn't matter either so
long as the sync lines up. I have watched a number of remote news bits
where the latency is ~1 second or more (which is disturbing BTW). I have
had better long distance phone call latency.
Ya, video and audio are two different animals.
--
Len Ovens
www.ovenwerks.net
3201
days inactive
3203
days old
linux-audio-user@lists.linuxaudio.org
25 comments
11 participants
participants (11)
-
Chris Caudle -
Fons Adriaensen -
Jonathan Brickman -
Len Ovens -
Neil C Smith -
Patrick Shirkey -
Paul Davis -
Ralf Mardorf -
Robin Gareus -
Tim E. Real -
Will Godfrey