Previous Next Contents Main Page

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.

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)

/dev/dsp

normally a link to /dev/dsp0

/dev/dsp0

first digital sampling device

/dev/dsp1

second digital sampling device

/dev/mixer

sound mixer

/dev/mixer1

second sound mixer

/dev/music

high-level sequencer interface

/dev/patmgr0

Patch Manager

/dev/patmgr1

Patch Manager

/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. 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.

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?

Up to two sound cards is supported. It's possible to install a Gravis UltraSound or MPU-401 with a SoundBlaster, SoundBlaster Pro, SoundBlaster16 or ProAudioSpectrum16. It's not possible to have a ProAudioSpectrum16 and SoundBlaster at the same time (the PAS16 has an SB emulator in it). It's also not possible to have more than one card of the same type at the same time -- for example, a GUS + GUS combination is not possible.

You can change the sound card configuration parameters at boot time using command line options from a boot loader such as LILO. See the kernel sound driver file Readme.linux for details.

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 files. If you do have the device files, ensure that they have the correct major and minor device numbers (some older CD-ROM distributions of Linux may not create the correct device files during installation).

6.6 Error: No such device for sound devices

You have not booted with a kernel containing the sound driver or the I/O address configuration doesn't match your hardware. Check that you are running the newly compiled kernel and verify that the settings entered when configuring the sound driver match your hardware setup.

6.7 Error: No space left on device for sound devices

This can happen if you tried to record data to /dev/audio or /dev/dsp without creating the necessary device file. The sound device is now a regular file, and has filled up your disk partition. You need to run the script described in the Creating the Device Files section of this document.

6.8 Error: Device busy for sound devices

Only one process can open a given sound device at one time. Most likely some other process is using the device in question. One way to determine this is to use the fuser command:

% fuser -v /dev/dsp
/dev/dsp:             USER       PID ACCESS COMMAND
                      tranter    265 f....  tracker

In the above example, the fuser command showed that process 265 had the device open. Waiting for the process to complete or killing it will allow the sound device to be accessed once again.

6.9 I still get device busy errors!

According to Brian Gough, for the SoundBlaster cards which use DMA channel 1 there is a potential conflict with the QIC-02 tape driver, which also uses DMA 1, causing "device busy" errors. If you are using FTAPE, you may have this driver enabled. According to the FTAPE-HOWTO the QIC-02 driver is not essential for the use of FTAPE; only the QIC-117 driver is required. Reconfiguring the kernel to use QIC-117 but not QIC-02 allows FTAPE and the sound-driver to coexist.

(the following explanation was supplied by Harald Albrecht [email protected])

Some soundcards support using DMA channel 0. The sound driver configuration program allows this, and the kernel compiles properly, but accessing the sound device results in a "device busy" error message.

The reason is that the Linux kernel reserves DMA channel 0 for DRAM refresh. This is no longer true for modern 386/486 boards which use their own refresh logic. You can correct it by changing this line in the file /usr/src/linux/kernel/dma.c:

static volatile unsigned int dma_chan_busy[MAX_DMA_CHANNELS] = {
                1, 0, 0, 0, 1, 0, 0, 0
};

Replace the first 1 with a 0; this enables DMA channel 0. Don't do the same with DMA channel 4 as this is cascade and won't work! The code should now look like this:

static volatile unsigned int dma_chan_busy[MAX_DMA_CHANNELS] = {
                0, 0, 0, 0, 1, 0, 0, 0
};

Recompile and reboot with the new kernel.

6.10 Partial playback of digitized sound file

The symptom is usually that a sound sample plays for about a second and then stops completely or reports an error message about "missing IRQ" or "DMA timeout". Most likely you have incorrect IRQ or DMA channel settings. Verify that the kernel configuration matches the sound card jumper settings and that they do not conflict with some other card.

Another symptom is sound samples that "loop". This is usually caused by an IRQ conflict.

6.11 There are pauses when playing MOD files

Playing MOD files requires considerable CPU power. You may have too many processes running or your computer may be too slow to play in real time. Your options are to:

If you have a Gravis UltraSound card, you should use one of the mod file players written specifically for the GUS (e.g. gmod).

6.12 Compile errors when compiling sound applications

The version 1.0c and earlier sound driver used a different and incompatible ioctl() scheme. Obtain newer source code or make the necessary changes to adapt it to the new sound driver. See the sound driver Readme file for details.

Also ensure that you have used the latest version of soundcard.h and ultrasound.h when compiling the application. See the installation instructions at beginning of this text.

