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.

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.

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.