On 03/11/2016 05:53 PM, Jonathan Brickman wrote:
>>
> OK, I think I see what you are referring to: the switching nature of the
> client list, where the JACK server has to switch between. And this is
> entirely why it helps to run multiple JACK servers on multiple
> motherboards, and why it will
On Fri, 11 Mar 2016, Jonathan Brickman wrote:
Nope, I don't want to switch engines. Everything runs at once, and
runs very well by the way. I just want to take more advantage of
what I have, by running some things asynchronously, exactly the way
some are already doing using multiple
On Fri, Mar 11, 2016, at 07:13 PM, Fons Adriaensen wrote:
> A client that generates a very uneven load (e.g.
> doing big FFTs every Nth cycle) can easily make it indicate
> much more than the average CPU load. Of course clients doing
> that are just badly implemented, but they do exist.
Badly
On Fri, Mar 11, 2016 at 08:34:30AM -0500, Paul Davis wrote:
> On Fri, Mar 11, 2016 at 8:24 AM, Patrick Shirkey
> wrote:
>
> > Are we absolutely sure this is the case? That Jonathan has not found a
> > "bug" in JACK2 or the DSP load algorithm?
> >
>
> the dataflow
>Indeed -- except that cars in Manhattan are restricted to using wheels
>:-) I have rocket engines which don't give off exhaust at all, lots
>and lots of fuel, no skyscrapers in the way, and no one else in the
>air; I am going to either learn or help build a way to use those
>engines :-)
The
On Fri, Mar 11, 2016 at 12:23 PM, Len Ovens wrote:
> Assuming you are using the same set of outputs for all of your chains,you
> must be using some sort of mixer. I think I recall nonmixer. That
> application may be forcing sync opperation on all your other apps/plugins.
>
On Fri, 11 Mar 2016, Jonathan Brickman wrote:
No, I know very well that nothing in a single JACK system runs asynchronously.
The point is that if a single JACK system cannot be flexible enough to use most
of the computing power I have, because of the limitations of any synchronous
design,
On Fri, Mar 11, 2016 at 11:53 AM, Jonathan Brickman
wrote:
>
> the "engines" i'm referring to are your many multiple clients (19 or so).
>
> OK, I think I see what you are referring to: the switching nature of the
> client list, where the JACK server has to switch between.
the "engines" i'm referring to are your many multiple clients (19 or so).
OK, I think I see what you are referring to: the switching nature of the
client list, where the JACK server has to switch between. And this is
entirely why it helps to run multiple JACK servers on multiple
although it isn't proven yet .. i think that your problem may
come from the fact that you want to have 19 different engines,
and you keep flicking switches to go from one to the other.
Nope, I don't want to switch engines. Everything runs at once, and
runs very well by the
On Fri, Mar 11, 2016 at 11:00 AM, Jonathan Brickman
wrote:
> On 3/11/2016 9:57 AM, Paul Davis wrote:
>
>
> On Fri, Mar 11, 2016 at 10:48 AM, Jonathan Brickman <
> j...@ponderworthy.com> wrote:
>
>> Indeed -- except that cars in Manhattan are
On 3/11/2016 9:57 AM, Paul Davis wrote:
On Fri, Mar 11, 2016 at 10:48 AM, Jonathan Brickman
> wrote:
Indeed -- except that cars in Manhattan are restricted to using
wheels :-) I have rocket engines which don't give off exhaust at
On Fri, Mar 11, 2016 at 10:48 AM, Jonathan Brickman
wrote:
>
>
>
> Indeed -- except that cars in Manhattan are restricted to using wheels
> :-) I have rocket engines which don't give off exhaust at all, lots and
> lots of fuel, no skyscrapers in the way, and no one else
On 3/11/2016 7:41 AM, Robin Gareus wrote:
On 03/11/2016 02:24 PM, Patrick Shirkey wrote:
According to Jonathan his multiple cores are barely reaching 5% usage. How
can JACK_DSP be so high when there is so much room left to play with if
JACK2 is handling the parallelism correctly?
It seems
>On 03/11/2016 02:24 PM, Patrick Shirkey wrote:
>> According to Jonathan his multiple cores are barely reaching 5%
>> usage. How can JACK_DSP be so high when there is so much room left
>> to play with if JACK2 is handling the parallelism correctly?
>>
>> It seems similar to my car telling me
On 03/11/2016 02:24 PM, Patrick Shirkey wrote:
> According to Jonathan his multiple cores are barely reaching 5% usage. How
> can JACK_DSP be so high when there is so much room left to play with if
> JACK2 is handling the parallelism correctly?
>
> It seems similar to my car telling me that I am
On Fri, Mar 11, 2016 at 8:24 AM, Patrick Shirkey wrote:
>
>
> Are we absolutely sure this is the case? That Jonathan has not found a
> "bug" in JACK2 or the DSP load algorithm?
>
the dataflow algorithm doesn't have a lot of room for bugs. but sure, yes,
it is
On 03/11/2016 01:17 PM, Patrick Shirkey wrote:
> According to Jonathan's results he is finding a bottle neck with JACK DSP
> with a single server.
He reports that the bottleneck is his complete setup, I saw no evidence
that JACK is the bottleneck nor that the reason is the "single-server".
Maybe
On Fri, March 11, 2016 11:59 pm, Paul Davis wrote:
> On Fri, Mar 11, 2016 at 7:17 AM, Patrick Shirkey
> > wrote:
>
>>
>> On Fri, March 11, 2016 6:58 pm, Robin Gareus wrote:
>> > On 03/11/2016 08:03 AM, Patrick Shirkey wrote:
>> >> If this cannot be fixed in JACK
On Fri, Mar 11, 2016 at 7:17 AM, Patrick Shirkey wrote:
>
> On Fri, March 11, 2016 6:58 pm, Robin Gareus wrote:
> > On 03/11/2016 08:03 AM, Patrick Shirkey wrote:
> >> If this cannot be fixed in JACK directly we should be able to spin up
> >> multiple instances on
On Fri, March 11, 2016 6:58 pm, Robin Gareus wrote:
> On 03/11/2016 08:03 AM, Patrick Shirkey wrote:
>> If this cannot be fixed in JACK directly we should be able to spin up
>> multiple instances on the same machine and have them play nice with each
>> other.
>
> and how would that be different
21 matches
Mail list logo