24 Feb
2016
24 Feb
'16
8:50 p.m.
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