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.
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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