Linux-HOWTOs.tar.gz/Sound-HOWTO

pkg://Linux-HOWTOs.tar.gz:1682658/Sound-HOWTO downloads

The Linux Sound HOWTO
Jeff Tranter, jeff_tranter@pobox.com
v1.17, 4 August 1997

This document describes sound support for Linux. It lists the sup
ported sound hardware, describes how to configure the kernel drivers,
and answers frequently asked questions. The intent is to bring new
users up to speed more quickly and reduce the amount of traffic in the
Usenet news groups and mailing lists.

1. Introduction

This is the Linux Sound HOWTO. It is intended as a quick reference
covering everything you need to know to install and configure sound
support under Linux. Frequently asked questions about sound under
Linux are answered, and references are given to some other sources of
information on a variety of topics related to computer generated sound
and music.

The scope is limited to the aspects of sound cards pertaining to
Linux. See the other documents listed in the References section for
more general information on sound cards and computer sound and music
generation.

1.1. Acknowledgments

Much of this information came from the documentation provided with the
sound driver source code, by Hannu Savolainen (hannu@voxware.pp.fi).
Thanks go to Hannu and the many other people who developed the Linux
kernel sound drivers and utilities.

Thanks to the SGML Tools package, this HOWTO is available in several
formats, all generated from a common source file.

1.2. Revision History

Version 1.1
first version; posted to SOUND channel of Linux activists
mailing list only

Version 1.2
minor updates; first version available on archive sites

Version 1.3
converted to SGML; now available in several formats using Matt
Welsh's Linuxdoc-SGML tools; appearance changed due to new
format, only minor changes to content

Version 1.4
minor tweaking of SGML; added answer on PAS16 and Adaptec1542A
SCSI adaptor incompatibilities

Version 1.5
2.5a sound driver is now in 1.1 kernel distribution; note on
GUS-MAX support; other minor updates
Version 1.6
added info on "no space on device" error; added note that
Hacker's Guide is in a "hidden" directory; added question on
bidirectional mode; info on "device busy" errors; other minor
changes

Version 1.7
added info on ASP and AWE32; VoxWare 2.9 is available; answer to
question on using IRQ2; references to Sound and SCSI HOWTOs

Version 1.8
added question on errors under DOS; many minor things updated to
match the version 2.90 sound driver; info on DOOM; answer on
reducing noise

Version 1.9
questions on recording and clone cards

Version 1.10
mentioned that HOWTO is available on WWW, as printed copies, and
translations; info on DMA conflict with QIC tape driver; info on
Sound Galaxy NX Pro and Logitech BusMouse

Version 1.11
A long overdue update (I've been busy); document placed under
GPL; brought up to date with version 3.0 sound driver; info on
many new supported sound card drivers; more info on
configuration and troubleshooting; lots of HTML links added;
brought in line with format of CD-ROM HOWTO

Version 1.12
new sound drivers in 1.3.34 kernel; new sound device names; 1542
address is 334 not 333; clarify status of Creative Labs Emu and
ASP; pointer to Creative Labs and MediaTrix Web sites

Version 1.13
note on the name VoxWare; updated to reflect latest supported
sound cards and configuration options; question on Plug and Play
support; question on block size problem; new xconfig and
menuconfig options; modutils has sound device support; vger
mailing list going away; emphasize author's Web site; other
miscellaneous minor changes

Version 1.14
Audio Excell DSP16 is not currently supported (should be working
again in a few months); changes to configure program; Italian
version of HOWTO available; trick for setting mixer gains when
loading sound module; latest stable kernel is now 2.0; new name
for sound driver; question on root permissions on sound device
files

Version 1.15
removed some questions that were very old and now obsolete; new
e-mail address for author; fixed some links to point to latest
software packages; more information on multimedia book; minor
spelling and grammatical changes

Version 1.16
many updates and corrections from Hannu Savolainen; added six
month "best before" date; new URL to web page for book; added
link to Spanish translation; minor spelling and grammatical
changes

Version 1.17
Chinese version available; alternate GUS driver; packet radio
modem; Linux Multimedia guide is now available in French and
Japanese; references to a couple of relevant mini-HOWTOs;
pointer for IBM ThinkPad

1.3. New versions of this document

New versions of this document will be periodically posted to the
comp.os.linux.answers newsgroup. They will also be uploaded to various
anonymous ftp sites that archive such information including
<ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/>.

Hypertext versions of this and other Linux HOWTOs are available on
many World-Wide-Web sites, including <http://sunsite.unc.edu/LDP/>.
Most Linux CD-ROM distributions include the HOWTOs, often under the
/usr/doc directory, and you can also buy printed copies from several
vendors. Sometimes the HOWTOs available from CD-ROM vendors, ftp
sites, and printed format are out of date. If the date on this HOWTO
is more than six months in the past, then a newer copy is probably
available on the Internet.

A French translation of this document is available at
<ftp://ftp.ibp.fr/pub2/linux/french/docs/HOWTO/>.

A Japanese translation is available from <http://yebisu.ics.es.osaka-
u.ac.jp/linux/>.

An Italian translation is available from
<http://www.psy.unipd.it/ildp/docs/HOWTO/Sound-HOWTO.html>.

A Spanish translation is available from
<http://www.insflug.nova.es/howtos/online/sonido/sonido-COMO.html>.

A Chinese translation is available from
<http://linux.ntcic.edu.tw/~yorkwu/linux/howto/sound/>.

Most translations of this and other Linux HOWTOs can also be found at
<http://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/> and
<ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/translations/>.

If you make a translation of this document into another language, let
me know and I'll include a reference to it here.

1.4. Feedback

I rely on you, the reader, to make this HOWTO useful. If you have any
suggestions, corrections, or comments, please send them to me,
jeff_tranter@pobox.com, and I will try to incorporate them in the next
revision.

I am also willing to answer general questions on sound cards under
Linux, as best I can. Before doing so, please read all of the
information in this HOWTO, and send me detailed information about the
problem. Please do not ask me about using sound cards under operating
systems other than Linux.

If you publish this document on a CD-ROM or in hardcopy form, a
complimentary copy would be appreciated. Mail me for my postal
address. Also consider making a donation to the Linux Documentation
Project to help support free documentation for Linux. Contact the
Linux HOWTO coordinator, Greg Hankins <mailto:gregh@sunsite.unc.edu>,
for more information.

1.5. Distribution Policy

This HOWTO is free documentation; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.

This document is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of
merchantability or fitness for a particular purpose. See the GNU
General Public License for more details.

You can obtain a copy of the GNU General Public License by writing to
the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
USA.

2. Sound Card Technology

This section gives a very cursory overview of computer audio
technology, in order to help you understand the concepts used later in
the document. You should consult a book on digital audio or digital
signal processing in order to learn more.

Sound is an analog property; it can take on any value over a
continuous range. Computers are digital; they like to work with
discrete values. Sound cards use a device known as an Analog to
Digital Converter (A/D or ADC) to convert voltages corresponding to
analog sound waves into digital or numeric values which can be stored
in memory. Similarly, a Digital to Analog Converter (D/A or DAC)
converts numeric values back to an analog voltage which can in turn
drive a loudspeaker, producing sound.

The process of analog to digital conversion, known as sampling,
introduces some error. Two factors are key in determining how well the
sampled signal represents the original. Sampling rate is the number of
samples made per unit of time (usually expresses as samples per second
or Hertz). A low sampling rate will provide a less accurate
representation of the analog signal. Sample size is the range of
values used to represent each sample, usually expressed in bits. The
larger the sample size, the more accurate the digitized signal will
be.

Sound cards commonly use 8 or 16 bit samples at sampling rates from
about 4000 to 44,000 samples per second. The samples may also be
contain one channel (mono) or two (stereo).

FM Synthesis is an older technique for producing sound. It is based on
combining different waveforms (e.g. sine, triangle, square). FM
synthesis is simpler to implement in hardware that D/A conversion, but
is more difficult to program and less flexible. Many sound cards
provide FM synthesis for backward compatibility with older cards and
software. Several independent sound generators or voices are usually
provided.

Wavetable Synthesis combines the flexibility of D/A conversion with
the multiple channel capability of FM synthesis. With this scheme
digitized voices can be downloaded into dedicated memory, and then
played, combined, and modified with little CPU overhead. State of the
art sound cards all support wavetable synthesis.

Most sound cards provide the capability of mixing, combining signals
from different input sources and controlling gain levels.

MIDI stands for Musical Instrument Digital Interface, and is a
standard hardware and software protocol for allowing musical
instruments to communicate with each other. The events sent over a
MIDI bus can also be stored as MIDI files for later editing and
playback. Many sound cards provide a MIDI interface. Those that do not
can still play MIDI files using the on-board capabilities of the sound
card.

MOD files are a common format for computer generated songs. As well
as information about the musical notes to be played, the files contain
digitized samples for the instruments (or voices). MOD files
originated on the Amiga computer, but can be played on other systems,
including Linux, with suitable software.

3. Supported Hardware

This section lists the sound cards and interfaces that are currently
supported under Linux. The information here is based on the latest
Linux kernels, at time of writing.

The sound driver has its own version numbering. The latest stable
Linux kernel release was version 2.0.30, using sound driver version
3.5.4-960630.

The author of the sound driver, Hannu Savolainen, typically also makes
available newer beta releases of the sound driver before they are
included as part of the standard Linux kernel distribution. The most
up to date list of supported cards is available at <http://www.4front-
tech.com/ossfree/new_cards.html> (USA) or
<http://personal.eunet.fi/pp/voxware/new_cards.html> (Europe). These
pages indicate which sound driver version is required for a given type
of sound card or if support for it is still under development. The
file /usr/src/linux/drivers/sound/Readme.cards distributed with the
kernel sound driver contains information on supported cards but it is
not always up to date.

The information in this HOWTO is valid for Linux on the Intel
platform.

The sound driver should also work with most sound cards on the Alpha
platform. However, some cards may conflict with I/O ports of other
devices on Alpha systems even though they work perfectly on i386
machines, so in general it's not possible to tell if a given card will
work or not without actually trying it.

At the time of writing the sound driver was not yet working on the
PowerPC version of Linux, but it should be supported in future.

It appears that sound can be configured into the kernel under the MIPs
port of Linux but I suspect it is not working (do MIPs machines even
have ISA slots?).
The Linux kernel includes a separate driver for the Atari and Amiga
versions of Linux that implements a compatible subset of the sound
driver on the Intel platform using the built-in sound hardware on
these machines.

The SPARC port of Linux does not currently have sound support (like
the Amiga and Atari, SPARC machines have built in sound hardware, so
it could be done with a new driver).

3.1. Sound Cards

The following sound cards are supported by the Linux kernel sound
driver:

· ATI Stereo F/X (no longer manufactured)

· AdLib (no longer manufactured)

· Ensoniq SoundScape (and compatibles made by Reveal and Spea)

· Gravis Ultrasound

· Gravis Ultrasound ACE

· Gravis Ultrasound Max

· Gravis Ultrasound with 16 bit sampling option

· Logitech Sound Man 16

· Logitech SoundMan Games

· Logitech SoundMan Wave

· MAD16 Pro (OPTi 82C928, 82C929, 82C930, 82C924 chipsets)

· Media Vision Jazz16

· MediaTriX AudioTriX Pro

· Microsoft Windows Sound System (MSS/WSS)

· Mozart (OAK OTI-601)

· Orchid SW32

· Personal Sound System (PSS)

· Pro Audio Spectrum 16

· Pro Audio Studio 16

· Pro Sonic 16

· Roland MPU-401 MIDI interface

· Sound Blaster 1.0

· Sound Blaster 16

· Sound Blaster 16ASP

· Sound Blaster 2.0

· Sound Blaster AWE32

· Sound Blaster Pro

· TI TM4000M notebook

· ThunderBoard

· Turtle Beach Tropez ("classic" but not Plus)

· Turtle Beach Maui

· Yamaha FM synthesizers (OPL2, OPL3 and OPL4)

· 6850 UART MIDI Interface

It should be noted that Plug and Play (PnP) sound cards are not fully
compatible with the older non-PnP models of the same device. For
example, the SoundBlaster16 PnP is not fully compatible with the
original SoundBlaster16. The same is true for the Soundscape PnP and
GUS PnP cards. More information related to Plug and Play is found
later in this document.

The following cards are not supported, either because they are
obsolete or because the vendor will not release the programming
information needed to write a driver:

· Pro Audio Spectrum (original)

· Pro Audio Spectrum+

· older (Sierra Aria based) sound cards made by Diamond

Other sound cards that are claimed to be compatible with one of the
supported sound cards may work if they are hardware (i.e. register
level) compatible.

Even though most sound cards are claimed to be "SoundBlaster
compatible", very few currently sold cards are compatible enough to
work with the Linux SoundBlaster driver. These cards usually work
better using the MSS/WSS or MAD16 driver. Only real SoundBlaster cards
made by Creative Labs, which use Creative's custom chips (e.g.
SoundBlaster16 Vibra), MV Jazz16 and ESS688/1688 based cards generally
work with the SoundBlaster driver. Trying to use a "SoundBlaster Pro
compatible 16 bit sound card" with the SoundBlaster driver is usually
just a waste of time.

The Linux kernel supports the SCSI port provided on some sound cards
(e.g. ProAudioSpectrum 16) and the proprietary interface for some CD-
ROM drives (e.g. Soundblaster Pro). See the Linux SCSI HOWTO and CDROM
HOWTO documents for more information.

A loadable kernel module to support joystick ports, including those
provided on some sound cards, is also available.

Note that the kernel SCSI, CD-ROM, joystick, and sound drivers are
completely independent of each other.

For the latest information on the sound card driver check Hannu
Savolainen's World-Wide Web site listed in the References section.

3.2. Alternate Sound Drivers

There are some "unofficial" sound drivers available, not included in
the standard Linux kernel distribution, and used in place of the
standard sound driver.

A commercial version of the Linux sound driver is sold by 4Front
Technologies. It offers a number of additional features over the free
version included in the Linux kernel. For more information see the
4Front Technologies Web page at <http://www.4front-tech.com/>.

Markus Mummert (mum@mmk.e-technik.tu-muenchen.de) has written a driver
package for the Turtle Beach MultiSound (classic), Tahiti, and
Monterey sound cards. The documentation states:

"It is designed for high quality hard disk record
ing/playback without losing sync even on a busy system.
Other features such as wave synthesis, MIDI and digital sig
nal processor (DSP) cannot be used. Also, recording and
playback at the same time is not possible. It currently
replaces VoxWare and was tested on several kernel versions
ranging from 1.0.9 to 1.2.1. Also, it is installable on UN*X
SysV386R3.2 systems."

It can be found at <http://www.cs.colorado.edu/~mccreary/tbeach>.

Kim Burgaard (burgaard@daimi.aau.dk) has written a device driver and
utilities for the Roland MPU-401 MIDI interface. The Linux software
map entry gives this description:

"A device driver for true Roland MPU-401 compatible MIDI
interfaces (including Roland SCC-1 and RAP-10/ATW-10). Comes
with a useful collection of utilities including a Standard
MIDI File player and recorder.

Numerous improvements have been made since version 0.11a.
Among other things, the driver now features IRQ sharing pol
icy and complies with the new kernel module interface.
Metronome functionality, possibility for synchronizing e.g.
graphics on a per beat basis without losing precision,
advanced replay/record/overdub interface and much, much
more."

