An Arch Tale
Dave needs a new 64-bit Linux for his primary audio production machine. What shall he do ? Read on to learn how and why he decided upon the Arch Linux distribution.
Why Switch ?
For about four years I've been running the excellent 64 Studio Linux distribution on my main machine here at Studio Dave. That machine - affectionately known as Big Black, thanks to the color of its Antec Sonata II case - houses an AMD64 3200 CPU, a single-core 64-bit processor that runs at 2 Ghz. It also contains 4GB RAM and a 320GB hard drive. Video is handled by an nVidia GeForce 7600 GS chipset with 512 MB video RAM, and the box's sound hardware includes an M-Audio Delta 66 digital audio interface system along with the motherboard's integrated HDA_Intel chipset. The Delta 66 is used for all serious recording on the machine, while the mobo's chipset handles audio playback for my CDs and DVDs. Altogether, a decent box, not especially up-to-date but quite sufficient for my purposes. Those purposes include various functions for my teaching business (printing lyrics, tablatures, chord charts, et cetera), most of my music composition, and the forementioned recording activities. I also use the machine for almost all my professional writing (with vi/vim, of course).
Big Black is the only machine in my studio running a pure 64-bit operating system. 64 Studio is based on Debian, with a rock-steady realtime kernel, but alas, the box has begun to show its age. That kernel is very old - version 2.6.21, ancient by today's standards - and the system's components can't keep up with the modern trends. YouTube complains that my version of Firefox is too old, I can't compile Ardour3 and other contemporary applications, but by far the worst condition is the system's failure to run the latest and greatest release of Jean-Pierre Lemoine's AVSynthesis. AVSynthesis is my preferred environment for sound and graphics composition, and for years it's been humming along nicely with 64 Studio's help. However, all things change, and indeed the requirements for AVSynthesis have recently been upgraded to the latest versions of Csound and JOGL (a Java/OpenGL combo). The Csound part is no problem - it still compiles cleanly on 64 Studio - but the latest JOGL2 has trouble with dependencies that can't be met easily or at all by the system. Given the frequency with which I work on AVSynthesis, the message was clear - I had to upgrade Big Black's operating system or risk falling behind while AVSynthesis continues to develop greater power and capabilities. So, I drove out to the local Staples, bought an on-sale 1T Seagate SATA drive, and installed it in Big Black to accommodate my new yet-to-be-selected 64-bit system.
In brief, any replacement for 64 Studio would need to be capable of handling a blend of OpenGL 3D animation and high-quality realtime audio output, without perceptible delays in either the graphics or audio performance. With this base criteria in mind I began looking at modern 64-bit Linux distributions. I'm already running a 32-bit Ubuntu system on my secondary machine, and I wanted to try a different Linux distro flavor. In the end I decided to install Arch Linux.
Why Arch ?
I'll admit that at first I was not especially eager to install an Arch system. I've happily put behind me my days of compiling system components, including kernels and graphics subsystems, and I've enjoyed the ease with which I've been able to install modern distributions such as Fedora and Ubuntu. In fact, I first installed Fedora 14 as the replacement system, and I'm pleased to report that it installed and configured itself without incident. Alas, I ran into considerable difficulty when I tried to install the latest nVidia driver for my graphics card, and in the end I decided the attempt wasn't worth the amount of time I was spending on it. Please bear in mind that my experience is no reflection on Fedora - I was trying to install a closed-source proprietary binary on an open-source operating system with a custom realtime kernel, a formula for problems if ever there was one - and I would have been happy with the system if its defaults satisifed my criteria. Unfortunately, the Nouveau video driver is not yet up to the task of the accelerated 3D I require, and it turns out that replacing the driver was a non-trivial task. Eventually I gave up on Fedora and turned to the members of the Linux Audio Users mail-list to find out what they chose for their 64-bit solutions. After considering their replies I decided to take the plunge into Arch.
Some descriptions of Arch include a disclaimer/warning to the effect that the system is not a beginner's Linux. I'm not so sure about that assessment - I was a complete Linux/UNIX novice when I installed Slackware in the mid-1990s, yet I was able to install and configure that system successfully in one afternoon, thanks mainly to its excellent documentation. As soon as I began my Arch journey I discovered a similar scenario. The instructions for installing the system are quite complete, and plenty of additional information is available on the net. Yes, there's no doubt that previous experience is a great help when installing Arch, but I believe that any reasonably thoughtful user can do it too (even without previous experience installing Slackware :).
Allow me to dispel one myth about Arch - you won't be required to compile anything you don't want to compile. When the installer informs you that you have to manually install the X window system, have no fear, it's a simple 1-or-2-click operation. In truth, installation isn't really much of a problematic area for newbies. The system configuration details pose the greater difficulty.
I won't detail here how Arch is installed, you can find all the information you need for that process on the Arch site. This article describes how I set up my system for use with AVSynthesis and its more general use as a replacement for 64 Studio. As is my usual way, I'll skip to the spoiler and tell my readers that I'm well-pleased with my new system and that I would not hesitate to recommend it for serious audio production.
The Tao Of Arch
The Arch Way is not exactly a return to the thrilling days of yesteryear's Linux installations. As I said, you won't have to compile much of anything you don't want to compile. You're welcome to build everything for yourself, but typically you'll want to employ the pacman package management system and simply download your needed binary packages. The official Arch software repositories include many standard components for setting up an audio-centric workstation, but you'll want to look into the AUR - that's the Arch User Repository - for other needed parts. A download from the AUR is not usually a package per se - it includes a script called a PKGBUILD that will automatically retrieve, build, and install your selection. PKGBUILDs are not officially supported by Arch, and the user must assume all risks, but the impression I've received so far indicates that bad packages won't last long in the community. In fact, if I understand the process correctly, a successful and popular PKGBUILD may pave the way for the package's eventual inclusion in the official repos.
As mentioned, for the novice perhaps the most disconcerting aspect of Arch is its dependence on the user's input for basic system configuration. And not just for novices, as I learned recently when I wondered why my printer connection disappeared a day after I had successfully installed and configured it for the system. Worse, I couldn't access the CUPS admin page from Firefox. After some vigorous head-scratching and a Google search I realized that I had failed to add the CUPS daemon to the list of daemons loaded during the system start-up. It's an easy fix - I added cupsd to the DAEMONS list in /etc/rc.conf, the main configuration file for Arch - but it's a bit nerve-wracking when you're accustomed to more hand-holding from a Linux distro.
Of course, the benefit from this user-centric configuration is the ability for said user to build his or her own highly-customized system. You can strip it down to a nubbin or beef it up to a fat cow of a system, it's your choice. In point of fact, it's truly your choice - the default installation is quite bare-boned and likely unusable by anyone without experience at the Linux command-line interface. However, I must again compliment the Arch community for the excellent documentation. The basic system installation instructions are thorough and clear, and to be honest, I simply had a lot of fun installing Arch. Technically, I felt that I was somewhere between that first Slackware installation and a Debian installer. I kept a Web browser open on my laptop for reference when I was uncertain about my options, but I rarely consulted it. Also, I ran through the entire installation process a couple of times before making my final decisions, a recommended practice if you have sufficient time and patience.
In my humble opinion, if you have zero knowledge of the Linux boot and system configuration procedures, or if the essential difference between /dev/sda and /dev/sdb is dark matter to you, then it's doubtful you'll feel very comfortable mucking about with those weirdly-named files in the /etc directory. On the other hand, if you're the kind of person who doesn't mind tinkering with and learning about your system's lower levels - better yet, if you already know how all that works - then you'll love setting up Arch.
Studio Dave, Studio Arch
Regarding my own Arch system (Figure 1), I'm afraid the gist of the story is something of an anti-climax. The only problems I've encountered have been troubles with system settings such as the printer configuration described above, with similar solutions (i.e. edit configuration files in /etc). I've installed development environments capable enough to build Ardour3 (GTK2), AVSynthesis (Java/Eclipse), Csound 5.13 (C/C++, Java, Python),and SuperCollider 3.5 (Qt), but I haven't been shy about using pacman. Up-to-date versions of QJackCtl, QSynth, JACK-Rack, Audacity, and mhWaveEdit are all here too, thanks to the repositories and Arch's "rolling release" policy of updates.
I've been happily surprised by the performance of the default kernel. Here's what uname -rvm reports :
3.0-ARCH #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 x86_64
I wasn't sure about that kernel version, so I ran pacman -Q linux and received this reply :
So there you have it. My Arch system is running around a 3.0 Linux kernel built with the PREEMPT options, from which I get reliable 5.33 ms latency with JACK at 48 kHz when using Ardour3 or AVSynthesis. I haven't tested the system with severity, but the performance so far is remarkable for a non-realtime-patched kernel. I'll continue to monitor that performance, and I may yet decide to install a realtime-patched kernel.
Oh, about that nVidia driver: I downloaded the latest package from nVidia's site, set up Arch to boot to the command prompt, built and installed the driver with no problems, and rebooted into my new Arch system displayed with nVidia's latest driver. AVSynthesis is happy, and so am I. End of Dave's nVidia story.
A Wee Testimonial
As I write this article I've been running my Arch system for about a week. I've had some expected difficulties with a few applications, but I've experienced no system crashes. The stock kernel handles the demands of AVSynthesis without troubles (i.e. few or no xruns), though I continue to keep a close watch on QJackCtl's reports. I've migrated and updated all my familiar applications from 64 Studio, including a few that weren't able to run at all on the older system (e.g. a 64-bit build of DOSemu). My menus are completely customized with single-click launchers for all my familiar apps, and the overall impression is that this is one fast system. I've made only subjective comparisons, but Arch seems to perform as well as my trusty 64 Studio, and that's with a non-realtime versus a realtime kernel. Xfce4 feels less like a desktop such as Gnome or KDE and more like a lighweight window manager a la Fluxbox. It stays out of the way, is easy to use, and is very easy to customize.
Could I set up Fedora or Ubuntu with a similar outcome ? To some extent, I've already done it. My Ubuntu systems are highly customized, but they are not as current as my Arch installation. My 64 Studio's configuration was also personalized, the result of many years of hard daily use. Thanks to that experience I've been able to quickly configure Arch to my preferences, but I must add that Arch itself - and especially Xfce4 - makes it a simple and direct matter to customize the system to my exact specifications.
One acid test of the system will occur during the coming week, during my teaching sessions. I use the main machine extensively throughout lessons, for such activities as :
- Finding tablatures and lyrics on Google.
- Printing tabs, chord charts, lyrics, blank music/tab paper, etc.
- Finding and watching performances on YouTube.
- Listening to/watching media on CDs, DVDs, USB sticks, etc.
- Recording student sessions with Ardour.
- Using Audacity for its excellent Change Tempo utility.
- Quickly creating MIDI tracks for accompaniments.
These activities require things like a consistently working printer setup, a steady Internet connection, a stable Web browser with the latest Flash player, support for external media devices, xrun-less audio performance with a professionally-capable hard-disk recorder, and uncomplicated control over the audio/MIDI subsystems. I'm confident that Arch is up to the tasks, and I'm looking forward to making it my default system on Studio Dave's main iron.
Coming next: A review of Gmaq's AV Linux, and more, of course.
Similis sum folio de quo ludunt venti.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide