Re: [LAD] So what do you think sucks about Linux audio ?

On Tue, 05 Feb 2013 09:58:14 -0500
Dave Phillips <dlphillips@email-addr-hidden> wrote:

> ...
>
> So, in your honest and bold opinion as user and/or developer, what do we
> lack most and what can we do without that we already have ? Please feel
> free to expand your remarks as you like. I'm planning an article on the
> topic and will likely use selected comments, subject to approval of course.

Too much fragmentation/too many standards to choose from. Plugin formats
for example. There is LADSPA which is all good and very useful for its
special niche, but it lacks the ability to create proper instruments
(as opposed to filters, for which it works fine). Also LADSPA has no
support for GUIs. Then there's DSSI which has support for instruments as
well as GUIs, but it lacks certain other things which other formats
such as VST have had for ages; one thing I was missing was the ability
to pass tempo information to the plugins. Then there's LV2 which is so
complex with all its "extensions" and Raptor and whatnot that as a
consequence, almost nobody supports it. I remember a discussion on the
Renoise board where the developers said that they would not support LV2
plugins specifically because it was so complex and it would pull in so
much bloat for so little expected gain. They chose to support DSSI
instead, with all its limitations. Then there's native Linux VSTs of
course. There are few, mostly because Steinberg can't be arsed to make
their API/SDK available in a way which makes painless open source
development possible (this is not the "fault" of Linux audio of
course!). Then MIDI: There's ALSA Midi which most programs use, and
Jack has its *own* implementation which is incompatible with ALSA,
which means that ALSA Midi programs can't talk to Jack Midi programs
and vice versa. (Yes, there are "bridge" applications and stuff, I
know...)

Same thing for session management. The way JACK is built asks for
modular connection of apps, but there's just no way you can reproduce
that song reliably once you have it all setup. There's LASH, at least
one other session management, I forgot its name, and recently JACK
began to grow its own session management extension (only available in
Jack2, but not in Jack1, right?)... For the best chance of good
compatibility, an app would have to support ALL those session
management interfaces. Many don't even support one.

Then JACK is great for what it does, but it really is a pain. It's hard
to setup, and sometimes it and its tools are just plain buggy. At the
sublab (local hackerspace) we tried setting up a moderately low-latency
audio server which networked computers could talk to using Jack. I
remember night-long debugging and setup sessions for that. Once,
everything seemed to be running alright but there was no output. We
found that the jack.plumbing tool had been crashing instantly after
starting for some reason for a while, so connections weren't restored.
I think that was fixed when we switched to Jack2. NetJack apparently
doesn't work when the clients are across a router; it has something to
do with the TTL of network packets which are used to discover the
server. I wrote a patch for it, but we would have to patch the "server"
machine (which isn't called the server in Jack terminology I think) and
all the clients who would be using it, plus configure the router to
forward the packets. Of course, we also want to just stream music at
times, for which Jack is overkill (and not all music apps support/not
all users want Jack), so we have to support PulseAudio too. We now have
PulseAudio running on top of Jack2 which is sorta stable but it took
ages. Jack2 seems to be more stable than Jack1, and the network support
is better IMHO.

I'm a professional software developer and I sometimes also do some
server configuration stuff and the like, but even for me, Linux audio
is often just too complicated to be fun. Especially when I'm in a
"musical mood", I don't want to think about port forwarding,
segmentation violations, problems with session management interfaces,
bugs in low-latency kernels, crashing Wine plugin bridges which worked
last week before the automatic update ran, and stuff like that. When I'm
trying to do music, I want to think about *music* and about using
technology in creative ways for making music, not staring at stack
traces.

And I think this is a problem that will not be fixed by creating some
wrapper script with a nice colorful GUI or even creating one more distro
with a realtime kernel and audio-specific default settings. Usability is
something that has to be thought about and built into the core
interfaces and programs such as Jack from the beginning.

This became something of a rant, sorry... I don't mean to be rude,
there is great potential in Linux audio, great stuff has been done by
many people in the last years, and I would never switch to Windows or
buy an Apple so I could use "The Audio App" (Live) like most everybody
else. But sometimes I think the huge great efforts made by Linux audio
people could be better coordinated to yield more, faster progress.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Feb 5 20:15:04 2013