It can be found at
<ftp://sunsite.unc.edu/pub/Linux/kernel/sound/mpu401-0.2.tar.gz>.

Jaroslav Kysela and others have written an alternate sound driver for
the Gravis UltraSound Card. Information can be found at
<http://romeo.pf.jcu.cz/~perex/ultra>, the home page of the Linux
UltraSound Project.

Another novel use for a sound card under Linux is as a modem for
amateur packet radio. The recent 2.1.x kernels include a driver that
works with SoundBlaster and Windows Sound System compatible sound
cards to implement 1200 bps AFSK and 9600 bps FSK packet protocols.
See the Linux AX25 HOWTO for details (I'm a ham myself, by the way --
callsign VE3ICH).

3.3. PC Speaker

An alternate sound driver is available that requires no additional
sound hardware; it uses the internal PC speaker. It is mostly software
compatible with the sound card driver, but, as might be expected,
provides much lower quality output and has much more CPU overhead. The
results seem to vary, being dependent on the characteristics of the
individual loudspeaker. For more information, see the documentation
provided with the release.

The current version is 1.1, and can be found at
<ftp://ftp.informatik.hu-berlin.de/pub/os/linux/hu-sound/>

3.4. Parallel Port

Another option is to build a digital to analog converter using a
parallel printer port and some additional components. This provides
better sound quality than the PC speaker but still has a lot of CPU
overhead. The PC sound driver package mentioned above supports this,
and includes instructions for building the necessary hardware.

4. Installation

Configuring Linux to support sound involves the following steps:

1. Installing the sound card.

2. Configuring and building the kernel for sound support.

3. Creating the device files.

4. Booting the Linux kernel and testing the installation.

The next sections will cover each of these steps in detail.

4.1. Installing the Sound Card

Follow the manufacturer's instructions for installing the hardware or
have your dealer perform the installation.

Older sound cards usually have switch or jumper settings for IRQ, DMA
channel, etc; note down the values used. If you are unsure, use the
factory defaults. Try to avoid conflicts with other devices (e.g.
ethernet cards, SCSI host adaptors, serial and parallel ports) if
possible.

Usually you should use the same I/O port, IRQ, and DMA settings that
work under DOS. In some cases though (particularly with PnP cards) you
may need to use different settings to get things to work under Linux.
Some experimentation may be needed.

4.2. Configuring the Kernel

When initially installing Linux you likely used a precompiled kernel.
These kernels usually do not provide sound support. It is best to
recompile the kernel yourself with the drivers you need. You may also
want to recompile the kernel in order to upgrade to a newer version or
to free up memory resources by minimizing the size of the kernel.

The Linux Kernel HOWTO <http://sunsite.unc.edu/LDP/HOWTO/Kernel-
HOWTO.html> should be consulted for the details of building a kernel.
I will just mention here some issues that are specific to sound cards.

If you have never configured the kernel for sound support before it is
a good idea to read all of the Readme files included with the kernel
sound drivers, particularly information specific to your card type.
The following documentation files can be found in the kernel sound
driver directory, usually installed in /usr/src/linux/drivers/sound:

CHANGELOG - description of changes in each release
COPYING - copying and copyright restrictions
Readme - latest and most important news
Readme.aedsp16 - information about Audio Excel DSP 16 sound card
Readme.cards - notes on configuring specific cards
Readme.linux - notes on installing separately release sound drivers
Readme.modules - how to build driver as a loadable kernel module
Readme.v30 - new features in version 3.0 sound driver
experimental.txt - notes on experimental features

Follow the usual procedure for building the kernel. There are
currently three interfaces to the configuration process. A graphical
user interface that runs under X11 can be invoked using "make
xconfig". A menu-based system that only requires text displays is
available as "make menuconfig". The original method, using "make
config", offers a simple text-based interface.

Special care must be taken when using "make xconfig" or "make
menuconfig". All Yes/No questions must be examined carefully. The
default answer provided by these commands is always No which is not
the proper one in all cases. In particular the "/dev/dsp and
/dev/audio support" (CONFIG_AUDIO) option should usually be enabled.

In this document I will assume that you use the traditional command
line configuration process invoked using "make config", although the
process is similar in each case.

There are also two different ways to configure sound. The first is the
"old" way (the only one offered prior to the 2.0.0 kernels). It uses a
standalone configuration program that is part of the sound driver.
This method works with most sound cards except the rare few that
require additional "low level" drivers (miroSOUND, AWE32, and AEDSP16
cards).

The second is the "new" method which is better integrated with the
menu-based configuration used for the rest of the kernel. This one
doesn't work with sound cards that require a firmware download file.
This includes the PSS, SM Wave, AudioTrix Pro and TurtleBeach
Tropez/Maui cards. With these cards the old method has to be used.

The "new" method is always used by "make xconfig". When using "make
menuconfig" you can select between the "old" and "new" methods in the
sound subscreen. When using "make config" you get the "old" method by
default. However if you have used the "new" method once, it will be
used by "make config" too. You can switch back to the "old" method by
running "make menuconfig" and by selecting the "old" one.

