Troubleshooting Linux Audio, Part 2
In my last installment of this series I introduced a variety of GUI-based tools that can help you discover more about your system to help identify potentially troublesome components. This week we'll look at some of the command-line utilities that do similar work. In fact, some of these utilities are the engines underneath the more attractive GUI tools, and there may be good reasons to employ the engines directly instead of relying upon their graphic incarnations.
The Linux console or terminal window (xterm or similar) is your best friend at the start of your audio diagnostics. If you launch an application from the command prompt you can receive reports from the program regarding its initialization and performance, and errors are often reported with helpful details.
Linux command-line tools are powerful resources. They are typically intended for combined use, following the UNIX philosophy of small tools that can be chained together to create more powerful tools. The following article describes some of the more important tools and utilities for troubleshooting audio problems, but my descriptions here are necessarily brief. For more complete information about a particular command see its manual page (e.g. 'man dmesg').
WARNING: Possible extremely geekish text follows, complete with obscure jargon, mind-numbing technical detail, and (gasp) commands and programs entered at the command prompt. Proceed at your own risk. You have been warned.
General System Analysis
It's not uncommon for a user to know next to nothing about the mechanical details of his or her machine. Fortunately Linux provides a variety of system analysis tools. Here are a few I've found most helpful over the years.
When Linux boots up it sends a stream of messages in plain text to its standard output device (i.e. your monitor). These messages list the system's successes and failures at identifying your machine and its components, along with its successes and failures at configuring those components for use. The reports scroll by too quickly to read while the machine boots up, but fortunately Linux provides the dmesg command to recall those reports.
Since it merely reports status, any normal user can run dmesg. Alas, when run without modification dmesg will stream its report as quickly as it did during startup. It would be much nicer to leisurely scroll through this output, and happily there's a simple way to do so by piping dmesg through the less command. Consider this combination of commands :
dmesg | less
This excerpt shows a portion of a report generated by this command :
dlphilp@The3800:~> dmesg |less ... hda: SONY CD-RW CRX225E, ATAPI CD/DVD-ROM drive hdb: LITE-ON COMBO SOHC-5236K, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... libata version 2.00 loaded. sata_nv 0000:00:0e.0: version 2.0 ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23 ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:0e.0 to 64 [lines 278-286]
The pipe symbol (the | character) sends the dmesg output to the less command, thus enabling the user to scroll forwards and backwards through the text. If you want to read the output at a later time simply employ the Linux redirection symbol (the > character) to send the dmesg output to a text file :
dmesg > dmesg-report.txt
You can further refine your search by piping the dmesg output into grep, a pattern-matching utility. The following example searches through the dmesg reports for a string of text that matches the indicated pattern :
dmesg | grep USB
The example produced this report on my JAD box :
dlphilp@The3800:~> dmesg |grep USB ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci_hcd 0000:00:0b.0: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found ehci_hcd 0000:00:0b.1: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:0b.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 hub 2-0:1.0: USB hub found usb 1-1: new low speed USB device using ohci_hcd and address 2 input: Logitech USB-PS/2 Optical Mouse as /class/input/input2 input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:0b.0-1 drivers/usb/input/hid-core.c: v2.6:USB HID core driver
Piping and redirection are helpful mechanisms that we will use with other command-line tools, but let's look at some other analysis tools first.
The uname command provides a concise summary of information regarding your kernel, CPU type, network node ID, and so forth (see the man page for a complete description of uname's flags and functions). when run with the -a switch you'll receive the command's full report :
dlphilp@The3800:~> uname -a Linux The3800 2.6.19-5-rt #1 SMP PREEMPT Sat Nov 25 18:35:39 UTC 2006 i686 athlon i386 GNU/Linux
Here's the breakdown of that information :
- Linux - kernel name
- The3800 - network hostname
- 2.6.19-5-rt - kernel release
- SMP PREEMPT - kernel version
- i686 - machine name
- athlon - CPU type
- i386 - hardware platform
- GNU/Linux - operating system
If you ask for help on a mail-list or forum you're likely to be asked about these details. The uname command will reveal them for you.
Linux employs a virtual filesystem called the proc (processes) filesystem. We can read a variety of status reports from the proc system by using the cat command. The following example queries the asound directory (the ALSA system as monitored by proc) and tells me how many soundcards I have installed in my machine :
Here's the report on my JAD box :
0 [Live ]: EMU10K1 - SBLive! Value [CT4832] SBLive! Value [CT4832] (rev.8, serial:0x80271102) at 0xa000, irq 20 1 [VirMIDI ]: VirMIDI - VirMIDI Virtual MIDI Card 1
Note that much relevant information can be found in this report, including the card numbering and naming, its hardware version, and its IRQ number. Again, when troubleshooting you may well need to know these names and values.
The cat/proc combination is very powerful. You can see a list of the entire proc filesystem by pressing the tab key after entering this command :
Do the same for any directories within the filesystem to see what else is monitored by proc :
That command returns this list for my JAD machine :
Live/ card1/ hwdep pcm version VirMIDI/ cards modules seq/ card0/ devices oss/ timers
As before, I can then run 'cat /proc/asound/whatever' for more detailed information regarding my ALSA components. Thus, if I need to know my ALSA version I simply run this command :
dlphilp@The3800:~> cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28 14:07:24 2006 UTC).
The following list provides other invocations for the cat/proc combination that may prove beneficial during a troubleshooting session :
cat /proc/interrupts cat /proc/cpuinfo cat /proc/devices
See the man pages for cat and proc for more detailed information about those commands and how they can be used. Remember, even if you don't understand the output from these tools you may be asked for the information by someone who does understand it and can help you resolve your difficulties. Which brings me to an aside...
When looking for assistance with Linux adio troubles it's not a bad idea to know a few things about Linux developers and power users. For the most part they'll be happy to help, but they will ask questions that verge on the incomprehensible, especially to a non-technical user. Learn to use the suggested tools, be patient, and stay civil. Provide the requested reports as fully as possible, and don't be surprised if there's no easy answer. Linux audio problems can be tricky to diagnose and resolve, but if you stay the course you'll find that your helpers will usually stay right there with you until your problems are solved. In this domain, as in so many others, "perseverance furthers" are words of wisdom.
Taking The Bus
Sound devices typically reside on what is called a bus line. The usual suspects include your machine's PCI card slots, its USB and FireWire ports, and its PCMCIA slots. Audio hardware is available for any of these locations, and each has its own performance idiosyncracies.
The lspci and lsusb commands list the devices present on the PCI and USB buses. When invoked with the -v switch they return verbose reports, but once again you can combine tools to filter, restrict, and redirect their output. In the next example the command chain simply redirects the verbose output from lspci to a text file :
lspci -v > foo.txt
As we did earlier, you could instead pipe the output to less if you don't need to save it.
The next chain filters the output from lspci and sends the filtered report to a text file :
lspci -v | grep Creative > foo.txt
The output without the redirection :
dlphilp@The3800:~> lspci -v | grep Creative 01:07.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08) Subsystem: Creative Labs CT4832 SBLive! Value 01:07.1 Input device controller: Creative Labs SB Live! Game Port (rev 08) Subsystem: Creative Labs Gameport Joystick
Use of lsusb is similar. Both of these commands have numerous switches to modify the output, and the determined troubleshooter is well-advised to consult their man pages for more details.
The soundcard in your Linux box works because there's an ALSA driver module that manages the lowest-level communications between your hardware and your computer's operating system. If there's no driver, or if there's a problem with a driver, there may as well be no soundcard.
The lsmod command lists the modules currently loaded into your system. The command takes no switches, so our previous filters will come in handy. Here are some helpful invocations of lsmod :
lsmod > modules.txt lsmod | grep snd (all ALSA modules) lsmod | grep usb (all USB device modules) lsmod | grep ieee1394 (FireWire driver)
If you know you have the hardware but no driver is listed, then either the driver module itself is not present or your system has failed to load it during its hardware configuration stages. You can manually load or unload a module with modprobe, but you need to know the name of the driver. If your soundcard or chipset is listed on the ALSA SoundCard Matrix you can find the driver module's name listed with your card. For my SBLive I would enter this command string :
modprobe -i snd-emu10k1
Note that you must have root user privileges to install device drivers.
An ALSA driver module may include various options that can critically affect the device's performance. The modinfo command returns information about a module, including its optional parameters, as displayed in this output regarding the SBLive driver module :
dlphilp@The3800:~> modinfo snd-emu10k1 filename: /lib/modules/2.6.19-5-rt/kernel/sound/pci/emu10k1/snd-emu10k1.ko author: Jaroslav Kysela
description: EMU10K1 license: GPL vermagic: 2.6.19-5-rt SMP preempt mod_unload 586 REGPARM depends: snd-pcm,snd-util-mem,snd-page-alloc,snd,snd-rawmidi,snd-timer,snd-hwdep,snd-ac97-codec,snd-seq-device alias: pci:v00001102d00000002sv*sd*bc*sc*i* alias: pci:v00001102d00000004sv*sd*bc*sc*i* alias: pci:v00001102d00000008sv*sd*bc*sc*i* srcversion: 17D45264B5978A64D57C5B7 parm: subsystem:Force card subsystem model. (array of uint) parm: enable_ir:Enable IR. (array of bool) parm: max_buffer_size:Maximum sample buffer size in MB. (array of int) parm: max_synth_voices:Maximum number of voices for WaveTable. (array of int) parm: seq_ports:Allocated sequencer ports for internal synthesizer. (array of int) parm: extout:Available external outputs for FX8010. Zero=default. (array of int) parm: extin:Available external inputs for FX8010. Zero=default. (array of int) parm: enable:Enable the EMU10K1 soundcard. (array of bool) parm: id:ID string for the EMU10K1 soundcard. (array of charp) parm: index:Index value for the EMU10K1 soundcard. (array of int)
If you need to assign a value to an unassigned parameter you can either add it to the module's invocation with modprobe or you can permanently add it to /etc/modprobe.d/sound. For example, to limit the number of synthesizer voices on the EMU10k1 I would add this line to /etc/modprobe.d/sound :
options snd-emu10k1 max_synth_voices=16
Please note that the exact name and location of the sounds file may vary between systems. It may also be necessary to add the requested options in /etc/modprobe.d/alsa-base. See your distribution's documentation for more specific details regarding the addition of module options.
Let's get back to the applications level. If a program fails to open at all, use the ldd command to see if its library dependencies are satisfied. This abbreviated report check the FST binary :
dlphilp@The3800:~/fst-1.8> ldd fst.exe.so linux-gate.so.1 => (0xffffe000) libgtk-x11-2.0.so.0 => /opt/gnome/lib/libgtk-x11-2.0.so.0 (0xb7bd4000) libgdk-x11-2.0.so.0 => /opt/gnome/lib/libgdk-x11-2.0.so.0 (0xb7b52000) ... libjack.so.0 => /usr/lib/libjack.so.0 (0xb76fe000) librt.so.1 => /lib/librt.so.1 (0xb76f5000) libasound.so.2 => /usr/lib/libasound.so.2 (0xb7641000) liblash.so.1 => /usr/lib/liblash.so.1 (0xb7636000) libwine.so.1 => /usr/local/lib/libwine.so.1 (0xb761a000) ...
If an entry is listed as not found then you're missing a required dependency. At that point you can use your system's package manager to find and install the missing component.
ALSA comes with some handy utilities, such as :
- alsaconfig - soundcard installation/configuration utility
- amixer/alsamixer - software soundcard mixer utilities
- alsactl - store and recall mixer settings
These tools are straightforward applications. Alsaconfig and alsamixer have character-graphics interfaces and are self-explanatory. The amixer command reports mixer element values with copious detail; see its man page for a list of its helpful switches for delimiting its output. The alsactl utility takes one of two command options (store/restore) and must be run with root privileges.
Your distribution's documentation may include helpful details regarding malfunctioning hardware or an obstinate software package, but at some point you may find yourself in need of greater assistance. If your problems are application-specific you should look for a dedicated wiki or forum, and if a search function is available you can look for previous mention of your problems. The list archives for the Linux Audio Developers and the Linux Audio Users groups contain a wealth of topics related to system analysis, diagnostics, and repair, the ALSA site and the unofficial ALSA wiki are likewise valuable resources, and Google can be a godsend whenn you're looking for users with prior experience.
Linux Music Makers
Okay, time to kick away from this nuts & bolts stuff, but alas, I've been too caught up in other matters and I haven't listened to any music for a while. You'll just have to hop over to Hans Fugal's LAM and check out some of the latest listings.
In my next entry I'll wrap up this troubleshooting series with a list of commonly-encountered problems and their typical solutions (employing the tools and programs encountered here, of course). Again, I encourage readers to send reports of their own tips and techniques, and I welcome suggestions for other tools and utilities I should consider adding to my Linux audio repair kit.
Similis sum folio de quo ludunt venti.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
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