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)