The recommended method is to use "make menuconfig" together with the
"old" sound config method. Many sound configuration problems are
caused (at least partly) by incorrect use of the "new" method.
It is also possible to build the sound driver as a kernel loadable
module. I recommend initially building the driver into the kernel.
Once it is tested and working you can explore using the kernel module
option.

When you run make config, enable sound support by answering "y" to the
question

Sound card support (CONFIG_SOUND) [M/n/y/?]

At the end of the configuration questions a sound configuration
program will be compiled, run, and will then ask you what sound card
options you want. Be careful when answering these questions since
answering a question incorrectly may prevent some later ones from
being asked. For example, don't answer "yes" to the first question
(PAS16) if you don't really have a PAS16. Don't enable more cards than
you really need, since they just consume memory. Also some drivers
(like MPU-401) may conflict with your SCSI controller and prevent the
kernel from booting.

I list here a brief description of each of the configuration dialog
options. Answer "y" (yes) or "n" (no) to each question. The default
answer is shown so that "Y/n/?" means "y" by default and "N/y/?"
means the default is "n". To use the default value, just hit Enter,
but remember that the default value isn't necessarily correct.

Entering a question mark ("?") will produce a short descriptive
message describing that configuration option.

Note also that all questions may not be asked. The configuration
program may disable some questions depending on the earlier choices.
It may also select some options automatically as well.

Old configuration exists in /etc/soundconf. Use it Y/n/?
If you have previously compiled the kernel for sound support,
then the previous configuration can be saved. If you want to use
the previous setup, answer "y". If you are trying a different
configuration or have upgraded to a newer kernel, you should
answer "n" and go through the configuration process.

ProAudioSpectrum 16 support Y/n/?
Answer "y" only if you have a Pro Audio Spectrum 16, ProAudio
Studio 16 or Logitech SoundMan 16. Don't answer 'y' if you have
some other card made by Media Vision or Logitech since they are
not PAS16 compatible.

SoundBlaster support Y/n/?
Answer "y" if you have an original SoundBlaster card made by
Creative Labs or a 100% hardware compatible clone (like the
Thunderboard or SM Games). If your card was in the list of
supported cards look at the card specific instructions in the
Readme.cards file before answering this question. For an unknown
card you may answer "y'"if the card claims to be SoundBlaster
compatible.

Gravis Ultrasound support Y/n/?
Answer "y" if you have a GUS or GUS MAX. Answer "n" if you don't
have a GUS since the driver consumes a lot of memory.

MPU-401 support (NOT for SB16) Y/n/?
Be careful with this question. The MPU-401 interface is
supported by almost all sound cards. However, some natively
supported cards have their own driver for MPU-401. Enabling the
MPU-401 option with these cards will cause a conflict. Also
enabling MPU-401 on a system that doesn't really have a MPU-401
could cause some trouble. If your card was in the list of
supported cards, look at the card specific instructions in the
Readme.cards file. It's safe to answer "y" if you have a true
MPU-401 MIDI interface card.

6850 UART Midi support Y/n/?
It's safe to answer "n" to this question in all cases. The 6850
UART interface is very rarely used.

PSS (ECHO-ADI2111) support Y/n/?
Answer "y" only if you have Orchid SW32, Cardinal DSP16 or some
other card based on the PSS chipset (AD1848 codec + ADSP-2115
DSP chip + Echo ESC614 ASIC CHIP).

16 bit sampling option of GUS (not GUS MAX) Y/n/?
Answer "y" if you have installed the 16 bit sampling
daughtercard on your GUS. Answer "n" if you have a GUS MAX.
Enabling this option disables GUS MAX support.

GUS MAX support Y/n/?
Answer "y" only if you have a GUS MAX.

Microsoft Sound System support Y/n/?
Again think carefully before answering "y" to this question.
It's safe to answer "y" if you have the original Windows Sound
System card made by Microsoft or Aztech SG 16 Pro (or NX16 Pro).
Also you may answer "y" in case your card was not listed earlier
in this file. For cards having native support in VoxWare,
consult the card specific instructions in Readme.cards. Some
drivers have their own MSS support and enabling this option will
cause a conflict.

Ensoniq Soundscape support Y/n/?
Answer "y" if you have a sound card based on the Ensoniq
SoundScape chipset. Such cards are being manufactured at least
by Ensoniq, Spea and Reveal (Reveal makes other cards also).

MediaTriX AudioTriX Pro support Y/n/?
Answer "y" if you have the AudioTriX Pro.

Support for MAD16 and/or Mozart based cards?
Answer "y" if your card has a Mozart (OAK OTI-601) or MAD16
(OPTi 82C928 or 82C929) audio interface chip. These chips are
currently quite common so it's possible that many no-name cards
have one of them. In addition the MAD16 chip is used in some
cards made by known manufacturers such as Turtle Beach (Tropez),
Reveal (some models) and Diamond (latest ones).
Support for Crystal CS4232 based (PnP) cards Y/n/?
Answer "y" if you have a card based on the Crystal CS4232 chip
set.

Support for Turtle Beach Wave Front (Maui, Tropez) synthesizers
Y/n/?" Answer "y" if you have any of these cards.

SoundBlaster Pro support Y/n/?
Enable this option if your card is a SoundBlaster Pro or
SoundBlaster 16. Enable it also with any SoundBlaster Pro
clones. Answering "n" saves some memory but "y" is the safe
alternative.

SoundBlaster 16 support Y/n/?
Enable if you have a SoundBlaster 16 (including the AWE32).

Audio Excel DSP 16 initialization support Y/n/?
Enable this if you have an Audio Excel DSP16 card. See the file
Readme.aedsp16 for more information.

The configuration program then asks some questions about the higher
level services. It's recommended to answer "y" to each of these
questions. Answer "n" only if you know you will not need the option.

/dev/dsp and /dev/audio support (usually required) Y/n/?
Answering "n" disables /dev/dsp and /dev/audio, the A/D and D/A
converter devices. Answer "y".

MIDI interface support Y/n/?
Answering "n" disables /dev/midixx devices and access to any
MIDI ports using /dev/sequencer and /dev/music. This option also
affects any MPU-401 and/or General MIDI compatible devices.

FM synthesizer (YM3812/OPL-3) support Y/n/?
Answer "y" here.

/dev/sequencer support Y/n/?
Answering "n" disables /dev/sequencer and /dev/music

Do you want support for the mixer of SG NX Pro ?
Answer "y" if you have a Sound Galaxy NX Pro sound card and want
support for its extended mixer functions.

Do you want support for the MV Jazz16 (ProSonic etc.) ?
Answer "y" if you have an MV Jazz16 sound card.

Do you have a Logitech SoundMan Games Y/n/?
Answer "y" if you have a Logitech SoundMan Games sound card.

After the above questions the configuration program prompts for the
card specific configuration information. Usually just a set of I/O
address, IRQ and DMA numbers are asked. With some cards the program
asks for some files to be used during initialization of the card.
These are used by cards which have a DSP chip or microprocessor which
must be initialized by downloading a program (microcode) file to the
card. In some cases this file is written to a .h file by the config
program and then included to the driver during compile. Again, read
the information in the file Readme.cards pertaining to your card type.

At the end you will be prompted:

The sound driver is now configured.
Save copy of this configuration to /etc/soundconf [Y/n/?]

Normally you would enter "y" so that if you later need to recompile
the kernel you have the option of using the same sound driver
configuration.

If you are upgrading from an older sound driver, make sure that the
files /usr/include/sys/soundcard.h and /usr/include/sys/ultrasound.h
are symbolic links to the corresponding files in /usr/include/linux,
or that they simply contain the lines #include <linux/soundcard.h> and
#include <linux/ultrasound.h>, respectively.

You are now ready to compile and install the new kernel.

4.3. Creating the Device Files

For proper operation, device file entries must be created for the
sound devices. These are normally created for you during installation
of your Linux system. A quick check can be made using the command
listed below. If the output is as shown (the date stamp will vary)
then the device files are almost certainly okay.

% ls -l /dev/sdnstat
crw-rw-rw- 1 root root 14, 6 Apr 25 1995 /dev/sndstat

Note that having the right device files there doesn't guarantee
anything on its own. The kernel driver must also be loaded or compiled
in before the devices will work (more on that later).

In rare cases, if you believe the device files are wrong, you can
recreate them using the short shell script from the end of the file
Readme.linux in the directory /usr/src/linux/drivers/sound, running it
as user root. Alternatively, most Linux distributions have a
/dev/MAKEDEV script which can be used for this purpose.

If you are using the PC speaker sound driver, read the documentation
that came with the package to determine if any device files need to be
created.

4.4. Booting Linux and Testing the Installation

You should now be ready to boot the new kernel and test the sound
drivers. Follow your usual procedure for installing and rebooting the
new kernel (keep the old kernel around in case of problems, of
course).

During booting, check for a message such as the following on powerup
(if they scroll by too quickly to read, you may be able to retrieve
them with the dmesg command):

Sound initialization started
<Sound Blaster 16 (4.13)> at 0x220 irq 5 dma 1,5
<Sound Blaster 16> at 0x330 irq 5 dma 0
<Yamaha OPL3 FM> at 0x388
Sound initialization complete

This should match your sound card type and jumper settings (if any).

Note that the above messages are not displayed when using loadable
sound driver module (unless you enable it, e.g. using "insmod sound
trace_init=1).

When the sound driver is linked into the kernel, the "Sound
initialization started" and "Sound initialization complete" messages
should be displayed. If they are not printed, it means that there is
no sound driver present in the kernel. In this case you should check
that you actually installed the kernel you compiled when enabling the
sound driver.

If nothing is printed between the "Sound initialization started" and
the "Sound initialization complete" lines, it means that no sound
devices were detected. Most probably it means that you don't have the
correct driver enabled, the card is not supported, the I/O port is bad
or that you have a PnP card that has not been configured.

The driver may also display some error messages and warnings during
boot. Watch for these when booting the first time after configuring
the sound driver.

Next you should check the device file /dev/sndstat. Reading the sound
driver status device file should provide additional information on
whether the sound card driver initialized properly. Sample output
should look something like this:

