This section answers some of the questions that have been commonly asked on the Usenet news groups and mailing list.
The PC speaker driver provides the following devices:
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..
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.
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 (PAS16 has a 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.
No such file or directory
for sound devicesYou need to create the sound driver device files. See the section on creating device files.
No such device
for sound devicesYou have not booted with a kernel containing the sound driver or the I/O address configuration doesn't match your hardware.
The symptom is usually that a sound sample plays for 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.
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:
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.
This is probably the same problem described in the previous question.
See the Readme
and CHANGELOG
files included with the
sound driver kernel source.
If you are using version 1.0c or earlier, you definitely need to upgrade. Version 1.0c is not compatible with the applications written for version 2.0 or later.
There have been no significant changes after version 2.0, so if you don't have problems and that particular version fulfills your requirements, there are no compelling reasons to move to a more recent version (this should be true at least until September 1994).
The latest official version is in the latest Linux kernel distribution. There may also be some test and prototype versions lying around. If the version number is smaller than 2.9, the version should be quite safe. Any driver release having a version number of the form 2.99.XX is an incompletely implemented and experimental test release.
If you are interested in development of the sound driver, join the linux activists SOUND channel.
During configuration of the sound driver, a configure
program
is compiled and executed. This program asks you some questions and
then generates the header file local.h
that defines the sound
card configuration.
The configuration file defines (or undefines) the following symbols:
Symbol Meaning ====== ======= KERNEL_SOUNDCARD enable/disable sound driver CONFIGURE_SOUNDCARD enable/disable sound driver EXCLUDE_PAS ProAudioSpectrum support EXCLUDE_SB SoundBlaster support EXCLUDE_ADLIB AdLib support EXCLUDE_GUS Gravis UltraSound support EXCLUDE_MPU401 MPU-401 MIDI interface support EXCLUDE_SBPRO SoundBlaster Pro support EXCLUDE_SB16 SoundBlaster 16 support EXCLUDE_AUDIO Digitized voice support EXCLUDE_MIDI MIDI interface support EXCLUDE_YM3812 FM synthesizer (YM3812/OPL-3) support EXCLUDE_SEQUENCER MIDI sequencer support EXCLUDE_PRO_MIDI SoundBlaster Pro MIDI support EXCLUDE_CHIP_MIDI MIDI on CHIP support SBC_IRQ SoundBlaster IRQ number SBC_DMA SoundBlaster DMA channel SB16_DMA SoundBlaster 16 DMA channel SB16_MIDI_BASE base address of SoundBlaster 16 MIDI port PAS_IRQ ProAudioSpectrum IRQ number PAS_DMA ProAudioSpectrum DMA channel GUS_IRQ Gravis UltraSound IRQ number GUS_DMA Gravis UltraSound DMA channel GUS_BASE base address of Gravis UltraSound MPU_IRQ MPU-401 IRQ number MPU_BASE base address of MPU-401 port DSP_BUFFSIZE DMA buffer size
Several other defines are also created, setting such things as the sound driver revision level and the time and date when configure was run.
There are other parameters that are not set by the configure program
(e.g. SoundBlaster base address). If you need to change these,
edit the file sound_config.h
.
To disable the sound driver, run make config
and answer "no"
to the "Sound card support?" question.
The sound driver is not just for Linux, it also supports several other Intel-based Unix operating systems. The package is now called "VoxWare". Some of the enhancements being considered are:
These are documented in the Hacker's Guide to VoxWare,
currently available in draft form. The latest version is draft 2, and
can be found on nic.funet.fi
in
/pub/OS/linux/ALPHA/sound
.
There is no easy answer to this, 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.
(the following explanation was supplied by
seeker@indirect.com
)
Linux only recognizes the 1542 at address 330 (default) or 333, 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 333 makes everyone happy.
Additionally, both the 1542 and the PAS-16 do 16-bit DMA, so if you sample at 16-bit 44KHz 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.
The newer SB Pro has an OPL-3 FM chip, but the older version 1 used the OPL-2. The sound driver assumed the presence of an OPL-3. Version 2.5 of the sound driver corrects this problem.