--- A new FreeBSD audio driver ---
by Luigi Rizzo (luigi@iet.unipi.it)
This is a new, completely rewritten, audio driver for FreeBSD.
Only "soundcard.h" has remained largely similar to the original
OSS/Voxware header file, mostly for compatibility with existing
applications.
This driver tries to cover those areas where the Voxware 3.0 driver
is mostly lacking: full-duplex, audio applications, modern (mostly
PnP) cards. For backward compatibility, the driver implements most
of the Voxware ioctl() audio calls, so that many applications --
even commercial ones -- will run unmodified with this driver. On
the other hand, at the moment this driver does not support /dev/midi
and /dev/synth, or some ioctl() used in xquake. Do not expect
/dev/synth to be supported anytime soon.
I also have implemented a new software interface with an independent
set of ioctl(), to support some functions which were not easy to
express with the existing software interface (e.g. full duplex on
old SB16 cards). To make an effective use of the new functionalities
you need to recompile applications by replacing the audio module(s).
Such modified driver modules are present in the misc/ directory
for several applications.
This file gives quick information on how to install the driver.
Updated versions of this code will be available at the following URL:
http://www.iet.unipi.it/~luigi/FreeBSD.html
Please READ CAREFULLY this file (and possibly the LaTeX documentation)
to build a working kernel. The configuration is DIFFERENT (and
hopefully much simpler) from the original Voxware driver. The
relevant steps are indicated at "---INSTALLATION---".
CARDS:
The driver supports most clones of WSS, SB16 and SBPro cards.
This includes those based on the Crystal CS423x, OPTI931, GUSPnP,
Yamaha, SB16/32 (both plain ISA, PnP, and the various AWExx).
Many PnP cards are directly recognized, for others you might need
manual configuration. See the file "CARDS" for more details.
APPLICATIONS:
In general, most applications which use /dev/audio or /dev/dsp
work unmodified or with a specially-supplied module.
UNMODIFIED:
- raplayer (Real Audio Player), rvplayer (linux version)
- xboing
- xanim
- various mpeg players (mpg123, amp, ...);
WITH SPECIAL DRIVER MODULE (supplied)
- speak_freely, full duplex (requires removing the definition of
HALF_DUPLEX in the Makefile);
- the realaudio player (3.0, dynamically linked);
- vat, full duplex (the version in ports is already modified);
- timidity, a software midi-to-pcm converter;
NOT WORKING
- xquake (we do not support mmapped buffers yet);
---INSTALLATION---
* add the following lines to your kernel configuration file:
controller pnp0 # this is required for PnP support
device pcm0 at isa ? port? tty irq N drq D flags F
where
N is the IRQ address used by the sound card,
D is the primary DMA channel used by the sound card,
F is used to specify a number of options, in particular:
bit 2..0 secondary DMA channel;
bit 4 set if the board uses two dma channels;
bit 15..8 board type, overrides autodetection; leave it
zero if don't know what to put in (and you don't,
since this is unsupported at the moment...).
The code will probe for common port addresses (0x220, 0x240
for SB and clones, 0x530 for WSS and clones), so you don't need
to specify them if your system uses one of them. In case you
do, note that for WSS cards the code assumes that the board
occupies 8 IO addresses, the first four used to configure
IRQ/DRQ, and the other four to access codec registers. Many
boards (including all the ones I have) do not have registers
to program IRQ and DRQ, so they really start at 0x534... yet
I decided to use the old convention for historical reasons.
You can use multiple sound cards, in which case you need more
lines like
device pcm1 at isa ? port? tty irq N drq D flags F
device pcm2 at isa ? port? tty irq N drq D flags F
...
EXAMPLES: a typical "device" line for the SB16 (full duplex) is
device pcm0 at isa ? port? tty irq 5 drq 1 flags 0x15
The driver will check at the default addresses (or the one you
specify) which type of SoundBlaster you have (1.5, 2.0, 3.X
aka SBPro, 4.X aka SB16) and use the correct commands. You
_do_not_ need to specify different drivers (sb,sbpro,sbxvi) as
it was the case (and a big source of confusion) in the previous
sound driver.
For a WSS-compatible codec (non PnP) working in full duplex using
dma channels 1 and 3, you can specify:
device pcm0 at isa ? port 0x530 tty irq 7 drq 1 flags 0x13
(0x530 is a default if no port address is specified). The
"flags 0x13" specifies that you have a dual dma board with
channel 3 as secondary DMA channel.
* build the kernel using the standard steps
config MYKERNEL
cd /sys/compile/MYKERNEL
make depend
make
* note for PnP cards:
For PnP cards, only the line for "pcm0" is needed (the code
will allocate entries for more cards if found), but IT MUST
INCLUDE ALL FIELDS. You can use the following line:
device pcm0 at isa ? port? tty irq 7 drq 1
NOTE that:
- the parameters for the PnP device(s) will be read from the
configuration of the card(s); they are usually assigned by
the bios, and there is no way (at the moment) to override
them, so if you have a broken (or no) PnP bios your only
chance is to patch the pnp attach code in the driver for your
card (ad1848.c, sb_dsp.c, clones.c) and write there the
parameters you want;
- The driver will assign unit numbers to the PnP cards starting
from the next free one (e.g. 1, 2, ...) same as it is done
with PCI devices which are clones of ISA devices.
The driver assumes a working PnP bios, which will assign correct
addresses and IO and DMA channels to the devices. If you do not
have a PnP-aware BIOS, you must boot with the -c option and assign
addresses manually the first time. The general commands are described in
the pnp README file. For the card-specific commands check in the
file CARDS.
WHAT IF THIS DRIVER DOES NOT WORK:
If the driver does not work with your hardware, I might to help
but I need the following information:
- relevant lines in your config file;
- dmesg output
- possibly, pnpinfo output
Please send all the above in plain text, not as a mime attachment.
Common mistakes:
* you are trying to use /dev/audio0 instead of /dev/audio1
For technical reasons, a PnP device is attached as unit 1 instead
of unit 0 -- most applications are programmed to access the audio
hardware through /dev/audio, /dev/dsp, /dev/mixer which are in turn
symlinks to the correct device entries. Check them and possibly fix
these symlinks in /dev
* you have used a wrong config line
The configuration of this driver is different from the Voxware one.
Please read the information in this file carefully.
* your BIOS is leaving the card disabled.
Some BIOSes do not initialize the card, or leave it disabled. At the
moment, the fix is to use the pnp code booting with "-c" and set the
correct port, irq, drq etc for the card. See the PnP documentation.
* your card is not recognized.
This driver supports a large, but still limited, number of cards,
mostly SB and WSS clones. Other cards may or may not work depending
on how closely they emulate these devices. In case, send me an email
with the info indicated above.
* the mixer does not work well
Different cards have different connections to the mixer, so it might
well be that to control the volume of your CD you have to use the FM
port, etc. Also, on some cards the volume might be lower than you
expect. The mixer code still does not try to exploit the features of
each card, and it just provides basic functionalities.
--- ACKNOWLEDGMENTS ---
Several people helped, directly or indirectly, in the development of
this driver. In particular I would like to thank:
* Hannu Savolainen (the Voxware author) for making his code
available. It was a very good source of technical info;
* Amancio Hasty for continuous support and his work on guspnp code;
* Jim Lowe for his suggestion on the block-mode select;
* Allison Mankin and Brad Karp at ISI-East for supplying a GUS PnP
which allowed me to support this card;
* Eric J. Schwertfeger for donating an ES1868 card for writing the
driver (which i haven't done yet...).
* and many people who had the patience to try the driver
on their cards and report success/failure and useful
information.
It was certainly helpful to have the data sheets for some of the
devices I support available on the net, especially in the (unfortunately
rare) cases where the data sheets matched the actual behavior of
the product. Too bad that no one of the chip/card manufacturers I
have contacted by email regarding missing or inconsistent documentation
on their products did even care to reply to my messages.
7e4a9dced9