% cat /dev/sndstat
Sound Driver:3.5.4-960630 (Sat Jan 4 23:56:57 EST 1997 root,
Linux fizzbin 2.0.27 #48 Thu Dec 5 18:24:45 EST 1996 i586)
Kernel: Linux fizzbin 2.0.27 #48 Thu Dec 5 18:24:45 EST 1996 i586
Config options: 0

Installed drivers:
Type 1: OPL-2/OPL-3 FM
Type 2: Sound Blaster
Type 7: SB MPU-401

Card config:
Sound Blaster at 0x220 irq 5 drq 1,5
SB MPU-401 at 0x330 irq 5 drq 0
OPL-2/OPL-3 FM at 0x388 drq 0

Audio devices:
0: Sound Blaster 16 (4.13)

Synth devices:
0: Yamaha OPL-3

Midi devices:
0: Sound Blaster 16

Timers:
0: System clock

Mixers:
0: Sound Blaster

The command above can report some error messages. "No such file or
directory" indicates that you need to create the device files (see
section 4.3). "No such device" means that sound driver is not loaded
or linked into kernel. Go back to section 4.2 to correct this.

If lines in the "Card config:" section of /dev/sndstat are listed
inside parentheses (such as "(SoundBlaster at 0x220 irq 5 drq 1,5)"),
it means that this device was configured but not detected.

Now you should be ready to play a simple sound file. Get hold of a
sound sample file, and send it to the sound device as a basic check of
sound output, e.g.

% cat endoftheworld >/dev/dsp
% cat crash.au >/dev/audio

(Make sure you don't omit the ">" in the commands above).

Note that, in general, using cat is not the proper way to play audio
files, it's just a quick check. You'll want to get a proper sound
player program (described later) that will do a better job.

This command will work only if there is at least one device listed in
the audio devices section of /dev/sndstat. If the audio devices
section is empty you should check why the device was not detected.

If the above commands return "I/O error", you should look at the end
of the kernel messages listed using the "dmesg" command. It's likely
that an error message is printed there. Very often the message is
"Sound: DMA (output) timed out - IRQ/DRQ config error?". The above
message means that the driver didn't get the expected interrupt from
the sound card. In most cases it means that the IRQ or the DMA channel
configured to the driver doesn't work. The best way to get it working
is to try with all possible DMAs and IRQs supported by the device.

Another possible reason is that the device is not compatible with the
device the driver is configured for. This is almost certainly the case
when a supposedly "SoundBlaster (Pro/16) compatible" sound card
doesn't work with the SoundBlaster driver. In this case you should try
to find out the device your sound card is compatible with (by posting
to the comp.os.linux.hardware newsgroup, for example).

Some sample sound files can be obtained from
<ftp://tsx-11.mit.edu/pub/linux/packages/sound/snd-data-0.1.tar.Z>

Now you can verify sound recording. 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
EDT% dd bs=8k count=4 </dev/audio >sample.au
4+0 records in
4+0 records out
# play back sound
% cat sample.au >/dev/audio

Obviously for this to work you need a microphone connected to the
sound card and you should speak into it. You may also need to obtain a
mixer program to set the microphone as the input device and adjust the
recording gain level.

If these tests pass, you can be reasonably confident that the sound
D/A and A/D hardware and software are working. If you experience
problems, refer to the next section of this document.

4.5. Troubleshooting

If you still encounter problems after following the instructions in
the HOWTO, here are some things to check. The checks are listed in
increasing order of complexity. If a check fails, solve the problem
before moving to the next stage.

4.5.1. Step 1: Make sure you are really running the kernel you com
piled.

You can check the date stamp on the kernel to see if you are running
the one that you compiled with sound support. You can do this with the
uname command:

% uname -a
Linux fizzbin 2.0.0 #1 Tue Jun 4 16:57:55 EDT 1996 i386

or by displaying the file /proc/version:

% cat /proc/version
Linux version 2.0.0 (root@fizzbin) (gcc version 2.7.0) #1 Tue Jun 4 16:57:55 EDT 1996

If the date stamp doesn't seem to match when you compiled the kernel,
then you are running an old kernel. Did you really reboot? If you use
LILO, did you re-install it (typically by running /etc/lilo/install)?
If booting from floppy, did you create a new boot floppy and use it
when booting?

4.5.2. Step 2: Make sure the kernel sound drivers are compiled in.

The easiest way to do this is to check the output of "dev/sndstat" as
described earlier. If the output is not as expected then something
went wrong with the kernel configuration or build. Start the
installation process again, beginning with configuration and building
of the kernel.

4.5.3. Step 3: Did the kernel detect your sound card during booting?

Make sure that the sound card was detected when the kernel booted. You
should have seen a message on bootup. If the messages scrolled off the
screen, you can usually recall them using the dmesg command:

% dmesg

% tail /var/adm/messages

If your sound card was not found then something is wrong. Make sure it
really is installed. If the sound card works under DOS then you can be
reasonably confident that the hardware is working, so it is likely a
problem with the kernel configuration. Either you configured your
sound card as the wrong type or wrong parameters, or your sound card
is not compatible with any of the Linux kernel sound card drivers.

One possibility is that your sound card is one of the "compatible"
type that requires initialization by the DOS driver. Try booting DOS
and loading the vendor supplied sound card driver. Then soft boot
Linux using Control-Alt-Delete. Make sure that card I/O address, DMA,
and IRQ settings for Linux are the same as used under DOS. Read the
Readme.cards file from the sound driver source distribution for hints
on configuring your card type.

If your sound card is not listed in this document, it is possible that
the Linux drivers do not support it. You can check with some of the
references listed at the end of this document for assistance.

4.5.4. Step 4: Can you read data from the dsp device?

Try reading from the /dev/audio device using the dd command listed
earlier in this document. The command should run without errors.

If it doesn't work, then chances are that the problem is an IRQ or DMA
conflict or some kind of hardware incompatibility (the device is not
supported by Linux or the driver is configured for a wrong device).

A remote possibility is broken hardware. Try testing the sound card
under DOS, if possible, to eliminate that as a possibility.

4.5.5. When All Else Fails

If you still have problems, here are some final suggestions for things
to try:

· carefully re-read this HOWTO document

· read the references listed at the end of this document, especially
Hannu Savolainen's web pages and the relevant kernel source Readme
files

· post a question to one of the comp.os.linux or other Usenet
newsgroups (comp.os.linux.hardware is a good choice; because of the
high level of traffic in these groups it helps to put the string
"sound" in the subject header for the article so the right experts
will see it)

· Using a Web/Usenet search engine with an intelligently selected
search criteria can give very good results quickly. One such choice
is <http://www.altavista.digital.com>

· try using the latest Linux kernel (but only as a last resort, the
latest development kernels can be unstable)

· send mail to the author of the sound driver

· send mail to the author of the Sound HOWTO

· fire up emacs and type Esc-x doctor :-)

