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

It (see subject) is a good question. In general my answer would be
'yes', but maybe not at the speed one could hope for.

The following is just from my perspective, which is 'minority',
'very specialised', or just 'irrelevant', take your choice.
That perspective is:

* Classical (including contemporary 'classical') music recording.
* Spatial audio reproduction, in particular Ambisonics.
* Acoustics research.
* Audio forensics.

I agree that is all quite different from the average musician's
POV, so you will be forgiven for considering it irrelevant.

In all of those fields Linux audio has served me well, and in
particular Ardour has been a very dependable and flexible tool
during the past five years or so. If I go back a bit more, it
is very clear that things have improved immensely. I remember
the second (IIRC) LAC where Paul demoed Jack and Ardour and had
to use pkill every two minutes. Things have really gone forward
since then, and by quite a distance. But that doesn't mean all
is honey.

The HW situation has been mentioned. Honestly, I wouldn't know
where to go if RME went away. Almost everything I've been doing
the last years has not only used their HW, but depended on it -
no alternatives. That *is* scary. Things being like that may not
be just a Linux problem.

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:

* It sould become a system level service, i.e. 'promiscuous'. I've
  been running modified versions like that for some time. It's a
  pain currently. Things will maybe improve once systemd becomes
  universal.

* It should have 'persistent' ports or the equivalent. That is, you
  can start an app, and tell Jack to remember it and its ports even
  after the app is terminated. The point here is that others can
  then connect to it even if it doesn't (yet) run. This would simplify
  things like session management quite a lot. But it also requires
  cooperation from the apps - one like Ardour that creates and removes
  ports with arbitrary names at any time doesn't fit well into such a
  scheme. The solution is to use Jack ports more like audio hardware
  uses its interfaces: ports are a fixed set (as would be e.g. an ADAT
  or MADI interface on a HW mixer), but are assignable to any function
  *within the app*. Any notion of logical function can still be carried
  as metadata of the port.

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

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
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
LV2 doesn't impose any quality standards, and doesn't care about its
reputation. It's just bad company.

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' before
anything happens. Which is more often that not just used to kill some
idea rather than towards any productive end.

-- 
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev