11 Oct
2012
11 Oct
'12
2:43 a.m.
On Wed, Oct 10, 2012 at 8:33 PM, J. Liles <malnourite(a)gmail.com> wrote:
Agreed, but with autostart and jackdbus, I don't think many users are
having trouble with this aspect anymore.
actually, on IRC, jackdbus's d-bus elements seem to be responsible for
about 75% of all the user issues with JACK at this point (partly reflecting
jack2+dbus adoption by so many distro's)
Agreed. This is why I'm still confused why everyone
seems to shy away from
supporting multiple client per process >programs (like
Non-Mixer).
multiple clients per process doesn't get rid of all the logic needed for
SMP operation.
i'm working with a company at present that uses a design for their
processing model that works the way you and others have suggested
multi-client-per-process. they're a very, very well known audio software
company and i think it would be fair to say that in our discussions of
their model (discrete sets of processing elements grouped together for
parallel execution, with each group sequentially following others,
modelling a tracks->busses style of flow) that they came to see the
benefits of a dataflow model. i don't see how you can fit a dataflow model
into a multiclient system without things becoming incredibly complex.
i should note that AFAIK, jack1 at least will support
multi-client-per-process, and if it doesn't, even if i'm not a fan of the
design, i would consider a bug.