5. Applications Supporting Sound

I give here a sample of the types of applications that you likely want
if you have a sound card under Linux. You can check the Linux Software
Map, Internet archive sites, and/or files on your Linux CD-ROM for
more up to date information.

As a minimum, you will likely want to obtain the following sound
applications:

· audio file format conversion utility (e.g. Sox)

· mixer utility (e.g. aumix or xmix)

· digitized file player/recorder (e.g. play or wavplay)

· MOD file player (e.g. tracker)

· MIDI file player (e.g. playmidi)

There are text-based as well as GUI-based versions of most of these
tools. There are also some more esoteric applications (e.g. speech
synthesis and recognition) that you may wish to try.

6. Answers To Frequently Asked Questions

This section answers some of the questions that have been commonly
asked on the Usenet news groups and mailing lists.

Answers to more questions can also be found at the OSS sound driver
web page.

6.1. What are the various sound device files?

These are the most "standard" device file names, some Linux
distributions may use slightly different names.

/dev/audio
normally a link to /dev/audio0

/dev/audio0
Sun workstation compatible audio device (only a partial
implementation, does not support Sun ioctl interface, just u-law
encoding)

/dev/audio1
second audio device (if supported by sound card or if more than
one sound card installed)

/dev/dsp
normally a link to /dev/dsp0

/dev/dsp0
first digital sampling device

/dev/dsp1
second digital sampling device

/dev/mixer
normally a link to /dev/mixer0

/dev/mixer0
first sound mixer

/dev/mixer1
second sound mixer

/dev/music
high-level sequencer interface

/dev/sequencer
low level MIDI, FM, and GUS access

/dev/sequencer2
normally a link to /dev/music

/dev/midi00
1st raw MIDI port

/dev/midi01
2nd raw MIDI port

/dev/midi02
3rd raw MIDI port

/dev/midi03
4th raw MIDI port

/dev/sndstat
displays sound driver status when read

The PC speaker driver provides the following devices:

/dev/pcaudio
equivalent to /dev/audio

/dev/pcsp
equivalent to /dev/dsp

/dev/pcmixer
equivalent to /dev/mixer

6.2. How can I play a sound sample?

Sun workstation (.au) sound files can be played by sending them to the
/dev/audio device. Raw samples can be sent to /dev/dsp. This will
generally give poor results though, and using a program such as play
is preferable, as it will recognize most file types and set the sound
card to the correct sampling rate, etc.

Programs like wavplay or vplay (in the snd-util package) will give
best results with WAV files. However they don't recognize Microsoft
ADPCM compressed WAV files. Also older versions of play (from the Lsox
package) doesn't work well with 16 bit WAV files.

The splay command included in the snd-util package can be used to play
most sound files if proper parameters are entered manually in the
command line.

6.3. How can I record a sample?

Reading /dev/audio or /dev/dsp will return sampled data that can be
redirected to a file. A program such as vrec makes it easier to
control the sampling rate, duration, etc. You may also need a mixer
program to select the appropriate input device.

6.4. Can I have more than one sound card?

With the current sound driver it's possible to have several
SoundBlaster, SoundBlaster/Pro, SoundBlaster16, MPU-401 or MSS cards
at the same time on the system. Installing two SoundBlasters is
possible but requires defining the macros SB2_BASE, SB2_IRQ, SB2_DMA
and (in some cases) SB2_DMA2 by editing local.h manually. It's also
possible to have a SoundBlaster at the same time as a PAS16.

The following drivers don't permit multiple instances:

· GUS (driver limitation)

· MAD16 (hardware limitation)

· AudioTrix Pro (hardware limitation)

· CS4232 (hardware limitation)

6.5. Error: No such file or directory for sound devices

You need to create the sound driver device files. See the section on
creating device