Troubleshooting Linux Audio, Part 1
I have a friend who has had nothing but nightmares result from his attempts at setting up the fabled low-latency high-performance Linux audio system. In sympathy with his plight I present here a primer in three parts for troubleshooting common and uncommon problems with the Linux sound system. Parts 1 & 2 will present programs used to analyze and configure your audio setup. Part 3 will list the most frequently encountered problems along with their suggested solutions.
This week, Part 1 introduces some useful system analysis tools and utilities with graphic user interfaces.
The Linux audio system is a complex beast, and ALSA is its beating heart. Well, it's supposed to be, but what do you do when it's not beating ?
First, consider the critical parts of a typical computer sound system. Three main stages exist for possible malfunction :
- Connections between soundcard and external equipment.
- The soundcard and its configuration.
- Your system software configuration.
Stage 1 should be checked for proper connections, power status, cable integrity, and other hardware aspects. Consumer-grade sound devices usually provide poor-quality connectors, though some cards from Creative include more durable connection points on their "Live Drive" control panels. If your external equipment includes an amplifier or powered speakers, be sure the power is turned on (and double-check those flimsy connectors between speakers). Cords and cables can be damaged easily, causing static-like noise and other discontinuities in the sound, and their connectors should be solidly attached. You don't need to buy cables with gold-plated hardware, but you should avoid cheap cords with molded plastic connectors. Remember, your audio system is a chain of parts, and like any chain it's only as strong as its links. Avoid weak links.
The soundcard itself may cause audio problems if it is not seated completely in its slot. It may also be a noise source if placed next to certain video or network cards. I'll discuss card and system configuration details later in this article, but first I have some advice to help you avoid some predictable problems.
Doing It Right The First Time
I can't over-emphasize the need to do your homework before purchasing hardware for audio with Linux. If you're coming from Windows into the Linux audio world you must not assume that your equipment will be supported. For that information your first stop should be the new & improved ALSA Soundcard Matrix, and if you can't find what you need there you should proceed to the LAU mail-list and its archives. These steps are increasingly necessary as Linux itself broadens support for USB, Firewire, and other i/o devices and protocols. For the most up-to-date information on recommended (and not-so-recommended) hardware, search the LAU archives and ask on the mail-list.
Typical recommendations for professional-quality audio work include the RME Hammerfall and the M-Audio Delta systems. However, potential buyers are well-advised to ask on the LAU list before purchasing any hardware, even the recommended items. Sensitive points include firmware versions, preamp requirements, available sample rates, and so forth.
ALSA supports a greater variety of consumer-grade cards, so recommendations are easier to make. Most cards from Creative Labs are well-supported, though again I also advise checking the ALSA Soundcard Matrix and the LAU mail-lists for current reports on your potential purchase.
USB audio devices are generally supported if they are truly standards-compliant. The LAU mail-list archive contains some valuable threads regarding USB devices and their performance under Linux, it won't hurt to consult the archive before buying a USB sound device. Firewire support has only recently come to the Linux audio world, thanks primarily to the work of the FFADO (formerly FreeBOB) project. Consult the FFADO Web site and the LAU list for current usability reports.
On-board desktop and laptop chipsets are generally not recommended for serious recording, at least not for multitrack/multichannel CD-quality digital audio I/O. They may be desirable for audio features for CD/DVD playback, but they are not sufficiently robust for serious audio production. The hda_intel chipsets are especially prone to difficulties; see the LAU archive for details regarding that and other fractious laptop & notebook audio chipsets.
Tools & Utilities: GUI
The Windows Control Panel has been a mixed blessing for users, but it does succeed at putting a lot of information about your system into one handy utility. Linux per se does not provide such a utility, but many Linux distributions and desktop environments now supply some kind of GUI for investigating and configuring your system and its various devices. For example, openSUSE includes yast ("yet another system tool"), an excellent utility that reports a wealth of detail regarding your machine and its operating system.
The screenshots in Figures 1 through 4 indicate the breadth and depth of information and control available from yast. Figure 1 shows off the yast (yast2, actually) GUI. The left-hand panel lists the general categories, and each category displays its own set of available devices and services. Figure 2 displays the results from selecting the Hardware category and then clicking on the Hardware Information icon. Figure 3 shows the same panel with the sound device information fully revealed.
The panels in Figures 1-3 are non-interactive, they only report the current configuration details. To reorder, enable/disable, or otherwise reconfigure your audio devices, open the Soundcard Configuration dialog (Hardware category, Sound icon).
Figure 4 shows off the configuration dialog for my JAD box. According to its report, I have two soundcards installed in my system, a real SBLive Value and a virtual MIDI card (the ALSA virmidi device). The SBLive was detected during installation, along with an on-board audio chipset. I disabled the on-board device in the machine's BIOS and later added the ALSA virtual MIDI port module. The Add button invokes a list of available drivers and extension modules, including the virmidi module. It was installed as the second card by default, and that's how I've left the system.
The dialog's Edit button calls up an interactive display of driver module configuration options. Depending on your soundcard, these options may be many or few. For example, the virmidi module provides only one, a parameter to create more than the default four virtual MIDI ports. In contrast, the module options for my SBLive include infrared control enable/disable, maximum number of wavetable synth voices, maximum sample buffer size, and three others. Most users should have no need to further configure a soundcard after installation, but the finer control is there when needed or desired.
QJackCtl is the main JACK control utility at Studio Dave, but I mention it here for its usefullness as a system analysis tool. The Messages panel reports any problems encountered when starting and operating the JACK server, the Status panel expands upon the information seen in QJackCtl's window display, and the Setup dialog provides a convenient all-settings-in-one-place configuration utility. Alas, the Setup dialog isn't much good if you don't know what affects what, but help is at hand, or at least on-line: Knowing JACK (PDF 370K) was written originally for Linux Pro Magazine in 2006, but its essential information remains valid, particularly the explanatory list of the Setup parameters in QJackCtl's Settings dialog.
Maarten de Boer's AlsaMixerGUI displays the same set of controls as the alsamixer console program, but the interface is much nicer, and it also adds a full report of the /proc/asound system. Right-click the ALSA logo, select Proc Info from the drop-down menu, and a report similar to the screenshot in Figure 6 should appear. I'll explain the proc system later in this article, but Figure 6 indicates its relevance whe troubleshooting ALSA.
AlsaMixerGUI isn't the only soundcard mixer that provides such reports. Check around on yours, you might find some useful hidden system analysis tools.
Linux Music Makers
Even if you can't read Spanish you should visit Carlos Pino's music page. My personal picks are Smooth (OGG 2M) and Open Horizon (OGG 4.8M), two sweet grooves that demonstrate Carlos's skills as an arranger and soloist.
Edgar Aichinger is a regular participant in the JackLab forum and the #jacklab IRC channel at Freenode, where he is known as edogawa. In addition to his activities at the JackLabs he is a devoted father and an impressive lutenist, as you can hear for yourself in his performances of Mille Regretz (OGG 2.8M) and this Prelude (OGG 1.4M) by Denis Gaultier.
Next entry I'll introduce troubleshooting from the prompt with some humble but powerful command-line tools. Meanwhile, I encourage readers to send in their own audio system configuration reports and troubleshooting tips. If we can amass enough relevant material perhaps one of us could be persuaded to wrap it up into a helpful page at Linuxaudio.org for everyone's access and assistance.
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
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
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