Re: [LAU] 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:
>> On Wed, February 24, 2016 8:42 am, Jonathan Brickman 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 :)
>> >
>> > 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 !!!!!
>>
>> 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.
>

 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user