Judgement Day: Studio Dave Tests Ubuntu Studio 9.04

I need at least one i386 installation here at Studio Dave because some production software is not yet 64-bit ready, and I happen to need that software. SuperCollider3 can run on a 64-bit system, but only after some tricky maneuvers; the label printing programs for my Lightscribe drive are 32-bit only; and VST/VSTi audio plugins still work best in a pure 32-bit system. My main production machine runs a pure 64-bit distribution (64 Studio), but an i386 box is still required for the complete Studio Dave.

The Road To Jaunty

I already have one such system here. My secondary desktop machine runs the excellent Jacklab Audio Distribution (JAD), based on the rather old OpenSUSE 10.2. However, JAD has not been updated for a while, and I need an up-to-date distro. The 64 Studio developers also make a 32-bit "legacy" version of their product, but I wanted to try a new flavor. Enter Ubuntu Studio.

I've already chronicled my recent experience with Ubuntu 8.10 (Intrepid Ibex). Given the overall hassles I encountered then you might wonder why I returned to any variety of Ubuntu. Well, the most recent Ubuntu Studio is based on the latest Ubuntu 9.04 (the Jaunty Jackalope), with a tested realtime kernel, so I thought it might be a good time to revisit the system.

I planned to install Ubuntu Jaunty on my notebook, an HP G60 machine with an AMD64 Turion X2 CPU, 3G memory, and a 250G hard disk. Video is handled by an integrated nVidia 8200M GPU, on-board sound is managed by an nVidia chip based on Intel's HDA codec. I had already installed Ubuntu 8.10 on the machine, but I decided to install Jaunty from a DVD. Turns out that was not such a good decision, and thus began my most recent series of trials and tribulations with Ubuntu.

I downloaded the ISO images for the i386 and x86_64 Jaunty installers, checked their md5 sums, and burned them to DVD discs. As noted, I especially wanted the i386 version so I tried installing it first. Everything went along nicely until I received an error message that stated that the installation had failed at the Select & Install Software stage. I retried that step via the installation menu, but it failed again. I then tried moving on to the next step of installing grub, but the installer failed again with the same non-specific error, only this time for the grub step. I tried to back out of that step but the error message wouldn't close. Fortunately I could still access the installation menu, so I opted to abort the installation.

I tried the installation again, this time with the x86_64 installer, and had exactly the same experience, i.e. the same errors at the same stages. At that point I was left with a hosed partition and no usable Jaunty. At least the installer didn't hose my 64 Studio partition and I could still boot into that system without problems. After some research I discovered that indeed the DVD installers are flawed in some way, though the md5checksums were correct and the media integrity checks reported no problems with the discs.

I searched Google and figured out that I would have been better off to have simply upgraded from my Intrepid installation, so I re-installed Ubuntu 8.10 and went directly to its Update Manager. I clicked on the big button that said "Upgrade to Jaunty" and let the network installer do its thing. After a while my notebook had a brand new Ubuntu Jaunty system (kernel 2.6.28-11-generic), so I rebooted, logged in, and started to organize the system for eventual use as the base system for Ubuntu Studio.

First, I installed the latest nVidia driver from the Hardware Drivers panel. I rebooted, but no nVidia splash screen appeared. The nvidia-settings utility said that the nVidia driver was not in use and advised running the nvidia-xconfig program to correctly set up X for full graphics hardware acceleration. I ran the config program, rebooted the machine, and this time the nVidia splash screen appeared signalling that all was well with the nVidia hardware. I had attained Jaunty status.

On To Ubuntu Studio

At the next stage I added all the Ubuntu Studio meta packages. These packages are simply lists of the software required by the specialized distribution. For example, the audio package includes a good selection of audio-related software, along with a 2.6.28 kernel optimized and patched for realtime performance. After these packages were installed I rebooted, selected the rt kernel from the grub menu, and soon encountered the next batch of troubles.

The first problem occurred when the system stalled at the Ubuntu Studio logo display. However, on reboot the system made it past the logo screen and I finally arrived at the login prompt, complete with an apparently working nVidia driver. I logged in, looked around for a while, then exited and restarted. Once again I made it to the login page, but after I logged in the system froze completely as soon as the Ubuntu workspace appeared. By "completely" I mean that the mouse and keyboard were unresponsive. I had to press the power switch to shut down the system. Not a good outcome.

I rebooted with the normal system kernel (non-realtime), logged in, and experienced the same problem. My first thought was to blame the closed-source nVidia driver. I did some research on Google and the Ubuntu forums, and I soon discovered that other users had reported the same tribulations on machines with non-nVidia graphics chipsets. The consensus was that the problem did not lie with the video subsystem. To verify that consensus I followed an interesting suggestion. Since I could get to the graphic login screen I could also switch to a console display where I could log in at the terminal prompt. I installed the OpenSSH server software, logged on to the machine from a desktop box, and used X forwarding to verify that the system was there and viable. Programs ran happily with their GUIs intact, so it seemed that nVidia was off the hook with regards to my basic problem.

Following suggestions found in my research I added these kernel boot options to the realtime kernel's entry in /boot/grub/menu.lst:

nosmp acpi=off pnpbios=off

Incidentally, the acpi option required the pnpbios option. When I booted with only the nosmp and acpi options the boot loader issued a fatal error message that advised using the pnpbios=off setting, I tried it, and voila, the system was now open and available for business. I logged in without troubles with either the mouse or keyboard. At last I could start to explore Ubuntu Studio. Alas, my expectations were quickly soured when I tried running QJackCtl. It failed to connect to the JACK server, and I was pretty sure I knew why. As it turns out, I was correct. The problem was Pulseaudio.

Resolving The Pulseaudio Problem

A word or two about Pulseaudio. The normal Linux desktop wants a sound server for various purposes such as system alerts and support for regular sound applications such as media players. As with some other aspects of Linux we now have too many solutions for that purpose, and the result has been a very messy affair. Developers are faced with an embarrassment of choices, and those choices are most certainly not equal in capabilities or intended purposes. As a result, confusion reigns when it comes to Linux sound servers. Pulseaudio attempts to resolve many issues, but in doing so it has become an issue itself. Pulseaudio itself is not necessarily a bad or even problematic thing. However, its implementation can be very problematic indeed.

As I said, I could at last boot into Ubuntu Studio. However, the alsamixer utility showed only two active audio channels (master volume and I forget what else, sorry). No other controls were present as far as I could tell. Following another bit of advice I looked into the depths of /var/log/user.log and found a stream of these errors:

pulseaudio[3519]: alsa-util.c: Cannot find fallback mixer control "Mic" or mixer control is no combination of switch/volume
pulseaudio[3519]: alsa-util.c: Cannot find fallback mixer control "PCM" or mixer control is no combination of switch/volume
pulseaudio[3519]: alsa-util.c: Device plug:front:1 doesn't support 44100 Hz, changed to 48000

Ubuntu Studio employs Pulseaudio as its default sound server. Unfortunately this employment stands in the way of directly using JACK, and any Linux distribution that advertises itself as an audio production system will assuredly be using JACK for its audio server, not Pulseaudio. The typical solution would simply remove Pulseaudio, but Ubuntu doesn't let that happen without removing the GNOME desktop, a rather drastic operation. Worse, the Pulseaudio daemon is persistent, so killall pulseaudio works only until the next call to the audio system, when the daemon reloads itself and remains in the way of a successful launch of JACK. Fortunately I discovered an excellent HOWTO titled Keeping The Beast Pulseaudio At Bay by a user with the handle of idyllictux. Thanks to his instructions I safely disabled Pulseaudio, and I recommend his advice to anyone who wants to put aside Pulseaudio.

By the way, I want to emphasize that I have nothing against Pulseaudio per se. Its developers have taken on a terribly difficult task, and I believe that they are working hard to make it the system sound server of preference for the mainstream Linux distributions. However, it does not currently suit my purposes, and its current implementation in Ubuntu creates problems for me. The advice from idyllictux resolves the matter nicely. Perhaps his suggested process could be offered as a configuration option to the advanced user ? Until the problem is resolved on the distro side I'm afraid that Pulseaudio will take heat from users who are unaware that the problem may occur because of the distribution's implementation of the server, not with any particular aspect of Pulseaudio itself.

More Configuration Trickery

My experiences with Ubuntu Intrepid taught me a few other tricks that were necessary before I could be happy about this new Jaunty-based Ubuntu Studio. I removed the network manager (easily done with the Synaptic package manager) and set up the default network device (eth0) for autoconnection via dhcp at system start-up. I disabled HAL polling on /dev/sdb and /dev/sr0, neither of which were listed in /etc/fstab. The polling was causing an xrun every 2 seconds (verified with the top utility). I turned off my machine's touchpad, but only after discovering that the solutions I used for Intrepid no longer worked with Jaunty. Thankfully, the solution was this simple one-line addition to /etc/rc.local:

modprobe -r psmouse

Shazam, no more random touchpad irritations. By the way, in case anyone was wondering why I didn't just use the administration tool for the mouse/touchpad: No tab or other dialog was present for controlling the touchpad, so I was left to manually reconfigure the thing.

A more serious problem presented itself when I discovered that JACK would not start in realtime mode. Surprisingly, Ubuntu Studio doesn't automatically create an audio group, so I had to open the dialog at System->Administration->Users and Groups, create the group, and add myself to it. I also had to edit /etc/security/limits.conf to add these instructions :

@audio - rtprio 99
@audio - nice -19
@audio - memlock unlimited

I restarted the system, logged in, configured and started QJackCtl, and behold, I was in realtime heaven. Figure 1 shows the settings I use for 8 milli-seconds latency with no xruns from my Edirol UA25 USB audio/MIDI interface.

Figure 1. QJackCtl settings for the Edirol UA25

By the way, the Ubuntu Studio Preparation Web page is an indispensable resource at this stage. The information there is clearly presented and should be required reading by anyone new (or even not so new) to Ubuntu Studio.

The specified changes are recommended for every high-performance audio distrbution, the figures come straight from the JACK devs, so why is this step relegated to the user? It seems a simple enough matter to have the installer make the entries during the system configuration. Ditto for the creation of the audio group, it should be prepared by the installer and the user should be added to it automatically during configuration.

Moving On, At Last

After all that, I finally had a fully-functioning Ubuntu Studio on my HP G60 (Figure 2), complete with stable low-latency audio performance, an excellent selection of sound and music production software, and support for nVidia accelerated graphics. I like to build my own software from source packages, so I proceeded to install the necessary boatload of dev packages, the build-essential meta package, and anything else needed for the complete Linux software development environment. As previously reported, my first project was the rc2 release of MusE 1.0, and I'm very happy to write that the build finished without complaint, installation was a breeze, and MusE's performance was rock-steady during my initial tests.

Figure 2. Ubuntu Studio 9.04

The Verdict

I've only started to dip into the various goodies provided by the Ubuntu Studio meta packages. I'm eager to check out the latest LMMS and Pd, and I plan to use the machine as my main platform for working with SuperCollider3. Thanks to the currency of the system I can build and test the latest Ardour3 as well as many other applications that require up-to-date graphics and audio components.

Performance-wise this system is now a beauty. Alas, the hoops I jumped through to get it into this condition were many and formidable. The solutions to my problems were not too difficult to find or implement, but they would be extremely challenging for users unfamiliar with the inner workings of Linux. In my opinion the Ubuntu Studio installer needs to go further in its preparation of the system for pro-audio needs, perhaps offering the user a choice between a high-performance desktop media playback system, a low-latency pro-audio production environment, or some stable mixture of both. The Pulseaudio problem ought to be easily resolvable by the user, and more system probing might be able to spot and resolve problems such as needless HAL polling.

It's worth pointing out that my experiences may not be typical because of the hardware involved (it's a fairly new machine), and you should expect your mileage to vary, hopefully towards the better. I'd like to hear from other Ubuntu Studio users, so please feel free to add your opinions to the Comments section below.

In closing, I want to thank the users and developers who populate the Ubuntu Forums, I definitely needed and heeded their help and advice. Thanks also to the regulars on the Linux Audio Users mail list, from whom I continue to learn so much. I had a stretch of rocky road to traverse, but the way was made easier with such excellent company.

Outro

Coming up, a review of the Linux version of Modartt's Pianoteq. Until then, stay tuned, upright, and stable.

A fair question, but after being borked by two DVD installs for Jaunty I had enough of that route. Also, it seemed to me that the more common recommendation was to install Jaunty first, then add the UStudio metapackages. I took that route.

In your opinion, would my experience have differed if I had installed from the UStudio ISO ?

First of all thanks for the great article and all the work you do for us linux users interested in all things audio.
I'd first like to stress the fact that I'm no pro user, all I like to do is hook up my guitar to the pc and do some very basic effect work and recording (when work and life give me the time to, that is).
My first impression is that the 'buntus are awful for audio work, after seeing the hoops you went through to get a stable and performing system I now see why (I had no idea about HAL polling and touchpad issues).
I stopped upgrading at the LTS version and can honestly say 6.06 worked better for my purposes. I have ditched real-time entirely as the provided kernels were as stable as a plate of jelly during an earthquake and in so doing I also discovered that for my purposes and the latency I can live with I didn't need it in the first place.
On the other hand, all this bother brought me to test fedora 10 with the ccrma project on a spare partition and I must confess that for an apt-loving, rpm-hating, debian raised person such as myself, I was thoroughly impressed.

