Linux Sound Support
With the availability of Linux and low-cost sound hardware for Intel-based PCs, a sound-capable Unix system is within the reach of most computer hobbyists.
Possibly because sound support was lacking in Unix systems, many new users are confused by the technical jargon specific to sound and electronic music, and the many sound cards available. This article will to explain what can be done with sound under Linux, unravel some of the technical terms, and point the reader to sources of more information.
The typical sound card hardware provides the capability for one or more of the following functions:
playing and recording digitized sound samples
playing music from an audio Compact Disc in a CD-ROM drive
generating sounds using an internal FM synthesizer
controlling external MIDI (Musical Instrument Digital Interface) devices
miscellaneous functions, such as providing a joystick interface, SCSI disk interface, volume and tone controls, and facilities for mixing of inputs
For digitized sounds, there are two basic parameters that determine the sound quality: sampling rate and sample size.
The sampling rate is the speed at which the analog waveform is converted to digital “samples”. This is expressed in samples per second, or more often (and less accurately), Hertz. The sample size indicates the number of data bits which are stored for each sample; the more bits, the more accurately the sample represents the original waveform. Sounds can also be recorded with one channel (mono) or two channels (stereo). Various coding schemes are used to represent the sample as a numerical value.
As an example, a low-cost sound card can produce single channel, 8-bit samples at 8000 samples per second. This provides sound quality comparable to the telephone network. A 16-bit sound card producing stereo sound at 44100 samples/second is equivalent to Compact Disc audio quality (ignoring issues such as noise and distortion).
Some sound cards also provide hardware for producing sounds using FM synthesis. This technique is based on modifying sine waves. The advantage of this scheme is that the hardware is reasonably simple and not much computing power is required. The disadvantage is that it is difficult to determine the parameters needed to produce specific sounds (e.g., a piano).
Sound cards also typically provide other miscellaneous features, including joystick ports, CD-ROM interface, SCSI interface, MIDI port, facilities for sound input and output, and volume and tone controls.
The Linux kernel currently supports the following sound cards:
Roland MPU-401 MIDI interface
SoundBlaster and compatibles (including ThunderBoard and Ati Stereo F/X)
The Linux kernel also supports the SCSI port provided on some sound cards (e.g., ProAudioSpectrum 16) and the CD-ROM interface provided on the Soundblaster Pro and SoundBlaster 16.
For those who do not (yet) have sound hardware, there are a couple of other options. With a little hardware, a sound interface can be built using the parallel printer port. For a zero-cost solution, there is even a sound driver for the internal speaker of your PC. The driver is compatible with the sound card driver, but the quality may leave something to be desired.
Setting up Linux to support a sound card involves the following steps:
installing the sound card
configuring and building the kernel with the sound drivers
creating the sound device files
testing the installation
The first requirement, if you have not already done so, is to install the sound card. Follow the instructions provided by the manufacturer. Be sure to note down the jumper settings for IRQ, DMA channel, and so on; if you are unsure, use the factory defaults. Try to avoid conflicts with other devices (e.g., Ethernet cards) if possible. You will also need speakers, and a microphone if you want to do any recording. A math co-processor is also useful for some sound applications (e.g., changing file formats, adding effects or speech synthesis), but not necessary.
The next step is to configure the Linux kernel. If you are using a recent version (0.99 patch level 14 or later), the sound drivers are included with the kernel release. Follow your usual procedure for building the kernel. When you configure the kernel, enable the sound driver, and answer the questions about sound card settings when prompted by the configure program.
Once the kernel is configured, you need to create the sound device files. The easiest way to do this is to cut the short shell script from the end of the file /usr/src/linux/drivers/sound/Readme.linux, and run it as root. These are the files that will be created:
/dev/audio- Sun workstation compatible audio device (read/write)
/dev/dsp- digital sampling device (read/write)
/dev/mixer- sound mixer
/dev/sequencer- MIDI, FM, and GUS synthesizer access
/dev/midi- MIDI device (not yet implemented in current sound driver)
/dev/sndstat- displays sound driver status when read
/dev/audio1- for second sound card
/dev/dsp1- for second sound card
If you are using the PC speaker sound driver, then it will use the following devices:
/dev/pcaudio- equivalent to /dev/audio
/dev/pcsp- equivalent to /dev/dsp
/dev/pcmixer- equivalent to /dev/mixer
Now that the kernel is configured and the device files created, you can verify the sound hardware and software. Follow your usual procedure for installing and rebooting the new kernel. (Keep the old kernel around in case of problems, of course.) Verify that sound card is recognized during kernel initialization. You should see a message such as the following on powerup:
snd2 <SoundBlaster Pro 3.2> at 0x220 irq 5 drq 1
snd1 <Yamaha OPL-3 FM> at 0x388 irq 0 drq 0
This should match your sound card type and jumper settings. The driver may also display some error messages and warnings during boot up. Watch for these when booting the first time after configuring the sound driver.
If no sound card is detected when booting, there are a couple of possible reasons. The configuration of the driver could be incorrect and the driver was not able to detect your card in the given I/O address. Another common error is not having the sound driver in the kernel, because you booted with an old kernel instead of the one that was just compiled.
Reading the sound driver status device file provides additional information on whether the sound card driver initialized properly. Sample output should look something like this:
% cat /dev/sndstat Sound Driver:2.4 (Sun Feb 13 14:49:20 EST 1994 firstname.lastname@example.org) Config options: 1aa2 HW config: Type 2: SoundBlaster at 0x220 irq 5 drq 1 Type 1: AdLib at 0x388 irq 0 drq 0 PCM devices: 0: SoundBlaster Pro 3.2 Synth devices: 0: Yamaha OPL-3 Midi devices: 0: SoundBlaster Mixer(s) installed
If the cat command displays “No such device”, then the sound driver is not active in the kernel. If the printout contains no devices (PCM, Synth or Midi), then your sound card was not detected. Verify that you entered the correct information when configuring the sound driver.
Now you should be ready to play a sample sound file, and send it to the sound device as a basic check of sound output, for example,
% cat endoftheworld >/dev/dsp % cat crash.au >/dev/audio
Some sample sound files can be obtained from the file snd-data-0.1.tar.Z, available on many Linux archive sites.
If you have sound input capability, you can do a quick test of this using commands such as the following:
# record 4 seconds of audio from microphone % dd bs=8k count=4 </dev/audio >sample.au # play back sound % cat sample.au >/dev/audio
If these tests pass, you can be reasonably confident that the sound hardware and software are working. If you experience problems, consult one of the references listed at the end of this article.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- Purism Librem 13 Review