Whitespace-only fixes. Translators, please ignore.
This commit is contained in:
Warren Block
parent
9dc994da05
commit
15d408c4f4
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=42407
1 changed files with 349 additions and 359 deletions
|
|
@ -42,14 +42,17 @@
|
|||
multimedia applications to be ported without
|
||||
modification.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Common code for processing sound data (format
|
||||
conversions, virtual channels).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A uniform software interface to hardware-specific audio
|
||||
interface modules.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Additional support for some common hardware interfaces
|
||||
(ac97), or shared hardware-specific code (ex: ISA DMA
|
||||
|
|
@ -58,8 +61,9 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>The support for specific sound cards is implemented by
|
||||
hardware-specific drivers, which provide channel and mixer interfaces
|
||||
to plug into the generic <devicename>pcm</devicename> code.</para>
|
||||
hardware-specific drivers, which provide channel and mixer
|
||||
interfaces to plug into the generic <devicename>pcm</devicename>
|
||||
code.</para>
|
||||
|
||||
<para>In this chapter, the term <devicename>pcm</devicename> will
|
||||
refer to the central, common part of the sound driver, as
|
||||
|
|
@ -76,7 +80,6 @@
|
|||
example, you can find a commented driver template at
|
||||
<ulink url="http://people.FreeBSD.org/~cg/template.c">
|
||||
http://people.FreeBSD.org/~cg/template.c</ulink></para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="oss-files">
|
||||
|
|
@ -92,7 +95,6 @@
|
|||
while the <filename>pci/</filename>, <filename>isa/</filename>
|
||||
and <filename>usb/</filename> directories have the drivers
|
||||
for PCI and ISA boards, and for USB audio devices.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="pcm-probe-and-attach">
|
||||
|
|
@ -107,11 +109,11 @@
|
|||
<para>However, sound drivers differ in some ways:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>They declare themselves as <devicename>pcm</devicename>
|
||||
class devices, with a <structname>struct
|
||||
snddev_info</structname> device private structure:</para>
|
||||
class devices, with a
|
||||
<structname>struct snddev_info</structname> device private
|
||||
structure:</para>
|
||||
|
||||
<programlisting> static driver_t xxx_driver = {
|
||||
"pcm",
|
||||
|
|
@ -122,11 +124,12 @@
|
|||
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> 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 <devicename>pcm</devicename> by the calls to
|
||||
<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
|
||||
<devicename>pcm</devicename> by the calls to
|
||||
<function>pcm_register()</function> and
|
||||
<function>mixer_init()</function>.
|
||||
<devicename>pcm</devicename> later passes back this address
|
||||
|
|
@ -138,8 +141,8 @@
|
|||
<para>The sound driver attach routine should declare its MIXER
|
||||
or AC97 interface to <devicename>pcm</devicename> 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>
|
||||
|
|
@ -170,7 +173,9 @@
|
|||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>There are two possible methods to handle non-PnP devices:</para>
|
||||
<para>There are two possible methods to handle non-PnP
|
||||
devices:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Use a <function>device_identify()</function> method
|
||||
|
|
@ -180,6 +185,7 @@
|
|||
device, creates a new pcm device which is then passed to
|
||||
probe/attach.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Use a custom kernel configuration with appropriate hints
|
||||
for pcm devices (example:
|
||||
|
|
@ -192,7 +198,6 @@
|
|||
<function>device_resume</function> and
|
||||
<function>device_shutdown</function> routines, so that power
|
||||
management and module unloading function correctly.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="oss-interfaces">
|
||||
|
|
@ -227,10 +232,10 @@
|
|||
|
||||
<para>The second parameter is a pointer to the private
|
||||
channel data structure, except for
|
||||
<function>channel_init()</function> which has a pointer to the
|
||||
private device structure (and returns the channel pointer
|
||||
for further use by <devicename>pcm</devicename>).</para>
|
||||
|
||||
<function>channel_init()</function> which has a pointer to
|
||||
the private device structure (and returns the channel
|
||||
pointer for further use by
|
||||
<devicename>pcm</devicename>).</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -281,9 +286,7 @@
|
|||
free), and make appropriate updates to the
|
||||
<structname>snd_dbuf</structname> structure.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3 id="xxxchannel-init">
|
||||
|
|
@ -306,7 +309,6 @@
|
|||
}</programlisting>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs="co-chinit-params">
|
||||
<para><varname>b</varname> is the address for the channel
|
||||
<structname>struct snd_dbuf</structname>. It should be
|
||||
|
|
@ -332,9 +334,7 @@
|
|||
area used to control this channel. This will be passed
|
||||
as a parameter to other channel interface calls.</para>
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -358,7 +358,6 @@
|
|||
<literal>AFMT_XXX value</literal>
|
||||
(<filename>soundcard.h</filename>).</para>
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
</sect3>
|
||||
|
||||
|
|
@ -376,7 +375,6 @@
|
|||
...
|
||||
return speed;
|
||||
}</programlisting>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -410,10 +408,8 @@
|
|||
size. In case the block size is indeed changed,
|
||||
<function>sndbuf_resize()</function> should be called to
|
||||
adjust the buffer.</para>
|
||||
|
||||
</callout>
|
||||
</calloutlist>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3 id="channel-trigger">
|
||||
|
|
@ -435,8 +431,8 @@
|
|||
<callout arearefs="co-chtrigger-params">
|
||||
<para><varname>go</varname> defines the action for the
|
||||
current call. The possible values are:</para>
|
||||
<itemizedlist>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><literal>PCMTRIG_START</literal>: the driver
|
||||
should start a data transfer from or to the channel
|
||||
|
|
@ -460,16 +456,15 @@
|
|||
stop the current transfer.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</callout>
|
||||
</calloutlist>
|
||||
|
||||
<note><para>If the driver uses ISA DMA,
|
||||
<function>sndbuf_isadma()</function> should be called before
|
||||
performing actions on the device, and will take care of the
|
||||
DMA chip side of things.</para>
|
||||
<note>
|
||||
<para>If the driver uses ISA DMA,
|
||||
<function>sndbuf_isadma()</function> should be called
|
||||
before performing actions on the device, and will take
|
||||
care of the DMA chip side of things.</para>
|
||||
</note>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -477,10 +472,9 @@
|
|||
|
||||
<para><function>xxxchannel_getptr()</function> returns the
|
||||
current offset in the transfer buffer. This will typically
|
||||
be called by <function>chn_intr()</function>, and this is how
|
||||
<devicename>pcm</devicename> knows where it can transfer
|
||||
be called by <function>chn_intr()</function>, and this is
|
||||
how <devicename>pcm</devicename> knows where it can transfer
|
||||
new data.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -492,7 +486,6 @@
|
|||
structures are dynamically allocated or if
|
||||
<function>sndbuf_alloc()</function> was not used for buffer
|
||||
allocation.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -508,16 +501,14 @@
|
|||
|
||||
<callout arearefs="co-chgetcaps-return">
|
||||
<para>The routine returns a pointer to a (usually
|
||||
statically-defined) <structname>pcmchan_caps</structname>
|
||||
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>
|
||||
statically-defined)
|
||||
<structname>pcmchan_caps</structname> 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>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -525,13 +516,13 @@
|
|||
|
||||
<para><function>channel_reset()</function>,
|
||||
<function>channel_resetdone()</function>, and
|
||||
<function>channel_notify()</function> are for special purposes
|
||||
and should not be implemented in a driver without discussing
|
||||
it on the &a.multimedia;.</para>
|
||||
<function>channel_notify()</function> are for special
|
||||
purposes and should not be implemented in a driver without
|
||||
discussing it on the &a.multimedia;.</para>
|
||||
|
||||
<para><function>channel_setdir()</function> is deprecated.</para>
|
||||
<para><function>channel_setdir()</function> is
|
||||
deprecated.</para>
|
||||
</sect3>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
@ -573,7 +564,6 @@
|
|||
<filename>soundcard.h</filename>
|
||||
(<literal>SOUND_MASK_XXX</literal> values and
|
||||
<literal>SOUND_MIXER_XXX</literal> bit shifts).</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
|
@ -593,10 +583,11 @@
|
|||
|
||||
<calloutlist>
|
||||
<callout arearefs="co-mxset-params">
|
||||
<para>The device is specified as a <literal>SOUND_MIXER_XXX</literal>
|
||||
value</para> <para>The volume values are specified in
|
||||
range [0-100]. A value of zero should mute the
|
||||
device.</para>
|
||||
<para>The device is specified as a
|
||||
<literal>SOUND_MIXER_XXX</literal> value</para>
|
||||
|
||||
<para>The volume values are specified in range [0-100].
|
||||
A value of zero should mute the device.</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs="co-mxset-return">
|
||||
|
|
@ -651,7 +642,6 @@
|
|||
that the mixer hardware is powered up and any settings not
|
||||
controlled by <function>mixer_set()</function> or
|
||||
<function>mixer_setrecsrc()</function> are restored.</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
|
|
@ -661,19 +651,20 @@
|
|||
<indexterm><primary>AC97</primary></indexterm>
|
||||
|
||||
<para>The <emphasis>AC97</emphasis> interface is implemented
|
||||
by drivers with an AC97 codec. It only has three methods:</para>
|
||||
by drivers with an AC97 codec. It only has three
|
||||
methods:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para><function>xxxac97_init()</function> returns
|
||||
the number of ac97 codecs found.</para>
|
||||
<listitem>
|
||||
<para><function>xxxac97_init()</function> returns the number
|
||||
of ac97 codecs found.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para><function>ac97_read()</function> and
|
||||
<function>ac97_write()</function> read or write a specified
|
||||
register.</para>
|
||||
<listitem>
|
||||
<para><function>ac97_read()</function> and
|
||||
<function>ac97_write()</function> read or write a
|
||||
specified register.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>The <emphasis>AC97</emphasis> interface is used by the
|
||||
|
|
@ -681,7 +672,6 @@
|
|||
level operations. Look at
|
||||
<filename>sound/pci/maestro3.c</filename> or many others under
|
||||
<filename>sound/pci/</filename> for an example.</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
Loading…
Reference in a new issue