Re: [LAD] Is Linux audio moving forward - some very personal notes

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: J. Liles <malnourite@...>
Cc: Linux Audio Developers <linux-audio-dev@...>
Date: Thursday, October 11, 2012 - 12:43 am

--f46d04016d4b97cda004cbbddc31
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 10, 2012 at 8:33 PM, J. Liles wrote:

>

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.

--f46d04016d4b97cda004cbbddc31
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 10, 2012 at 8:33 PM, J. Lile=
s <malnourite@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-bu=
s 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 distr=
o's)

y away from supporting multiple client per process >programs (like Non-M=
ixer). 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-cli=
ent-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 execut=
ion, with each group sequentially following others, modelling a tracks->=
busses style of flow) that they came to see the benefits of a dataflow mode=
l. i don't see how you can fit a dataflow model into a multiclient syst=
em 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.

--f46d04016d4b97cda004cbbddc31--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] Is Linux audio moving forward - some very personal..., Jörn Nettingsmeier, (Fri Oct 12, 11:52 am)
Re: [LAD] Is Linux audio moving forward - some very personal..., Paul Davis, (Thu Oct 11, 12:43 am)