StudioDave Does A Hardware Review And Meets Ubuntu 8.10
A few months ago I started sensing the need for a replacement for my aging and ailing HP Omnibook 4150. That machine's audio capabilities were negligible even with external hardware, but it had been serviceable for writing articles and as a portable MIDI composition environment. Alas, after years of travel and abuse the Omnibook's hard drive gasped its last breath of life. I had no fear for my data, the drive had been backed up, but clearly the time had come to buy a new portable computer.
My home town doesn't offer much choice when it comes to buying hardware. We have a Wal-Mart, a Best Buy, a Staples store and some local repair shops. Few sales people here know much about Linux, so my hopes for satisfaction were low. Nevertheless, I found a contender at Best Buy, a Hewlett-Packard G60-125NR. After due deliberation and much helpful advice from my colleagues on the Linux Audio Users mail list I decided to purchase the machine.
This purchase was risky. Google supplied only a little information about the machine's performance under Vista, and those reports were not overwhelming in their praise. However, I did find some reports indicating success with recent Ubuntu systems, and the machine's hardware seemed to be a near-perfect fit for my needs. The G60 is powered by an AMD Turion running at 2 GHz and includes a 250G hard disk, 3G memory, and a LightScribe CD/DVD-RW drive. Graphics are provided by an on-board nVidia geForce 8200M, sound is handled by Intel's HDA codec. Vista was pre-installed, so I took a quick look around before wiping the disk. Very pretty, rather slow. I hoped to see and experience better performance with Linux.
I had specific intentions for this machine. Above all it had to run AVSynthesis, which meant that it would need accelerated 3D graphics capability along with support for high-quality realtime audio. I also wanted to install a complete environment for building a specific version of Csound 5.09 and for compiling Ardour 3 from its SVN source code, which meant that I would need a relatively up-to-date Linux distribution. Other required components included a recent version of JACK and the latest Java SDK.
So how did I fare ? I'll announce the spoiler now and tell you that everything is coming along nicely and I'm happy with my purchase. But Linux is Linux, and configuring a Linux machine for audio production can be troublesome. Read on for the details of my trials and travails as Studio Dave goes mobile.
In The Beginning
A new machine deserves a new operating system, so decided to sample a few distributions before settling on one. I first tried plain vanilla installations for 64-bit Ubuntu 8.10 and Arch Linux. Both failed, but I succeeded with OpenSUSE 11.0. Alas, the nVidia binary driver wouldn't load, so I followed another lead (thank goodness for Google) and installed the 32-bit version of Ubuntu 8.10, aka Intrepid Ibex.
I must emphasize that my failures with the other distributions were likely my own fault. When I installed OpenSUSE I learned that a bad driver (the Atheros wifi driver) could freeze an installation. I fixed the problem by adding brokenmodules=ath5k to the installation options, and soon afterwards I had a working OpenSUSE system. I applied the same option to the Ubuntu installation, along with brokenmodules=ath_pci. I'm not sure I needed either option, but the installation proceeded smoothly to completion.
After the installer completed the basic user-level configuration I replaced the GNOME desktop with Fluxbox and added the realtime kernel to my start-up selections. I also added nVidia's closed-source driver, an uncomplicated task thanks to Ubuntu's Hardware Drivers manager. However, I needed to add myself to the video group before I had full GL/GLX support as a normal user. With that issue resolved I was ready to wrestle with the machine's audio hardware.
The Sound Scenario
By default Intrepid is set up for simple desktop sound such as DVD, CD, and soundfile playback, but my needs are considerably more demanding. As I expected, setting up my required audio support was troublesome labor.
For some reason Intrepid does not create an audio group, and membership in such a group is necessary to ensure priority access to the sound devices. Fortunately the GNOME Control Center provides a nice control panel for defining new groups and their members. With that step taken I then proceeded to configuring the JACK audio server. I need flawless performance from JACK, and that requirement alone took some time to meet.
The G60's audio chipset is based on Intel's HDA codec. This codec is designed primarily for high-grade playback of DVDs and other audio streams, including various surround sound configurations. Nothing is inherently awful about the chipset, but it is definitely not designed for desktop audio production. This fact presents itself glaringly when the JACK server is invoked. Without alteration to anything in the basic system JACK's performance was very poor with a relentless stream of xruns. I checked with Google, and indeed this problem was well-known and had a number of proposed solutions. These proposals included setting the period size to 3, the frames per period to 256, and the sample rate to 44100. In addition to these settings for JACK I learned that certain options should be passed to the ALSA kernel sound module (snd-hda-intel), including a model specification, a fix for a DMA-related problem, and a switch to enable MSI (message signalled interrupt). Alas, none of the suggested fixes worked for my hardware. I was about to give up on the on-board sound when fellow enthusiast Shane Richards pointed me towards Rui Nuno Capela's excellent rtirq script. I installed the script according to its instructions and started it so :
dlphilp@maximus:~$ sudo src/rtirq-20071012/rtirq.sh start rtirq.sh: start [rtc] irq=8 pid=852 prio=90: OK. rtirq.sh: start [snd] irq=10 pid=1970 prio=85: OK. rtirq.sh: start [ohci_hcd] irq=5 pid=1916 prio=80: OK. rtirq.sh: start [ohci_hcd] irq=11 pid=1156 prio=79: OK. rtirq.sh: start [ehci_hcd] irq=7 pid=1920 prio=80: OK. rtirq.sh: start [i8042] irq=1 pid=841 prio=75: OK. rtirq.sh: start [i8042] irq=12 pid=840 prio=74: OK.
Following Shane's advice I set JACK's priority to 70 and restarted the server. I was astonished to discover that I could achieve the optimal latency possible with this hardware and suffer no xruns at all. That latency is hardly low (JACK reports 17.4 ms) but it is serviceable until I deploy a better external interface. To recap, here are my JACK settings :
jackd -R -P 70 -d alsa -p 256 -n 3 -r 44100
where -R indicates realtime activation, -P sets the priority level, -d names the audio system backend, -p sets the period size, -n sets the number of frames per period, and -r equals the sample rate.
Annoyances And Solutions
The system speaker's beep was annoyingly loud until I discovered the hardware volume control keys. The G60 includes a function activation key (labeled fn) located to the left of the Windows key. The *, -, and + keys on the numeric keypad - labeled for speaker mute, decrease volume, and increase volume - are activated in combination with the fn key.
I don't usually care for a notebook's touchpad, and I was pleased to see that the G60 included a switch to disable the device. Alas, it didn't work, or so I thought until I discovered the touchpad controls in the GNOME Control Center utility. I still need to find a way to disable the touchpad at start-up, but at least now I can turn off the device during a session.
I knew that some degree of Linux support exists for the LightScribe disc drive, and I was interested to see how well that support would work for my new hardware. I installed LightScribe's system software and tested their SimpleLabeler along with the 4L-gui and 4L-cli labeling tools from LaCie. Everything worked as advertised, though I had to install libstdc++.so.5 for the LaCie software. These programs are all closed-source, but LightScribe's SDK is available as free software licensed under the GPL. Now if I can figure out how to add text with 4L-gui I'll have completed my LightScribe preparations.
The G60 includes a port for an HDMI connection, but I haven't tested it. HDMI is interesting enough to investigate, and the installed versions for the ALSA (1.0.17) and nVidia (177.80) drivers support the interface on the G60, so I'll check it out eventually.
I also did not test the machine's wifi support and its media card reader. Sorry, I ran out of time.
Some annoyances remain. I installed the firmware and loading rules for my MidiSport 2x2 USB MIDI interface, but the device still doesn't initialize until I unplug it and plug it in again. Suggestions are most welcome for a fix to this problem. I have a similar problem with the rtirq script, I'd like to have it loaded by the time my login appears.
My Edirol UA25 arrived as I was putting the final touches to this article. Again I'm faced with resolving xrun issues with JACK, but I'm confident that I'll soon have it working to my expectations.
I mentioned that I intended to set up a development environment sufficiently current to build Ardour 3 from its SVN sources. Alas, Intrepid's components are a little too current, and the environment's GTK support is actually too new for Ardour 3. I doubt that the problem will remain much longer. I did successfully compile Ardour 3 with SYSLIBS=1, an option emphatically not supported by the Ardour developers. I'll have more to report regarding Ardour 3, but not until I can build it according to the official recommendations.
And A Big Thank You To...
I owe my colleagues on the LAU list for much advice on many topics, but they were especially helpful with regards to this purchase. Extreme thanks go out to Mark Knecht (aka He Who Never Sleeps), Shane Richards, Arnold Krille, and everyone who responded to my pleas for assistance. I made the buy with much greater confidence because of their support and encouragement.
I am satisified with this machine, and Ubuntu 8.10 is an excellent fit for the hardware. AVSynthesis runs nicely in realtime, and the rtirq script has eliminated xruns from JACK's performance. The apt system has made it easy to update the system and set up a full-featured development environment, and of course there's the whole UbuntuStudio apps collection for me to explore. I'll have more to say about my new machine and its performance with Linux audio software, so be sure to check in again soon.
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!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
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