1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-17 10:26:15 +00:00
freebsd/sys/i386/isa/snd
Poul-Henning Kamp 4e2f199e0c This commit should be a extensive NO-OP:
Reformat and initialize correctly all "struct cdevsw".

        Initialize the d_maj and d_bmaj fields.

        The d_reset field was not removed, although it is never used.

I used a program to do most of this, so all the files now use the
same consistent format.  Please keep it that way.

Vinum and i4b not modified, patches emailed to respective authors.
1999-05-30 16:53:49 +00:00
..
ad1848.c Fix dev_t/minor problems 1999-05-12 19:01:30 +00:00
CARDS Add support for ASound Gold card using the ALS120 1999-05-27 06:12:40 +00:00
clones.c Sigh, serves me right for committing without reading the followups. :-] 1999-05-02 21:53:28 +00:00
dmabuf.c Extend the callback mechanism and add hooks to support PCI cards. 1998-12-31 07:34:01 +00:00
mss.h Bring in ad1816 patches from German Tischler. 1999-01-04 10:40:14 +00:00
README spell check 1998-11-02 09:39:54 +00:00
sb_dsp.c Add support for ASound Gold card using the ALS120 1999-05-27 06:12:40 +00:00
sbcard.h Quiet a warning, put a #if 0 around some (I believe) unused static structs. 1999-05-09 13:21:06 +00:00
sound.c This commit should be a extensive NO-OP: 1999-05-30 16:53:49 +00:00
sound.h Bring in ad1816 patches from German Tischler. 1999-01-04 10:40:14 +00:00
ulaw.h Fix breakage by cleanup. 1998-12-27 17:12:02 +00:00

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