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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Fons Adriaensen <fons@...>
Cc: Linux Audio Developers <linux-audio-dev@...>
Date: Thursday, October 11, 2012 - 12:34 am

--f46d043c82201c5f9c04cbbdba3a
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 10, 2012 at 4:09 PM, Fons Adriaensen wrote:

> I agree with J. Liles that we should have the courage to review

I'm also open to something new/radical. But frankly I'd settle for
incremental improvements too. One can always deprecate a feature later if
it turns into a problem. But it's important to actually *try* these things
in the ecosystem so that people can see the difference between all these
theoretical problems they're so ready to imagine and what actually comes up
in practice. Right now JACK is the thing that connects all of this stuff
together, and IMHO, progress will blossom as the bandwidth and expressive
quality of this connection is increased.

> * It sould become a system level service, i.e. 'promiscuous'. I've

Agreed, but with autostart and jackdbus, I don't think many users are
having trouble with this aspect anymore.

>

Fixed port names has its advantages and disadvantages. For one, it imposes
another level of assignment/routing on the user (within the application).
When you look at something like a DAW, I don't think it makes much sense to
mangle all the ports into a fixed array of 32 channels or whatever. I
certainly don't see how having JACK attempt to remember the connections
would make session management easier.

> * All current hardware is SMP. If an audio app has a complex internal

Agreed. This is why I'm still confused why everyone seems to shy away from
supporting multiple client per process programs (like Non-Mixer).

The plugin situation is deplorable. Let's face it, 90% of the available

I think imposing quality standards is beyond the scope of a plugin API.
Many plugins used in non-classical mixes are intended to reduce fidelity,
not preserve it. I agree on the GUI, which is why I prefer the way DSSI
handles this (GUI is a separate process, can use whatever TK it wants).
Unfortunately, there are very few of us with the skill set required to make
non-crap plugins.

> Finally, and on a very personal level, you may have noticed that my

I've dealt with the same situation and feelings. I sat on the NSM prototype
long enough to see one or two other session managers come on the scene in
the meantime. I say release what you've done. You never know when you're
going to get hit by a bus. Someone will find a use for it and be grateful.

--f46d043c82201c5f9c04cbbdba3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 10, 2012 at 4:09 PM, Fons Adriae=
nsen <fons@linuxaudio.org> wrote:

I agree with J. Liles that we should have the courage to review
Jack. It has done a very good job, but (at least in my world) it
is showing its limits, and I'm not at al convinced that these can
be removed by 'incremental' improvements. Maybe we need something
new and incompatible, with two systems existing during a transition
period which could take several years. In particular:
I'm also open to something new/radical. But f=
rankly I'd settle for incremental improvements too. One can always depr=
ecate a feature later if it turns into a problem. But it's important to=
actually *try* these things in the ecosystem so that people can see the di=
fference between all these theoretical problems they're so ready to ima=
gine and what actually comes up in practice. Right now JACK is the thing th=
at connects all of this stuff together, and IMHO, progress will blossom as=
the bandwidth and expressive quality of this connection is increased.
=C2=A0
* It sould become a system level service, i.e. 'promiscuous'. I&#39=
;ve
=C2=A0 been running modified versions like that for some time. It's a
=C2=A0 pain currently. Things will maybe improve once systemd becomes
=C2=A0 universal.Agreed, but with autostart and j=
ackdbus, I don't think many users are having trouble with this aspect a=
nymore.=C2=A0

* It should have 'persistent' ports or the equivalent. That is, you=

=C2=A0 can start an app, and tell Jack to remember it and its ports even
=C2=A0 after the app is terminated. The point here is that others can
=C2=A0 then connect to it even if it doesn't (yet) run. This would simp=
lify
=C2=A0 things like session management quite a lot. But it also requires
=C2=A0 cooperation from the apps - one like Ardour that creates and removes=

=C2=A0 ports with arbitrary names at any time doesn't fit well into suc=
h a
=C2=A0 scheme. The solution is to use Jack ports more like audio hardware
=C2=A0 uses its interfaces: ports are a fixed set (as would be e.g. an ADAT=

=C2=A0 or MADI interface on a HW mixer), but are assignable to any function=

=C2=A0 *within the app*. Any notion of logical function can still be carrie=
d
=C2=A0 as metadata of the port.Fixed port names h=
as its advantages and disadvantages. For one, it imposes another level of a=
ssignment/routing on the user (within the application). When you look at so=
mething like a DAW, I don't think it makes much sense to mangle all the=
ports into a fixed array of 32 channels or whatever. I certainly don't=
see how having JACK attempt to remember the connections would make session=
management easier.

* All current hardware is SMP. If an audio app has a complex internal
=C2=A0 processing graph it will implement its own multithreaded scheduling<=
br>
=C2=A0 system for audio processing units (as Ardour 3 does). But it's s=
illy
=C2=A0 to repeat this in every app, and even more silly to schedule apps
=C2=A0 'per process', i.e. run them only if *all* of the internal g=
raph can
=C2=A0 run. This level of logic should move into Jack, or whatever replaces=

=C2=A0 it.Agreed. This is why I'm still confu=
sed why everyone seems to shy away from supporting multiple client per proc=
ess programs (like Non-Mixer).

The plugin situation is deplorable. Let's face it, 90% of the available=

ones just don't work, or work for some value of 'work' but are =
still crap.
LV2 has not delivered what was hoped for, IMHO as a result of focussing
on the wrong things. Given that things are what they are, any plugin
standard on Linux should have a documented and *stable* way to support
*any* X11 based GUI, including having a GUI embedded into an app, *and*
do that in a way that still works efficiently even if you have 100 plugins<=
br>
in an single app and 500 in your system. Focussing on the right things also=

means supporting developers who go for quality and are prepared for the
effort instead of trying to make things as easy a possible for beginners.
One of the reasons I'm not releasing anything as an LV2 plugin is that<=
br>
LV2 doesn't impose any quality standards, and doesn't care about it=
s
reputation. It's just bad company.I think imp=
osing quality standards is beyond the scope of a plugin API. Many plugins u=
sed in non-classical mixes are intended to reduce fidelity, not preserve it=
. I agree on the GUI, which is why I prefer the way DSSI handles this (GUI =
is a separate process, can use whatever TK it wants). Unfortunately, there =
are very few of us with the skill set required to make non-crap plugins. =
=C2=A0
=C2=A0
Finally, and on a very personal level, you may have noticed that my
output has decreased. But it hasn't. I've written more Linux audio =
SW
during the last years than at any time before. I'm just less inclined
to publish it. And I have been asking myself why that is so. One factor
may be that much of it is rather specialised. But that is in itself no
reason to keep it private, so that doesn't explain things. What has
certainly played a role is that fact that I'm tired of the mostly
useless discussions that arise whenever you propose something that
challenges the status quo, and the need to reach a 'consensus' befo=
re
anything happens. Which is more often that not just used to kill some
idea rather than towards any productive end.I&#39=
;ve dealt with the same situation and feelings. I sat on the NSM prototype =
long enough to see one or two other session managers come on the scene in t=
he meantime. I say release what you've done. You never know when you&#3=
9;re going to get hit by a bus. Someone will find a use for it and be grate=
ful.

--f46d043c82201c5f9c04cbbdba3a--

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..., J. Liles, (Thu Oct 11, 12:34 am)