6.13 SEGV when running sound binaries that worked previously

This is probably the same problem described in the previous question.

6.14 What known bugs or limitations are there in the sound driver?

See the Readme and CHANGELOG files included with the sound driver kernel source.

6.15 Where are the sound driver ioctls() etc. documented?

These are partially documented in the Hacker's Guide to VoxWare, currently available in draft form. The latest version is draft 2, and can be found on ftp://nic.funet.fi/pub/OS/Linux/ALPHA/sound. Note that this directory is "hidden" and will not appear in directory listings. If you "cd" to the directory and use the FTP "dir" command, the files are there.

At time of writing new documentation was becoming available on the 4Front Technologies Web site.

Another source of information is the Linux Multimedia Guide, described in the references section.

6.16 What CPU resources are needed to play or record without pauses?

There is no easy answer to this question, as it depends on:

In general, any 386 machine should be able to play samples or FM synthesized music on an 8 bit soundcard with ease.

Playing MOD files, however, requires considerable CPU resources. Some experimental measurements have shown that playing at 44kHz requires more than 40% of the speed of a 486/50 and a 386/25 can hardly play faster than 22 kHz (these are with an 8 bit card sound such as a SoundBlaster). A card such as the Gravis UltraSound card performs more functions in hardware, and will require less CPU resources.

These statements assume the computer is not performing any other CPU intensive tasks.

Converting sound files or adding effects using a utility such as Sox is also much faster if you have a math coprocessor. The kernel driver itself does not do any floating point calculations, though.

6.17 Problems with a PAS16 and an Adaptec 1542 SCSI host adaptor

(the following explanation was supplied by [email protected])

Linux only recognizes the 1542 at address 330 (default) or 334, and the PAS only allows the MPU-401 emulation at 330. Even when you disable the MPU-401 under software, something still wants to conflict with the 1542 if it's at its preferred default address. Moving the 1542 to 334 makes everyone happy.

Additionally, both the 1542 and the PAS-16 do 16-bit DMA, so if you sample at 16-bit 44 KHz stereo and save the file to a SCSI drive hung on the 1542, you're about to have trouble. The DMAs overlap and there isn't enough time for RAM refresh, so you get the dread ``PARITY ERROR - SYSTEM HALTED'' message, with no clue to what caused it. It's made worse because a few second-party vendors with QIC-117 tape drives recommend setting the bus on/off times such that the 1542 is on even longer than normal. Get the SCSISEL.EXE program from Adaptec's BBS or several places on the internet, and reduce the BUS ON time or increase the BUS OFF time until the problem goes away, then move it one notch or more further. SCSISEL changes the EEPROM settings, so it's more permanent than a patch to the DOS driver line in CONFIG.SYS, and will work if you boot right into Linux (unlike the DOS patch). Next problem solved.

Last problem - the older Symphony chipsets drastically reduced the timing of the I/O cycles to speed up bus accesses. None of various boards I've played with had any problem with the reduced timing except for the PAS-16. Media Vision's BBS has SYMPFIX.EXE that's supposed to cure the problem by twiddling a diagnostic bit in Symphony's bus controller, but it's not a hard guarantee. You may need to:

Young Microsystems will upgrade the boards they import for around $30 (US); other vendors may be similar if you can figure out who made or imported the motherboard (good luck). The problem is in ProAudio's bus interface chip as far as I'm concerned; nobody buys a $120 sound card and sticks it in a 6MHz AT. Most of them wind up in 25-40MHz 386/486 boxes, and should be able to handle at least 12MHz bus rates if the chips are designed right. Exit soapbox (stage left).

The first problem depends on the chipset used on your motherboard, what bus speed and other BIOS settings, and the phase of the moon. The second problem depends on your refresh option setting (hidden or synchronous), the 1542 DMA rate and (possibly) the bus I/O rate. The third can be determined by calling Media Vision and asking which flavor of Symphony chip is incompatible with their slow design. Be warned, though - 3 of 4 techs I talked to were brain damaged. I would be very leery of trusting anything they said about someone else's hardware, since they didn't even know their own very well.

6.18 Is it possible to read and write samples simultaneously?

Due to hardware limitations, this is not possible with most sound cards. Some newer cards do support it. See the section on "bidirectional mode" in the Hacker's Guide to Voxware for more information.

6.19 My SB16 is set to IRQ 2, but configure does not allow this value.

On '286 and later machines, the IRQ 2 interrupt is cascaded to the second interrupt controller. It is equivalent to IRQ 9.