All this to say, I would be extremely interested to read your expert's opinion on a fedora + ccrma based audio setup as compared to 64studio and ubuntu-studio.

This comment makes absolutely no sense in this context. This article is about a special purpose system. This is like going to a high-end gaming site and complaining that some registry tweak for the latest Nvidia card is not easy and intuitive. You might try trolling a board where your comments at least don't seem completely inane.

I had to look up what LARPing was, but after I did, the comment was at least moderately amusing. I'll have to at least give you credit for making me chuckle. However, I'm afraid I don't belong to a Star Trek fan club (although I am at least somewhat of a fan), and I have never LARPed in my life. The closest I've come is playing World of Warcraft for a while (it gets pretty old after a little while though, especially in the Summertime). I'm afraid that besides computers, my hobbies are more traditional things like hiking, drawing, photography, and reading (although I'll admit that some of the reading is fantasy & sf :-) ).

I'll add that tip to the others I've collected. Right now I'm happy with the solution described by idyllictux. I have PulseAudio completely out of the picture, with no chance of resurgence due to updates, system upgrade, daemonic persistence, or some other Linux voodoo mojo weirdness. :)

"... contact to the Pulseaudio mailinglist directly, cause otherwise the Linux (audio) world will be ruled by a lot of myths..."

A good suggestion. Alas, if I contacted every developer group responsible for the problems I've encountered I'm not sure I'd have time to actually use the system. More to the point, why exactly is any of this two-stepping necessary at all ? Again I say: If a system advertises itself as an audio production system then that system should fulfill the expectations of pro-audio users, and there should be no need for any of these workarounds and correctives.

64 Studio and Planet CCRMA have established the models for system stability. Wise developers will consider how those systems achieve their stability.

Btw, I'm perfectly aware of how complex distributions have become, and I know that it is impossible that the developers can attend to every combination of hardware running Linux. I apologize if my commentary seems harsh, it is not intended to insult or downplay the great work that has gone into Ubuntu. It is intended to draw needed attention to remaining issues that affect serious audio recordists.

On my Ubuntu Studio Jaunty system qjackctl is automatically run with pasuspender. No configuration of pulse audio was needed. I did do a fresh install from the studio disk, but I seem to recall that the metas in the beta versions of Jaunty (ontop the beta regular ubuntu) also had no problems with pulse audio. What exactly led you to believe Pulse Audio was stopping Jack from running?

"Ubuntu Studio employs Pulseaudio as its default sound server. Unfortunately this employment stands in the way of directly using JACK, and any Linux distribution that advertises itself as an audio production system will assuredly be using JACK for its audio server, not Pulseaudio."

I don't see how PA stands in the way of Jack. On my 9.04 PA exists totally seemless, enabling me to watch and hear youtube while any other sounds are playing in the background. When I start Jack, PA goes out for lunch, there's absolutely no interfering. This is without any tweaks or modifications of the system at all.

Until PulseAudio was disabled I could not even launch JACK. I'd definitely call that "standing in the way".

Perhaps I didn't make it clear enough in the article so I'll emphasize again: I have no quarrel with PulseAudio per se, but it has little or no place in an audio production system, which is after all what UStudio purports to be. PulseAudio is not a low-latency audio server and it provides no such transport control as JACK. To its credit, it does not claim to be such a system.

i have a laptop with touchpad (recognized by recent kernel as Elantech Touchpad).
i disable touchpad mode by using kernel command line:psmouse.proto=imps
since my psmouse is kernel built-in.
With this option touchpad will be recognized as regular ps/2 mouse (with ImPS/2 protocol).

you can also add this option in /etc/modprobe.conf asoptions psmouse proto=imps
if your module is not kernel built-in.

Given that Linux can runs on devices from netbooks to super computing Beowulf clusters, reviews that concentrate too much on a particular combination of hardware bits can be less than useful. Laptops, in particular are often problematic. I wish reviewers would find a system than a particular distribution, such as UbuntuStudio Jaunty Jackalope, runs real good on and then describe exactly their hardware configuration so that other users can duplicate it.

Choosing a bit of hardware, ill-suited to Linux, and then complaining about installation issues is not real helpful.

is a large hammer. it's unfortunantly not uncommon for new hardware to have acpi problems (the hardware vendors criteria is more 'does it work with windows' than following any spec), but it's very uncommon for nosmp to be needed to make a system work properly

you may want to try again without the nosmp to get the ability to use the second core in your system.