[LAU] A year of Linux Audio revisited - would like to know your oppinion

[Robert Persson]

On 10/12/2007, Sebastian Tschöpel <tschoseb at tu-cottbus.de> wrote:
>
>
> The result is a small midterm-report and I would be glad to hear some of
> your thoughts.
> Not about the article itself but about the questions I had before I
> started to use Linux as
> audio production base, about the answers you might have found and about
> your personal Likes and Dislikes.
>
> Linux audio has certainly come a long way in the last year, but there are
certain problems that are very frustrating and other limitations that make
it fall completely flat on its face.

Although I have tinkered with it for a while, it is only recently that it
has actually become a viable audio platform for me. The two key factors are
wineasio and the continued improvements in the Windows DAW Reaper. This
means that I no longer have to waste so much time fighting with technology.
In fact it came just in time. I was on the point of giving up on Linux for
audio and was only prevented from doing so by my Windows 2000 installation
committing suicide—it stopped being able to recognise the disk geometry
properly, much as, about 3 years ago, Windows XP 3 times in 2 weeks which,
strangely enough, happened also to be the last two weeks that I voluntarily
used Windows, but I digress.

Like with any mainstream commercial DAW, you can start up Reaper and carry
on working where you left off. This is an absolute essential for
conventional multitrack recording. LASH is supposed to do this, but even if
I could work out what on earth I am supposed to do with it (a documentation
problem at the very least), it isn't yet supported by enough audio
applications to make it useful. Proper and comprehensive session management
is an absolute must.

Rosegarden is a very useful tool in certain circumstances. It could be
brilliant in a school music class (I'm sure there's someone out there who's
already using it in this way), and I myself use it for teaching myself
formal compostional techniques through score writing, but it just doesn't
cut it as a DAW. For instance if there is a way to create volume envelopes
for midi tracks, I have yet to find it. Another problem is that I can't
transpose the midi input so I have to route midi through qmidiroute, which
always takes a minute to set up. Add up all these little and not so little
problems and you start to find that you have a big problem.

None of the sequencers for Linux have groove quantise. Admittedly Reaper
doesn't have it yet either, but it looks like it should turn up in the not
too distant future. For the time being I can do without by concentrating on
recording those of my songs that don't need it, or by doing something
convoluted like opening midi files in some other windows program like style
enhancer, twiddling with them, and importing them back into whatever, but
eventually I will need to use it a lot more. And if Reaper doesn't deliver
soon enough then I will have to switch to OS X that does the job. What
really concerns me as far as open source apps are concerned is that I see no
sign of anyone considering this to be an important issue. If you want to
process a particular audio track in a way that is beyond the capabilities of
your DAW you can do this at any time, but if your timing is not the way you
want it you are stuffed right from square one.

For instance FL Studio exists for no other purpose than to help people
create grooves. Groove quantise is therefore one of its most important
features. Therefore it just isn't true that LMMS can do the kind of job that
FL Studio can do, yet it seems that many people in the Linux audio world
think that it is. There is a lot of this kind of over-optimism within the
Linux audio world and this is dangerous because it can lead to complacency.
Developers need to face up to the stringent demands of their target users
and do their best to meet them. wineasio does this, as does jost, as does
zynaddsubfx. Rosegarden is nothing like Cubase and there is nothing to be
gained by pretending that it is. MuSE is a great project and it has achieved
a lot, but I don't think it is being disrespectful to the developers to say
that it still has a fair way to go yet.

Jack is another area of concern for me. People say a lot of good things
about it, and I have a lot of good things to say about it as well, but it
has some serious problems that don't seem to get mentioned very much.
Basically it is way too fascist. A client that doesn't return its data fast
enough and it is booted off. This usually means that you have to terminate
the client and start again, in which case you will also need to patch it
again. At best you have to manually restart the jack engine the way you can
with hydrogen. And if you hibernate your machine then you have to restart
all your clients—I don't know what happens when you suspend to ram because
suspend to ram doesn't work on my box, as it doesn't on a lot of linux
systems. Given the lack of adequate session management, this causes a lot of
irritation and wastes a lot of time. And sometimes I find that a lot of
distortion creeps into the jack signal and it doesn't go away until I
actually kill some clients. You don't get any of this kind of stuff with
coreaudio; you just don't have to think about it. One of two things needs to
change. Either jack must become more forgiving or client applications must
automatically reestablish their own connection with jack and their routing
to other clients.

On the other hand jack does offer possibilities for routing that exceed
those of any of its competitors, such as rewire or rearoute. What with
wineasio, jackosx, netjack and jackdmp, it should soon be possible to
connect pretty well anything to anything. That is a great achievement. It
means that you can sit in the kitchen area of your supremely elegant loft in
your black polo neck drinking something from your personal espresso machine
and doing stuff on your spanking new macbook. This means that you won't
damage your reputation with all your beautiful and sophisticated
art-mag-reading, non nerdy friends even though, unknown to them, you are
actually farming out a lot of the really heavy dsp to a stack of cheap linux
boxes hidden in the airing cupboard. Apart from implementing netjack in
jackdmp, the last set of hurdles I can see as far as all this goes is
getting jack transport to play nicely with MMC, MTC and coreaudio transport.


Hydrogen is really looking very good, but it is lacking in the midi sync
department, it slows down rather than stuttering when it is overloaded,
which is not good when you need it to keep in sync with something else, and
you can't yet gate your hi-hats. And of course it also lacks groove
quantise.

As far as distros go, I tried to work with ubuntu studio, but I ran into too
many limitations. I got way too many xruns was poor and I found myself
having to compile a lot of audio stuff myself for one reason or another. In
the end I decided to keep the Ubuntu installation for normal work and to
create a separate gentoo installation for the audio stuff. This is now
working well, but it was quite a lengthy, difficult and frustrating process
setting it up. I am aware that there are a lot of music-oriented
distributions out there that I haven't tried, but from what I read, it looks
like they all have their limitations. Again, a good deal of progress has
been made this year, but there is still a lot to be done.

There are also some outstanding driver issues. For instance many functions
are not accessible on my audigy2 card. Perhaps this is not in itself too
important because you'll definitely need to get something more appropriate
if you seriously get into professional recording, but it's important for
people like me who can't yet afford something more specialised. More
generally, the fact that a widely used soundcard is not supported properly
puts a big question mark over whether some more obscure piece of hardware is
supported. This kind of thing causes FUD in potential users.

I should probably let someone else get a word in now.

Robert
-- 
Robert Persson
ireneshusband at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20071210/1f3900a1/attachment.htm