6.20 Are the SoundBlaster AWE32 or SoundBlaster16 ASP supported?

These cards offer special chips (ASP and Emu) that support additional features such as wavetable synthesis, however Creative Labs is not willing to release programming information. Unless they change their policy there can be no support for the special hardware under Linux. The cards are supported as regular SoundBlaster 16 cards under Linux.

The Gravis UltraSound card has capabilities similar to the AWE32, and is supported under Linux. Cards based on other DSPs such as the Analog Devices ADSP-21xx may be supported in the future.

6.21 If I run Linux, then boot DOS, I get errors and/or sound applications do not work properly.

This happens after a soft reboot to DOS. Sometimes the error message misleadingly refers to a bad CONFIG.SYS file.

Most of the current sound cards have software programmable IRQ and DMA settings. If you use different settings between Linux and MS-DOS/Windows, this may cause problems. Some sound cards don't accept new parameters without a complete reset (i.e. cycle the power or use the hardware reset button).

The quick solution to this problem it to perform a full reboot using the reset button or power cycle rather than a soft reboot (e.g. Ctrl-Alt-Del).

The correct solution is to ensure that you use the same IRQ and DMA settings with MS-DOS and Linux (or not to use DOS :-).

6.22 Problems running DOOM under Linux

Users of the port of ID software's game DOOM for Linux may be interested in these notes.

For correct sound output you need version 2.90 or later of the sound driver; it has support for the real-time "DOOM mode".

The sound samples are 16-bit. If you have an 8-bit sound card you can still get sound to work using one of several programs available in ftp://sunsite.unc/edu/pub/Linux/games/doom.

If performance of DOOM is poor on your system, disabling sound (by renaming the file sndserver) may improve it.

By default DOOM does not support music (as in the DOS version). The program musserver will add support for music to DOOM under Linux. It can be found at ftp://pandora.st.hmc.edu/pub/linux/musserver.tgz.

(Late breaking news: it seems that sound for DOOM now longer works under 2.0.x kernels. It reports an error about /dev/sequencer.)

6.23 How can I reduce noise picked up by my soundcard?

Using good quality shielded cables and trying the sound card in different slots may help reduce noise. If the sound card has a volume control, you can try different settings (maximum is probably best).

Using a mixer program you can make sure that undesired inputs (e.g. microphone) are set to zero gain.

Some sound cards are simply not designed with good shielding and grounding and are prone to noise pickup.

Finally, on my system I found that the kernel command line option no-hlt reduces the noise level. This tells the kernel not to use the halt instruction when running the idle process loop. You can try this manually when booting, or set it up using the command append = "no-hlt" in your LILO configuration file.

6.24 I can play sounds, but not record.

If you can play sound but not record, try these steps:

6.25 My "compatible" sound card only works if I first initialize under MS-DOS.

Some sound card clones are not 100% register compatible with the real thing; they sometimes contain extra circuitry such as mixers. You may be able to use these under Linux if you first initialize under MS-DOS, then soft boot Linux (i.e. Ctrl-Alt-Delete).

One user also reported that he had better results if he used LOADLIN rather than LILO to boot Linux after initializing his sound card under MS-DOS (this was with a Diamond sound card).,

They may or may not function reliably. The real solution is to find out from the manufacturer what the differences are and have the support added to the sound driver. This has been done, for example, for the Sound Galaxy NX Pro.

6.26 My 16-bit SoundBlaster "compatible" sound card only works in 8-bit mode under Linux.

16-bit sound cards described as SoundBlaster compatible are really only compatible with the 8-bit SoundBlaster Pro. They typically have a 16-bit mode which is not compatible with the SoundBlaster 16 and not compatible with the Linux sound driver.

If your card is also listed as compatible with the Microsoft Windows Sound System, you may be able to get it to work in 16-bit mode if you enable support for the WSS in the Linux sound driver. You will also probably have to do the DOS initialization trick to get the card to work.

6.27 Where can I find sound applications for Linux?

Here are some good archive sites to search for Linux specific sound applications:

6.28 Can the sound driver be compiled as a loadable module?

With recent kernels the sound driver is supported as a kernel loadable module.

See the files /usr/src/linux/drivers/sound/Readme.modules and /usr/src/linux/Documentation/modules.txt (or /usr/src/linux/README) for details.

6.29 Can I use a soundcard to replace the system console beep?

Try the oplbeep program, found at ftp://sunsite.unc.edu/pub/Linux/apps/sound/oplbeep-alpha.tar.gz

Another variant is the beep program found at ftp://sunsite.unc.edu/pub/Linux/kernel/patches/misc/modreq_beep.tgz

The modutils package has an example program and kernel patch that supports calling an arbitrary external program to generate sounds when requested by the kernel.

Alternatively, with some sound cards you can connect the PC speaker output to the soundcard so that all sounds come from the sound card speakers.

6.30 What is VoxWare?

The kernel sound drivers support several different Intel-based Unix compatible operating systems, and can be obtained as a package separate from the Linux kernel. Up until February 1996 the author had called the software "VoxWare". Unfortunately this name has been registered by VoxWare Incorporated, and can not be used. On March 29th, 1996 Hannu Savolainen announced that the new name was Unix Sound System (USS) Lite.

The Unix Sound System (USS) is a commercially available kernel sound driver for various Unix systems, sold by 4Front Technologies. A free version, known as USS/Lite will continue to be made freely available for Linux systems.

For more information see the 4Front Technologies Web page at http://www.4front-tech.com/.

6.31 Are Plug and Play sound card supported?

Full Plug and Play support should be coming in Linux version 2.1. In the mean time there are a number of workarounds for getting Plug and Play sound cards to work.

If you have a newer Pentium system with a Plug and Play BIOS, it should take care of configuring the cards for you. Make sure that you configure the Linux sound driver to use the same i/o address, IRQ, and DMA channel parameters as the BIOS.

There is a package of Plug and Play tools for Linux that can be used to set up the card. It can be found at http://www.redhat.com/pnp.

If you use the card under Windows95, you can use the device manager to set up the card, then soft boot into Linux using the LOADLIN program. Make sure Windows95 and Linux use the same card setup parameters.

If you use the card under DOS, you can use the icu utility that comes with SB16 PnP cards to configure it under DOS, then soft boot into Linux using the LOADLIN program. Again, make sure DOS and Linux use the same card setup parameters.

The commercial USS/Linux sound driver has support for the SB16 PnP sound card. You can purchase this driver from 4Front Technologies.

6.32 Sox/Play/Vplay reports "invalid block size 1024"

A change to the sound driver in version 1.3.67 broke some sound player programs which (incorrectly) checked that the result from the SNDCTL_DSP_GETBLKSIZE ioctl was greater than 4096. You should get a newer version of the program (if available) or fix it yourself. For the Sox program, the following patch worked for me:

--- sbdsp.c.orig        Thu Feb 22 22:46:00 1996
+++ sbdsp.c     Thu Feb 22 22:51:18 1996
@@ -176,7 +176,7 @@
        }
 
        ioctl (dspfd, SNDCTL_DSP_GETBLKSIZE, &abuf_size);
-       if (abuf_size < 4096 || abuf_size > 65536) {
+       if (abuf_size < 1) {
                if (abuf_size == -1)
                perror (dspname);
                else

6.33 Why does the sound driver have its own configuration program?

The sound driver supports many different configuration parameters. The configure program included with the sound driver checks for many dependencies between parameters. The tools used to configure the kernel don't support this level of functionality.

That said, the recent 1.3.x kernels do optionally allow using the standard kernel configuration tools with the sound driver. See the notes in the CHANGELOG file for the sound driver. This is still experimental and some options cannot be set this way.

6.34 The mixer settings are reset whenever I load the sound driver module

You can build the sound driver as a loadable module and use kerneld to automatically load and unload it. This can present one problem - whenever the module is reloaded the mixer settings go back to their default values. For some sound cards this can be too loud (e.g. SB16) or too quiet. Markus Gutschke ([email protected]) found this solution. Use a line in your /etc/conf.modules file such as the following:

options sound dma_buffsize=65536 && /usr/bin/setmixer igain 0 ogain 0 vol 75

This causes your mixer program (in this case setmixer) to be run immediately after the sound driver is loaded. The dma_buffsize parameter is just a dummy value needed because the option command requires a command line option. Change the line as needed to match your mixer program and gain settings.

If you have compiled the sound driver into your kernel and you want to set the mixer gains at boot time you can put a call to your mixer program in a system startup file such as /etc/rc.d/rc.local.

6.35 Only user root can record sound

By default the script in Readme.linux that creates the sound device files only allows the devices to be read by user root. This is to plug a potential security hole. In a networked environment, external users could conceivably log in remotely to a Linux PC with a sound card and microphone and eavesdrop. If you are not worried about this, you can change the permissions used in the script.

With the default setup, users can still play sound files. This is not a security risk but is a potential for nuisance.


Previous Next Contents Main Page