Clean up some errors from textproc/igor
by wrapping long lines. Event: vBSDcon Hackathon
This commit is contained in:
parent
999f8925ae
commit
743c61d608
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=53370
1 changed files with 47 additions and 30 deletions
|
@ -4,15 +4,22 @@
|
|||
|
||||
$FreeBSD$
|
||||
-->
|
||||
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="oss">
|
||||
<info><title>Sound Subsystem</title>
|
||||
<authorgroup>
|
||||
<author><personname><firstname>Jean-Francois</firstname><surname>Dockes</surname></personname><contrib>Contributed by </contrib></author>
|
||||
</authorgroup>
|
||||
|
||||
</info>
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||||
xml:id="oss">
|
||||
<info>
|
||||
<title>Sound Subsystem</title>
|
||||
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Jean-Francois</firstname>
|
||||
<surname>Dockes</surname>
|
||||
</personname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</info>
|
||||
|
||||
<sect1 xml:id="oss-intro">
|
||||
<title>Introduction</title>
|
||||
|
@ -96,7 +103,9 @@
|
|||
<title>Probing, Attaching, etc.</title>
|
||||
|
||||
<para>Sound drivers probe and attach in almost the same way as any
|
||||
hardware driver module. You might want to look at the <link linkend="isa-driver"> ISA</link> or <link linkend="pci">PCI</link> specific sections of the handbook for
|
||||
hardware driver module. You might want to look at the <link
|
||||
linkend="isa-driver">ISA</link> or <link
|
||||
linkend="pci">PCI</link> specific sections of the handbook for
|
||||
more information.</para>
|
||||
|
||||
<para>However, sound drivers differ in some ways:</para>
|
||||
|
@ -104,9 +113,9 @@
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>They declare themselves as <filename>pcm</filename>
|
||||
class devices, with a
|
||||
<varname remap="structname">struct snddev_info</varname> device private
|
||||
structure:</para>
|
||||
class devices, with a <varname
|
||||
remap="structname">struct snddev_info</varname> device
|
||||
private structure:</para>
|
||||
|
||||
<programlisting> static driver_t xxx_driver = {
|
||||
"pcm",
|
||||
|
@ -117,8 +126,11 @@
|
|||
DRIVER_MODULE(snd_xxxpci, pci, xxx_driver, pcm_devclass, 0, 0);
|
||||
MODULE_DEPEND(snd_xxxpci, snd_pcm, PCM_MINVER, PCM_PREFVER,PCM_MAXVER);</programlisting>
|
||||
|
||||
<para>Most sound drivers<indexterm><primary>device
|
||||
drivers</primary><secondary>sound</secondary></indexterm>
|
||||
<para>Most sound drivers
|
||||
<indexterm>
|
||||
<primary>device drivers</primary>
|
||||
<secondary>sound</secondary>
|
||||
</indexterm>
|
||||
need to store additional private information about their
|
||||
device. A private data structure is usually allocated in
|
||||
the attach routine. Its address is passed to
|
||||
|
@ -134,7 +146,8 @@
|
|||
<para>The sound driver attach routine should declare its MIXER
|
||||
or AC97 interface to <filename>pcm</filename> by calling
|
||||
<function>mixer_init()</function>. For a MIXER interface,
|
||||
this causes in turn a call to <link linkend="xxxmixer-init"><function>xxxmixer_init()</function></link>.</para>
|
||||
this causes in turn a call to <link
|
||||
linkend="xxxmixer-init"><function>xxxmixer_init()</function></link>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
@ -196,7 +209,8 @@
|
|||
<title>Interfaces</title>
|
||||
|
||||
<para>The interface between the <filename>pcm</filename> core
|
||||
and the sound drivers is defined in terms of <link linkend="kernel-objects">kernel objects</link>.</para>
|
||||
and the sound drivers is defined in terms of <link
|
||||
linkend="kernel-objects">kernel objects</link>.</para>
|
||||
|
||||
<para>There are two main interfaces that a sound driver will
|
||||
usually provide: <emphasis>CHANNEL</emphasis> and either
|
||||
|
@ -235,11 +249,12 @@
|
|||
<para>For sound data transfers, the
|
||||
<filename>pcm</filename> core and the sound drivers
|
||||
communicate through a shared memory area, described by a
|
||||
<varname remap="structname">struct snd_dbuf</varname>.</para>
|
||||
<varname remap="structname">struct
|
||||
snd_dbuf</varname>.</para>
|
||||
|
||||
<para><varname remap="structname">struct snd_dbuf</varname> is private to
|
||||
<filename>pcm</filename>, and sound drivers obtain
|
||||
values of interest by calls to accessor functions
|
||||
<para><varname remap="structname">struct snd_dbuf</varname> is
|
||||
private to <filename>pcm</filename>, and sound drivers
|
||||
obtain values of interest by calls to accessor functions
|
||||
(<function>sndbuf_getxxx()</function>).</para>
|
||||
|
||||
<para>The shared memory area has a size of
|
||||
|
@ -253,7 +268,8 @@
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>pcm</filename> initially fills up the
|
||||
buffer, then calls the sound driver's <link linkend="channel-trigger">
|
||||
buffer, then calls the sound driver's <link
|
||||
linkend="channel-trigger">
|
||||
<function>xxxchannel_trigger()</function></link>
|
||||
function with a parameter of PCMTRIG_START.</para>
|
||||
</listitem>
|
||||
|
@ -273,8 +289,9 @@
|
|||
<listitem>
|
||||
<para><function>chn_intr()</function> arranges to copy new
|
||||
data to the area that was transferred to the device (now
|
||||
free), and make appropriate updates to the
|
||||
<varname remap="structname">snd_dbuf</varname> structure.</para>
|
||||
free), and make appropriate updates to the <varname
|
||||
remap="structname">snd_dbuf</varname>
|
||||
structure.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
@ -301,8 +318,8 @@
|
|||
<calloutlist>
|
||||
<callout arearefs="co-chinit-params">
|
||||
<para><varname>b</varname> is the address for the channel
|
||||
<varname remap="structname">struct snd_dbuf</varname>. It should be
|
||||
initialized in the function by calling
|
||||
<varname remap="structname">struct snd_dbuf</varname>.
|
||||
It should be initialized in the function by calling
|
||||
<function>sndbuf_alloc()</function>. The buffer size to
|
||||
use is normally a small multiple of the 'typical' unit
|
||||
transfer size for your device.</para>
|
||||
|
@ -491,10 +508,10 @@
|
|||
|
||||
<callout arearefs="co-chgetcaps-return">
|
||||
<para>The routine returns a pointer to a (usually
|
||||
statically-defined)
|
||||
<varname remap="structname">pcmchan_caps</varname> structure (defined
|
||||
in <filename>sound/pcm/channel.h</filename>. The
|
||||
structure holds the minimum and maximum sampling
|
||||
statically-defined) <varname
|
||||
remap="structname">pcmchan_caps</varname> structure
|
||||
(defined in <filename>sound/pcm/channel.h</filename>.
|
||||
The structure holds the minimum and maximum sampling
|
||||
frequencies, and the accepted sound formats. Look at
|
||||
any sound driver for an example.</para>
|
||||
</callout>
|
||||
|
@ -626,7 +643,7 @@
|
|||
|
||||
<para><function>xxxmixer_uninit()</function> should ensure
|
||||
that all sound is muted and if possible mixer hardware
|
||||
should be powered down </para>
|
||||
should be powered down.</para>
|
||||
|
||||
<para><function>xxxmixer_reinit()</function> should ensure
|
||||
that the mixer hardware is powered up and any settings not
|
||||
|
|
Loading…
Reference in a new issue