SOUND(4) | Device Drivers Manual | SOUND(4) |
sound
, pcm
,
snd
—
FreeBSD PCM audio device
infrastructure
To compile this driver into the kernel, place the following line in your kernel configuration file:
device sound
The sound
driver is the main component of
the FreeBSD sound system. It works in conjunction
with a bridge device driver on supported devices and provides PCM audio
record and playback once it attaches. Each bridge device driver supports a
specific set of audio chipsets and needs to be enabled together with the
sound
driver. PCI and ISA PnP audio devices identify
themselves so users are usually not required to add anything to
/boot/device.hints.
Some of the main features of the sound
driver are: multichannel audio, per-application volume control, dynamic
mixing through virtual sound channels, true full duplex operation, bit
perfect audio, rate conversion and low latency modes.
The sound
driver is enabled by default,
along with several bridge device drivers. Those not enabled by default can
be loaded during runtime with kldload(8) or during boot
via loader.conf(5). The following bridge device drivers
are available:
Refer to the manual page for each bridge device driver for driver specific settings and information.
For old legacy ISA cards, the driver looks for MSS cards at
addresses 0x530
and 0x604
.
These values can be overridden in
/boot/device.hints. Non-PnP sound cards require the
following lines in device.hints(5):
hint.pcm.0.at="isa" hint.pcm.0.irq="5" hint.pcm.0.drq="1" hint.pcm.0.flags="0x0"
Apart from the usual parameters, the flags field is used to specify the secondary DMA channel (generally used for capture in full duplex cards). Flags are set to 0 for cards not using a secondary DMA channel, or to 0x10 + C to specify channel C.
In general, the module snd_foo corresponds
to device snd_foo
and can be loaded by the boot
loader(8) via loader.conf(5) or from the
command line using the kldload(8) utility. Options which
can be specified in /boot/loader.conf include:
NO
”) If set to
“YES
”, this option loads all
available drivers.NO
”) If set to
“YES
”, only the Intel High
Definition Audio bridge device driver and dependent modules will be
loaded.NO
”) If set to
“YES
”, load driver for card/chipset
foo.To define default values for the different mixer channels, set the
channel to the preferred value using hints, e.g.:
hint.pcm.0.line="0
".
This will mute the input channel per default.
Multichannel audio, popularly referred to as “surround
sound” is supported and enabled by default. The FreeBSD multichannel
matrix processor supports up to 18 interleaved channels, but the limit is
currently set to 8 channels (as commonly used for 7.1 surround sound). The
internal matrix mapping can handle reduction, expansion or re-routing of
channels. This provides a base interface for related multichannel
ioctl
()
support. Multichannel audio works both with and without VCHANs.
Most bridge device drivers are still missing multichannel matrixing support, but in most cases this should be trivial to implement. Use the dev.pcm.%d.[play|rec].vchanformat sysctl(8) to adjust the number of channels used. The current multichannel interleaved structure and arrangement was implemented by inspecting various popular UNIX applications. There were no single standard, so much care has been taken to try to satisfy each possible scenario, despite the fact that each application has its own conflicting standard.
The Parametric Software Equalizer (EQ) enables the use of “tone” controls (bass and treble). Commonly used for ear-candy or frequency compensation due to the vast difference in hardware quality. EQ is disabled by default, but can be enabled with the hint.pcm.%d.eq tunable.
Each device can optionally support more playback and recording channels than physical hardware provides by using “virtual channels” or VCHANs. VCHAN options can be configured via the sysctl(8) interface but can only be manipulated while the device is inactive.
FreeBSD supports independent and individual volume controls for
each active application, without touching the master
sound
volume. This is sometimes referred to as
Volume Per Channel (VPC). The VPC feature is enabled by default.
The following loader tunables are used to set driver configuration
at the loader(8) prompt before booting the kernel, or they
can be stored in /boot/loader.conf in order to
automatically set them before booting the kernel. It is also possible to use
kenv(1) to change these tunables before loading the
sound
driver. The following tunables can not be
changed during runtime using sysctl(8).
There are a number of sysctl(8) variables available which can be modified during runtime. These values can also be stored in /etc/sysctl.conf in order to automatically set them during the boot process. hw.snd.* are global settings and dev.pcm.* are device specific.
sound
volume. Increase to give
more room for attenuation control. Decrease for more amplification, with
the possible cost of sound clipping.ioctl
():
SNDCTL_DSP_GETPLAYVOL, SNDCTL_DSP_SETPLAYVOL,
SNDCTL_DSP_SETRECVOL, SNDCTL_DSP_SETRECVOL.
This
is however not always possible. Enable this to allow applications to use
their own existing mixer logic to control their own channel volume.sound
stream will be fed directly to the
hardware. If VCHANs are enabled, the bitperfect mode will use the VCHAN
format/rate as the definitive format/rate target. The recommended way to
use bitperfect mode is to disable VCHANs and enable this sysctl. Default
is disabled.sound
channels with
different format/rate. When a new channel is about to start, the
entire list of virtual channels will be scanned, and the channel with
the best format/rate (usually the highest/biggest) will be selected.
This ensures that mixing quality depends on the best channel. The
downside is that the hardware DMA mode needs to be restarted, which
may cause annoying pops or clicks.On devices that have more than one recording source (ie: mic and line), there is a corresponding /dev/dsp%d.r%d device. The mixer(8) utility can be used to start and stop recording from an specific device.
Channel statistics are only kept while the device is open. So with situations involving overruns and underruns, consider the output while the errant application is open and running.
The driver supports most of the OSS
ioctl
() functions, and most applications work
unmodified. A few differences exist, while memory mapped playback is
supported natively and in Linux emulation, memory mapped recording is not
due to VM system design. As a consequence, some applications may need to be
recompiled with a slightly modified audio module. See
<sys/soundcard.h>
for a
complete list of the supported ioctl
()
functions.
The sound
drivers may create the following
device nodes:
sound
status, including all channels and
drivers.The first number in the device node represents the unit number of
the sound
device. All sound
devices are listed in /dev/sndstat. Additional
messages are sometimes recorded when the device is probed and attached,
these messages can be viewed with the dmesg(8)
utility.
The above device nodes are only created on demand through the dynamic devfs(5) clone handler. Users are strongly discouraged to access them directly. For specific sound card access, please instead use /dev/dsp or /dev/dsp%d.
Use the sound metadriver to load all sound
bridge device drivers at once (for example if it is unclear which the
correct driver to use is):
kldload snd_driver
Load a specific bridge device driver, in this case the Intel High Definition Audio driver:
kldload snd_hda
Check the status of all detected sound
devices:
cat /dev/sndstat
Change the default sound device, in this case to the second
device. This is handy if there are multiple sound
devices available:
sysctl
hw.snd.default_unit=1
snd_ad1816(4), snd_ai2s(4), snd_als4000(4), snd_atiixp(4), snd_audiocs(4), snd_cmi(4), snd_cs4281(4), snd_csa(4), snd_davbus(4), snd_ds1(4), snd_emu10k1(4), snd_emu10kx(4), snd_envy24(4), snd_envy24ht(4), snd_es137x(4), snd_ess(4), snd_fm801(4), snd_gusc(4), snd_hda(4), snd_hdspe(4), snd_ich(4), snd_maestro(4), snd_maestro3(4), snd_mss(4), snd_neomagic(4), snd_sbc(4), snd_solo(4), snd_spicds(4), snd_t4dwave(4), snd_uaudio(4), snd_via8233(4), snd_via82c686(4), snd_vibes(4), devfs(5), device.hints(5), loader.conf(5), dmesg(8), kldload(8), mixer(8), sysctl(8)
Cookbook formulae for audio EQ biquad filter coefficients, by Robert Bristow-Johnson, http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt.
Julius O'Smith's Digital Audio Resampling, http://ccrma.stanford.edu/~jos/resample/.
Polynomial Interpolators for High-Quality Resampling of Oversampled Audio, by Olli Niemitalo, http://www.student.oulu.fi/~oniemita/dsp/deip.pdf.
The OSS API, http://www.opensound.com/pguide/oss.pdf.
The sound
device driver first appeared in
FreeBSD 2.2.6 as pcm
,
written by Luigi Rizzo. It was later rewritten in
FreeBSD 4.0 by Cameron
Grant. The API evolved from the VOXWARE standard which later became
OSS standard.
Luigi Rizzo
<luigi@iet.unipi.it>
initially wrote the pcm
device driver and this
manual page. Cameron Grant
<gandalf@vilnya.demon.co.uk>
later revised the device driver for FreeBSD 4.0.
Seigo Tanimura
<tanimura@r.dl.itc.u-tokyo.ac.jp>
revised this manual page. It was then rewritten for FreeBSD
5.2.
Some features of your sound card (e.g., global volume control) might not be supported on all devices.
March 22, 2012 | Debian |