Slashdot Mirror
Goodbye Apple, Hello Music Production On Ubuntu
Adam Wrzeski notes a piece up at Create Digital Music by musician Kim Cascone (artist's bio) on switching from Apple to Linux for audio production: "The [Apple] computer functioned as both sound design studio and stage instrument. I worked this way for ten years, faithfully following the upgrade path set forth by Apple and the various developers of the software I used. Continually upgrading required a substantial financial commitment on my part. ... I loaded up my Dell with a selection of Linux audio applications and brought it with me on tour as an emergency backup to my tottering PowerBook. The Mini 9 could play back four tracks of 24-bit/96 kHz audio with effects — not bad for a netbook. The solution to my financial constraint became clear, and I bought a refurbished Dell Studio 15, installed Ubuntu on it, and set it up for sound production and business administration. The total cost was around $600 for the laptop plus a donation to a software developer — a far cry from the $3000 price tag and weeks of my time it would have cost me to stay locked-in to Apple. After a couple of months of solid use, I have had no problems with my laptop or Ubuntu. Both have performed flawlessly, remaining stable and reliable."
I agree with the premise of this article: Linux is a perfectly good platform for digital audio creation and editing. It might even be better than a Mac, depending on how you weigh different pros and cons. But I unfortunately don't really feel I learned much from this article about why Linux is a good choice. All the apps he mentioned (Audacity, Ardour, etc.) are available for both platforms. And his reasons for switching, like the lack of a tree view in the OS X finder, strike me as weirdly trivial and not music related.
As someone who's done some published research on audio latency/jitter issues in a former life, I'm also somewhat annoyed by how much these sorts of articles focus on tech like JACK and low-latency kernel patches. This used to be a huge issue, but I suspect it shouldn't be nearly as high up anyone's priority list as it used to be--- back in the 2.4.x. series kernels, when the default kernel's clock tick used 10ms granularity and scheduling was flaky, it made a much bigger difference. Today, I suspect this sort of behind-the-scenes performance is only infrequently the bottleneck in anyone's audio performance; when I see actual glitches in performances, they can often be fixed by much more boring scheduling tweaks like "nice -19" on the processes that are bottlenecks in the audio path, or finding bugs in how you're setting up your callbacks.
In any case, these days I see JACK as useful mainly for being a reasonably well supported audio-app-interconnection bus; as he says, the Core Audio of the Linux world. But that doesn't make it hugely unique either.
So I guess I'm in the weird position where I agree with the article's conclusions, and some of its specific points, but overall if I didn't already agree with it, this article wouldn't have sold me on why Linux is great for audio editing. Sorry. :/
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Having spent the last 6 hours writing music using a softsynth on linux (we're doing a 64k entry for the demoscene, on linux, so we have no choice), I have to say, in spite of the pre-emptive kernel, there need to be some serious kernel changes before it can stand up to the low latency requirements of music production.
My synth will happily plod away in interactive mode using about 30% cpu on windows (there's reasons why I can't just boot into windows and run it), and yet it munches about 40% whilst idle in its VST host on linux, and regularly spazzes out at 100% of the interrupt time given to it, requiring me to hit the panic button. That's with the pre-emptive kernel and realtime-everything switched on. All of this whilst "top" is showing that it's actually only using 30% of the total cpu time. It won't just ramp up to use the entire cpu. On the standard kernel, it's, erm.. well.
The problem appears to be the way in which the different applications are talking to eachother through processes which depend on eachother's data streams, but don't get called NOW when you need it. The previous version of my synth was a basic jack midi device, and that was even worse. Timing bugs all over the place. Occasionally it would miss entire notes.
Then again, if ubuntu are taking this seriously, hopefully we can see linux improve in this respect soon.
Either that, or I'm off to buy a quad-core xeon.
I wrote my first program at the age of six, and I still can't work out how this website works.
...it's actually only using 30% of the total cpu time. It won't just ramp up to use the entire cpu.
It may actually be using the entire CPU, but not reporting it via "top".
Unless I'm mistaken, CPU used by the back-end IO processing - the act of the CPU coordinating traffic between the computer's bus and the devices that are being written to and from, are not actually charged to the process or thread.
That is, the details of how much CPU are used by the IO system aren't written to the process header, because the process header isn't in the computable scope (an area defined by a set of active register values). Ergo, "top" doesn't report that CPU because it isn't there. (Old VMS systems had a parameter that simulated this, called "Iota" (measured in microfortnights, oddly enough) that was added in back when charging for CPU usage was in vogue.)
What that seems to indicate is that the problem may not be in the operating system per se, but in the driver and/or the device. The culture of one IO per byte may still exist in some buried (or should be buried) hardware devices. The IO needs to be blocked up a bit I think to get the performance you need for seamless music delivery.
Do not mock my vision of impractical footwear
Many people have problems with sound in Linux. The situation is certainly less than ideal. However, on most computers, sound in Linux works flawlessly. If you have problem with sound in Linux, you are part of the exception, rather than the rule.
That depends on how you define "works." I agree that most people who install something like Ubuntu will get sound working without fuss. My main beefs with audio on Linux are with some terrible design decisions along the entire sound stack. For example, ALSA (ditching OSS completely) was a bad idea. PulseAudio is a good idea for some (very few) specific situations, but it doesn't belong as the fixture it has been made by several of the common distributions. It solves problems nobody knew they had only to introduce other important problems (i.e. latency).
I'm not discouraged at all by the audio situation on Linux. Like you said, it mostly works (setting aside audio production concerns). There are a lot of problems, though, and the best solutions may require some hurt egos. That's always a tough thing.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
Reaper actually *officialy* supports WINE. From http://www.reaper.fm/download.php : "Windows (32-bit): Windows 98/ME/2000/XP/Vista/7 or WINE (limited support for W98/ME)."
Me and U(buntu) - my blog about Ubun