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.
These are the most standard device file names, some Linux distributions may use slightly different names.
normally a link to /dev/audio0
Sun workstation compatible audio device (only a partial implementation, does not support Sun ioctl interface, just u-law encoding)
second audio device (if supported by sound card or if more than one sound card installed)
normally a link to /dev/dsp0
first digital sampling device
second digital sampling device
normally a link to /dev/mixer0
first sound mixer
second sound mixer
high-level sequencer interface
low level MIDI, FM, and GUS access
normally a link to /dev/music
1st raw MIDI port
2nd raw MIDI port
3rd raw MIDI port
4th raw MIDI port
displays sound driver status when read (also available as /proc/sound, removed in 2.4 kernels)
The PC speaker driver provides the following devices:
equivalent to /dev/audio
equivalent to /dev/dsp
equivalent to /dev/mixer
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.
If you are running a graphical desktop such as KDE or GNOME then it should already include a graphical sound file player program.
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.
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.
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.
With the 2.0 and newer kernels that configure sound using make config, instead of local.h, you need to edit the file /usr/include/linux/autoconf.h. After the section containing the lines:
#define SBC_BASE 0x220 #define SBC_IRQ (5) #define SBC_DMA (1) #define SB_DMA2 (5) #define SB_MPU_BASE 0x0 #define SB_MPU_IRQ (-1) |
add these lines (with values appropriate for your system):
#define SB2_BASE 0x330 #define SB2_IRQ (7) #define SB2_DMA (2) #define SB2_DMA2 (2) |
The following drivers don't permit multiple instances:
GUS (driver limitation)
MAD16 (hardware limitation)
AudioTrix Pro (hardware limitation)
CS4232 (hardware limitation)
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).
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.
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.
This may also happen with Linux 2.0 and later if there is not enough free RAM on the system when the device is opened. The audio driver requires at least two pages (8k) of contiguous physical RAM for each DMA channel. This happens sometimes in machines with less than 16M of RAM or which have been running for very long time. You can preallocate the DMA buffers when the driver is loaded using the kernel option "dma_buf=1".
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. You should run the fuser command as root in order to report usage by users other than yourself.
On some systems you may need to be root when running the fuser command in order to see the processes of other users.
Under the KDE desktop, the artsd sound server usually take control of the sound device. Applications should make requests to play sound through the sound server, or the sound server should be paused. A similar situation exists under GNOME with the esd sound server.
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 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.
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:
try playing with a lower sampling rate or in mono mode
eliminate other processes
buy a faster computer
buy a more powerful sound card (e.g. Gravis UltraSound)
If you have a Gravis UltraSound card, you should use one of the mod file players written specifically for the GUS (e.g. gmod).
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 files included with the sound driver kernel source.
Currently the best documentation, other than the source code, is available at the 4Front Technologies web site, http://www.opensound.com. Another source of information is the Linux Multimedia Guide, described in the references section.
There is no easy answer to this question, as it depends on:
whether using PCM sampling or FM synthesis
sampling rate and sample size
which application is used to play or record
Sound Card hardware
disk I/O rate, CPU clock speed, cache size, etc.
In general, any 386 machine or better should be able to play samples or FM synthesized music on an 8 bit sound card 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 (or CPU with on board FPU). The kernel driver itself does not do any floating point calculations, though.
(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:
get the motherboard distributor to replace the older version bus chip,
replace the motherboard, or
buy a different brand of sound card.
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 drivers for some sound cards support full duplex mode. Check the documentation available from 4Front Technologies for information on how to use it.
On '286 and later machines, the IRQ 2 interrupt is cascaded to the second interrupt controller. It is equivalent to IRQ 9.
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 :-).
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://www.ibiblio.org/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.
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.
Philipp Braunbeck reported that on his ESS-1868 sound card there was a jumper to turn off the built-in amplifier which helped reduce noise when enabled.
On one 386 system I found that the kernel command line option no-hlt reduced 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.
Some sound cards are simply not designed with good shielding and grounding and are prone to noise pickup.
If you can play sound but not record, try these steps:
use a mixer program to select the appropriate device (e.g. microphone)
use the mixer to set the input gains to maximum
If you can, try to test sound card recording under MS-DOS to determine if there is a hardware problem
Sometimes a different DMA channel is used for recording than for playback. In this case the most probable reason is that the recording DMA is set up incorrectly.
In most cases a "SoundBlaster compatible" card will work better under Linux if configured with a driver other than the SoundBlaster one. Most sound cards claim to be compatible (e.g. "16 bit SB Pro compatible" or "SB compatible 16 bit") but usually this SoundBlaster mode is just a hack provided for DOS games compatibility. Most cards have a 16 bit native mode which is likely to be supported by recent Linux versions (2.0.1 and later).
Only with some (usually rather old) cards is it necessary to try to get them to work in the SoundBlaster mode. The only newer cards that are the exception to this rule are the Mwave-based cards.
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.
You may be able to get the card to work in 16-bit mode by using the MAD16 or MSS/WSS driver.
Here are some good archive sites to search for Linux specific sound applications:
Also see the References section of this document.
With recent kernels the sound driver is supported as several kernel loadable modules.
See the files in /usr/src/linux/Documentation/sound, especially the files Introduction and README.modules.
Try the oplbeep program, found at ftp://www.ibiblio.org/pub/Linux/apps/sound/oplbeep-2.3.tar.gz
Another variant is the beep program found at ftp://www.ibiblio.org/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.
Version 2.0 and later of KDE allows playing a sound file for the console beep in KDE applications such as konsole.
Alternatively, with some sound cards you can connect the PC speaker output to the sound card so that all sounds come from the sound card speakers.
The commercial version of the sound drivers sold by 4Front Technologies was previously known by other names such as VoxWare, USS (Unix Sound System), and even TASD (Temporarily Anonymous Sound Driver). It is now marketed as OSS (Open Sound System). The version included in the Linux kernel is sometimes referred to as OSS/Free.
For more information see the 4Front Technologies web page at http://www.opensound.com/. I wrote a review of OSS/Linux in the June 1997 issue of Linux Journal.
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. The latest sound driver versions have been fixed to avoid allocating fragments shorter than 4096 bytes which solves this problem with old utilities.
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. SoundBlaster16) 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 post-install sound /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.
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.
Information on how to use the mwave sound card on an IBM ThinkPad laptop computer can be found in the file /usr/src/linux/Documentation/sound/mwave, which is part of the kernel source distribution (note that not all IBM ThinkPads use the MWAVE sound chip).
Some old 8-bit SoundBlaster cards have no mixer circuitry. Some sound applications insist on being able to open the mixer device, and fail with these cards. Jens Werner () reports a workaround for this is to link /dev/mixer to /dev/null and everything should work fine.
From Scott Manley ():
There seems to be a new type of Soundblaster - it was sold to us as a SB16 - the Model no. on the Card is CT4170. These Beasties only have one DMA channel so when you try to set them up then the kernel will have trouble accessing the 16 bit DMA. The solution is to set the second DMA to 1 so that the card will behave as advertised.
From Kim G. S. OEyhus ():
I looked all around the internet and in sound documentation on how to do something as simple as connecting the MIDI output from a master keyboard to the MIDI input on a sound card. I found nothing. The problem is that they both use the same device, /dev/midi, at least when using the OSS sound system. So I found a way to do it, which I want to share. This makes for a very simple synthesizer, with full MIDI support:
CONNECTING A MIDI MASTER-KEYBOARD DIRECTLY TO A SOUNDCARD WITH MIDI
A MIDI master-keyboard is a keyboard without any synthesizer, and with only a MIDI-out plug. This can be connected to the 15-pin D-SUB port on most sound-cards with a suitable cable.
Such a keyboard can be used to control the MIDI synthesizer device for the card, thus making a simple keyboard controlled synthesizer.
Compile the following program, say with 'gcc -o prog prog.c' and run it:
#include <fcntl.h>
main()
{
int fil, a;
char b[256];
fil=open("/dev/midi", O_RDWR);
for(;;)
{
a=read(fil, b, 256);
write(fil, b, a);
}
}
|
From Matthew Inger ():
Information on getting an Ensoniq PCI 128 card to work.
The problem that it was exhibiting was that it was trying to use interrupt 15 by default (Plug and Pray was responsible for this one). This interrupt is used by the secondary ide controller, and cannot be shared by other devices. You need to somehow force the es1370 to use another interrupt (should use interrupt 11 like it does under windows).
I figured this one out for myself believe it or not.
What I had to do was:
a) in the BIOS, you have to tell the computer that you don't have a Plug and Play OS. I believe this is under advanced options in my BIOS.
b) in the PCI settings in the BIOS, tell the computer to reserve interrupt 15 for legacy ISA devices. In my bios, under advanced options, there is a section for PCI settings. Under there, there is a Resource Exclusion area, and that's where to do this.
When you reboot into linux you will be able to use sound. (I don't remember if it shows up in the boot messages or not like it used to). To be safe, I ran sndconfig again so that it would play the test message, which sounded not great, but it was there. When I played a CD however, it sounded perfect.
Don't worry about windows, I tried both my cards: ISA Modem, and the Sound Card out, and they work without any hitches.
The odds are your BIOS will be different from mine, but you just have to figure out where the settings are for the above two items. Good luck.
SoftOSS is a software-based wavetable synthesizer included with the kernel sound driver that is compatible with the Gravis Utrasound card. To operate the driver needs GUS compatible MIDI patch files. The documentation mentions the "public domain MIDIA patchset available from several ftp sites". Note that SoftOSS is no longer included as of the 2.4 kernels.
As explained on the 4Front Technologies web page http://www.opensound.com/softoss.html they can be downloaded from ftp://archive.cs.umbc.edu/pub/midia/instruments.tar.gz.