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."
Audio support is fine. Music making support OTOH is abysmal. The article correctly points out that sound recording, editing and mixing is fine on Linux. The heavyweight music creation tools just don't exist and many of the top-end hardware interfaces simply don't have Linux drivers.
Squirrel!
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
I've been using this for quite some time now. anyone else?
Warning, the above comment may contain sarcasm. Don't say I didn't warn you.
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.
Seems like some enterprising individual could start putting together cheaper-than-dirt Ubuntu-based music machines by buying Dell Studio laptops (with Microsoft license rebate, naturally) and preloading everything necessary.
The complaint from non-geeks about Linux is you have to do it yourself. If you didn't have to do it yourself, and it really was that cheap, it becomes a lot more interesting.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Kim mentions the use of free audio production software, such as Audacity, as substitutes for commercial offerings. While an Audacity user is more than welcome to dive into the code base and make needed improvements, not every user has the time and/or ability to do such. In my estimation, neither Audacity 1.3.7 nor Audacity 1.2.6 are stable enough to be considered "professional-quality" software. I am not trying to insult the developers and their abilities -- they have a complex project on their hands. But Audacity's graphical interface has serious and repeatable bugs; Audacity's sound export facilities reliably adds spurious noise to sound. I admire Kim's decision to use Ubuntu as an audio workstation, but I don't think Kim has been forthcoming about sacrifices in software quality that a user must make to do so. Kim can easily translate most audio programming done in Max/MSP (the commercial environment he has worked with extensively) to the public domain environment "pd" -- but as an experienced user of both systems there are more functionality loses than gains moving from the commercial Max/MSP/Jitter environment to pd (Pure Data).
If the cost of an Apple system and the higher cost of outfitting it with professional quality audio production and performance software are bankrupting a musician, then I can see the logic of using an Ubuntu system at this time. Otherwise, I still believe the adage "you get what you pay for" applies. However, I believe with effort from open source audio developers an Ubuntu audio workstation with both cost and quality advantages is more than possible. The bugs I am seeing in Audacity today remind me of the bugs I saw in the comparable commercial application "Peak" ten years ago.
I wonder how the vendors are going to support another OS when they can't even get their stuff working properly with different hardware configurations on TWO operating systems (Windows/OS X). I can't tell you how many problems I've had with FireWire audio interfaces.
Once this hurdle has been reached, I am all for whatever open source audio stuff comes my way. I use currently Audacity for editing samples and quick n' dirty recording. Audacity WORKS but it's interface is mediocre at best and if you want ASIO support you have to download an unsupported patch to get it.
...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
Half the time it's the chipset manufacturer's fault, too. For example, Realtek pretends to support Linux and even has public datasheets (to some extent), but some of their chips only half-work or don't work at all if you stick to the published specifications. Turns out you need to perform some magical undocumented actions to get them to behave correctly. Don't bother asking their "linux guy" (he's even listed at the top of the driver in the Linux kernel), he'll just waste your time.
I had an issue with their ALC889 chipset, which I described to him in technical detail (such and such portions of the chip don't work, even when there's no way this could happen going by the spec, which I can prove because I've tested this and this). He wasted two weeks of my time throwing random revisions of the driver .c file at me that just added pin-configuration support for other motherboards and laptops (none of which were my laptop, and which is totally irrelevant to the issue as I described it, as I know how to test and determine the platform-specific pinouts and had already nailed mine). Eventually I gave up and manually brute-forced every single bit of their proprietary registers until I came up with the magic ones to make the chip behave.
Problems getting *any* sound to come out are quite often the result of proprietary platforms and chipsets with poor support. Software issues with mixing and incompatibilities with applications are an entirely different issue - those can indeed be attributed to the rather crazy state of linux audio.
Interesting point.
In the early days of Windows audio, people found that their gaming graphics card was grabbing the PCI bus for incredibly long stretches at a time, as a side effect of the graphics card driver trying to max out performance and show great benchmark results. This would totally mess up any audio latency.
I wonder if the linux graphics drivers are doing similar games, causing all sorts of latency hiccups?
(As I'm typing this on a windows box the hard drive is causing seconds long delays as I try to type this!)
Linux audio is definitely not yet what it should be..
Bavarian Purity Law of Rice Krispie Squares: Rice Krispies, Marshmallows, Butter, Vanilla.
Never mind a plan, some sort of agreed specification would be wonderful! (And, no, a bunch of vendors locked away with OSDL or some other tiny group isn't any way to come up with a specification.)
I'd argue that JACK is probably the most Unix-like in passing data from A to B, where all components are special-purpose. I'd also argue that it's the closest to a true audio plugin system of any system out there for Linux. Thus, any specification would logically be derived from the JACK experience.
Why only the experience? Because JACK is linear, but audio processing may want more complex flows. There's a very nice package that lets you build up a synthesizer by running leads from modules to other modules, allowing you to split and merge the signal as you like. That would obviously be superior to single pipe in, single pipe out.
Another problem is that you want audio to be hard real-time, and only the kernel is currently capable of being hard real-time. The user space can only do soft real-time. But flipping between user space and kernel space adds enormous latency for each switch-over. It wouldn't take a long pipe to kill the audio entirely.
Thus, either real-time needs to make it to user space, OR there needs to be an ambivalent layer that is neither strictly kernel nor user, where you can have hard real-time without the horrible overheads.
At this time, neither option seems likely to happen, but until it does true HQ studio audio won't be possible in Linux. It'll come damn close, but it'll never reach the point hardcore professionals would take it on.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I wish the article's server hadn't been slashdotted, because I would love to know which professional digital audio adapter he's using, where he got the drivers, and whether he uses jack or not.
Every time a new Ubuntu studio comes out, I install it on a PC workstation in my studio to see if finally I can use Linux for digital music production, and every time I am disappointed by the way Linux talks to my audio gear. In Windows, I can use ASIO or WDM drivers and get professional-quality results, low latency, etc in Reaper. Apple uses SoundDriver for Logic. But Linux? All I've been able to find is jack, and for a professional, it doesn't do jack. There always seems to be problems with my MIDI gear, too, but that's gotten better in the past year.
Still, Reaper, using its ReMote technology allows me to offload certain things on to a Linux box via ethernet, such as rendering and effects processing, and that's a huge help, allowing me to use more real-time effects on more tracks. And, of course, my Linux box is absolutely key for streaming samples and other stored data to my digital audio workstation.
But using Linux as a main machine for music production? Not yet as of February. I plan on reading this article, though, as soon as you slashdotters give the server a breather, to find out what this guy's doing. Maybe it's finally time. I may not yet be ready to give up my Mac Pro and custom-built windows workstation for music production yet, but I look forward to being able to use Linux on a music project, start-to-finish.
You are welcome on my lawn.
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
I just finished recording and producing a jazz album using Project CCRMA hosted on Fedora. The recording through to the final mastering were all done using linux. Having read his article I was surprised to find he hadn't mastered his production using Jamin which, when used in combination with Ardour and Jack, gives the type of control over the production process I've not seen duplicated using a Mac (Windows is not capable at all in this regard). I suppose though that is the workflow he is used to.
The innovation is what it means to the production process. There is no mixdown to a 24bit 44.1Khz stereo track prior to mastering and you can render your tracks through the mastering software into the final tracks and tweak automation artifacts instead of compromising by using equalisation. Sure you still equalise but you end up doing less as you can refer back to the master if there is a problem and fix it there. Plus you have better control over (audio gain) compression to reduce transients and maintain dynamic range in the final product.
The bands that listen to my recording are amazed at the results (well my recording techniques *ahem* do play some part :-) and some asked me if it was done on analogue equipment - which is quite a compliment. The thing is sure, it's not perfect and sometimes frustrating because the your hardware is often pushed to it's limit, you find bugs you have to adjust your work flow around but simply put I don't think the capability *exists* anywhere else.
I've been using it since 2003 and have seen the foundation laid down by Alsa and Jack projects continually refined. Often the criticism is made that 'linux copies this or that' but after comparing it to existing processes it seems to me that audio production under Linux is on the leading edge of technology as the framework for innovation in music production.
My ism, it's full of beliefs.
ReNoise is clever, and fun, but not a pro tracker. If I'm going to have to use Wine, why wouldn't I just use the operating system that those apps work in natively?
I'm not sure how you can compare ALSA with ASIO. I don't know all the under the hood stuff, but I have never had a problem with ASIO. I've never had to fiddle to get it working, and the performance is terrific. I go back to the days when I'd have to shift entire tracks to the left after recording just to line up the beats. I don't have to do that any more, thanks to technologies like ASIO, WDM, etc.
I use RME hardware since the Hammerfall v1.0, and whenever I've tried Ubuntu, it's always been with RME hardware. Mostly because there just aren't any drivers for most of my other audio hardware. I've got an old MOTU box around here somewhere, adn I've heard that they've released Linux drivers, too. I know there's no drivers for my Apogee gear.
Finally, as you know, when you're using a digital audio workstation, the main app is key. Programs like Logic, Digital Performer, Pro Tools, Sonar, and the others are much more than just "trackers". They're multi-track digital recorders, mixing matrices, virtual instrument platforms, digital audio editors, mastering suites and more, besides being "trackers". I am encouraged by Cockos' Reaper and their very decent port to Linux, but beyond that, there simply isn't a professional-quality application available that runs natively in Linux. Did I mention effects? I've got a palette of effects, virtual instruments and more that use Steinberg's VST or DirectX or Apple's AudioUnits. Without those, I'm hamstrung. I bet there's a way to use wine for VST or maybe even DirectX, and someday when I have lots of free time, I might decide that taking the time to learn to use those effects and VIs in Wine instead of the OS for which they were written is time well spent. I have to balance the desire to see Linux become a useful platform for soup to nuts music production with the desire to be productive right now. Life is short, unfortunately, and inspiration is fleeting, by its nature.
I am constantly writing letters of encouragement to both audio hardware and software manufacturers trying to get them to port their products to Linux. I guess enough time has passed since my last attempt with Ubuntu Studio that I ought to give it another go. I want it to work. I'll make sure to read the article on your server before I get started. Thanks for working hard to get it back up after what must have been a deluge of Slashdot readers.
You are welcome on my lawn.
OSS has been dead for over a decade. It can't cope with multi-channel sound cards properly because it tries to treat *everything* as a stereo pair. It's got a fairly awful API, too - how did they manage to make it overcomplicated *and* too simple to be useful at the same time?
I think you might be referring to the deprecated OSS version that had been included in the Linux kernel. There is a much newer version which is argued by some to be better than ALSA in both its API and performance.