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

On 10/12/2007, Sebastian Tschöpel <tschoseb(a)tu-cottbus.de> wrote: 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(a)gmail.com