2008-04-30 17:10:46 +04:00
|
|
|
.\" $NetBSD: audio.9,v 1.42 2008/04/30 13:10:58 martin Exp $
|
1997-08-25 02:46:41 +04:00
|
|
|
.\"
|
2000-02-12 01:56:15 +03:00
|
|
|
.\" Copyright (c) 1999, 2000 The NetBSD Foundation, Inc.
|
1997-08-25 02:46:41 +04:00
|
|
|
.\" All rights reserved.
|
|
|
|
.\"
|
1999-04-14 00:25:28 +04:00
|
|
|
.\" This code is derived from software contributed to The NetBSD Foundation
|
|
|
|
.\" by Lennart Augustsson.
|
|
|
|
.\"
|
1997-08-25 02:46:41 +04:00
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
.\" are met:
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
.\"
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
|
|
|
|
.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
|
|
|
|
.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
1997-10-09 01:59:52 +04:00
|
|
|
.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
|
|
|
|
.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
1997-08-25 02:46:41 +04:00
|
|
|
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
|
|
.\" POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
.\"
|
2007-11-10 23:55:33 +03:00
|
|
|
.Dd November 10, 2007
|
1997-08-25 02:46:41 +04:00
|
|
|
.Dt AUDIO 9
|
1999-03-16 03:40:46 +03:00
|
|
|
.Os
|
1997-08-25 02:46:41 +04:00
|
|
|
.Sh NAME
|
|
|
|
.Nm audio
|
|
|
|
.Nd interface between low and high level audio drivers
|
|
|
|
.Sh DESCRIPTION
|
|
|
|
The audio device driver is divided into a high level,
|
|
|
|
hardware independent layer, and a low level hardware
|
2002-10-14 17:43:14 +04:00
|
|
|
dependent layer.
|
|
|
|
The interface between these is the
|
2001-06-21 15:59:00 +04:00
|
|
|
.Va audio_hw_if
|
1997-10-19 23:45:46 +04:00
|
|
|
structure.
|
1997-08-25 02:46:41 +04:00
|
|
|
.Bd -literal
|
|
|
|
struct audio_hw_if {
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*open)(void *, int);
|
|
|
|
void (*close)(void *);
|
|
|
|
int (*drain)(void *);
|
1997-08-25 02:46:41 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*query_encoding)(void *, struct audio_encoding *);
|
|
|
|
int (*set_params)(void *, int, int,
|
2005-01-11 10:19:28 +03:00
|
|
|
audio_params_t *, audio_params_t *,
|
|
|
|
stream_filter_list_t *, stream_filter_list_t *);
|
|
|
|
int (*round_blocksize)(void *, int, int, const audio_params_t *);
|
1997-08-25 02:46:41 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*commit_settings)(void *);
|
1997-08-25 02:46:41 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*init_output)(void *, void *, int);
|
|
|
|
int (*init_input)(void *, void *, int);
|
|
|
|
int (*start_output)(void *, void *, int, void (*)(void *),
|
|
|
|
void *);
|
|
|
|
int (*start_input)(void *, void *, int, void (*)(void *),
|
|
|
|
void *);
|
|
|
|
int (*halt_output)(void *);
|
|
|
|
int (*halt_input)(void *);
|
1997-08-25 02:46:41 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*speaker_ctl)(void *, int);
|
1997-10-19 11:40:26 +04:00
|
|
|
#define SPKR_ON 1
|
|
|
|
#define SPKR_OFF 0
|
1997-08-25 02:46:41 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*getdev)(void *, struct audio_device *);
|
|
|
|
int (*setfd)(void *, int);
|
2001-06-21 15:59:00 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*set_port)(void *, mixer_ctrl_t *);
|
|
|
|
int (*get_port)(void *, mixer_ctrl_t *);
|
1997-08-25 02:46:41 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*query_devinfo)(void *, mixer_devinfo_t *);
|
2001-06-21 15:59:00 +04:00
|
|
|
|
2003-05-06 00:52:52 +04:00
|
|
|
void *(*allocm)(void *, int, size_t, struct malloc_type *, int);
|
|
|
|
void (*freem)(void *, void *, struct malloc_type *);
|
2001-10-03 03:58:03 +04:00
|
|
|
size_t (*round_buffersize)(void *, int, size_t);
|
2003-05-06 00:52:52 +04:00
|
|
|
paddr_t (*mappage)(void *, void *, off_t, int);
|
1997-08-25 02:46:41 +04:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*get_props)(void *);
|
2000-02-12 01:56:15 +03:00
|
|
|
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*trigger_output)(void *, void *, void *, int,
|
2005-01-11 10:19:28 +03:00
|
|
|
void (*)(void *), void *, const audio_params_t *);
|
2001-10-03 03:58:03 +04:00
|
|
|
int (*trigger_input)(void *, void *, void *, int,
|
2005-01-11 10:19:28 +03:00
|
|
|
void (*)(void *), void *, const audio_params_t *);
|
2007-07-31 02:48:46 +04:00
|
|
|
int (*dev_ioctl)(void *, u_long, void *, int, struct lwp *);
|
2006-03-07 18:18:11 +03:00
|
|
|
int (*powerstate)(void *, int);
|
|
|
|
#define AUDIOPOWER_ON 1
|
|
|
|
#define AUDIOPOWER_OFF 0
|
1997-08-25 02:46:41 +04:00
|
|
|
};
|
|
|
|
|
2005-01-11 10:19:28 +03:00
|
|
|
typedef struct audio_params {
|
|
|
|
u_int sample_rate; /* sample rate */
|
|
|
|
u_int encoding; /* e.g. mu-law, linear, etc */
|
|
|
|
u_int precision; /* bits/subframe */
|
|
|
|
u_int validbits; /* valid bits in a subframe */
|
|
|
|
u_int channels; /* mono(1), stereo(2) */
|
|
|
|
} audio_params_t;
|
1997-08-25 02:46:41 +04:00
|
|
|
.Ed
|
1999-03-24 09:46:30 +03:00
|
|
|
.Pp
|
1997-08-25 02:46:41 +04:00
|
|
|
The high level audio driver attaches to the low level driver
|
|
|
|
when the latter calls
|
|
|
|
.Va audio_attach_mi .
|
|
|
|
This call should be
|
|
|
|
.Bd -literal
|
|
|
|
void
|
2000-02-18 00:25:47 +03:00
|
|
|
audio_attach_mi(ahwp, hdl, dev)
|
1997-08-25 02:46:41 +04:00
|
|
|
struct audio_hw_if *ahwp;
|
|
|
|
void *hdl;
|
|
|
|
struct device *dev;
|
|
|
|
.Ed
|
1999-03-24 09:46:30 +03:00
|
|
|
.Pp
|
2001-06-21 15:59:00 +04:00
|
|
|
The
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va audio_hw_if
|
2002-10-14 17:43:14 +04:00
|
|
|
struct is as shown above.
|
|
|
|
The
|
2001-06-21 15:59:00 +04:00
|
|
|
.Va hdl
|
1997-08-25 02:46:41 +04:00
|
|
|
argument is a handle to some low level data structure.
|
|
|
|
It is sent as the first argument to all the functions
|
|
|
|
in
|
|
|
|
.Va audio_hw_if
|
|
|
|
when the high level driver calls them.
|
1997-10-19 23:45:46 +04:00
|
|
|
.Va dev
|
|
|
|
is the device struct for the hardware device.
|
1997-10-19 11:40:26 +04:00
|
|
|
.Pp
|
1997-10-19 23:45:46 +04:00
|
|
|
The upper layer of the audio driver allocates one buffer for playing
|
2002-10-14 17:43:14 +04:00
|
|
|
and one for recording.
|
|
|
|
It handles the buffering of data from the user processes in these.
|
|
|
|
The data is presented to the lower level in smaller chunks, called blocks.
|
2008-04-25 18:16:05 +04:00
|
|
|
If, during playback, there is no data available from the user process when
|
2002-10-14 17:43:14 +04:00
|
|
|
the hardware request another block a block of silence will be used instead.
|
|
|
|
Furthermore, if the user process does not read data quickly enough during
|
|
|
|
recording data will be thrown away.
|
1997-08-25 02:46:41 +04:00
|
|
|
.Pp
|
|
|
|
The fields of
|
|
|
|
.Va audio_hw_if
|
|
|
|
are described in some more detail below.
|
1997-10-19 11:40:26 +04:00
|
|
|
Some fields are optional and can be set to 0 if not needed.
|
1999-03-24 09:46:30 +03:00
|
|
|
.Bl -tag -width indent
|
1997-08-25 02:46:41 +04:00
|
|
|
.It Dv int open(void *hdl, int flags)
|
2005-01-11 10:19:28 +03:00
|
|
|
optional, is called when the audio device is opened.
|
2002-10-14 17:43:14 +04:00
|
|
|
It should initialize the hardware for I/O.
|
|
|
|
Every successful call to
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va open
|
|
|
|
is matched by a call to
|
|
|
|
.Va close .
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv void close(void *hdl)
|
2005-01-11 10:19:28 +03:00
|
|
|
optional, is called when the audio device is closed.
|
1997-08-25 02:46:41 +04:00
|
|
|
.It Dv int drain(void *hdl)
|
|
|
|
optional, is called before the device is closed or when
|
|
|
|
.Dv AUDIO_DRAIN
|
2002-10-14 17:43:14 +04:00
|
|
|
is called.
|
|
|
|
It should make sure that no samples remain in to be played that could
|
|
|
|
be lost when
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va close
|
|
|
|
is called.
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int query_encoding(void *hdl, struct audio_encoding *ae)
|
|
|
|
is used when
|
|
|
|
.Dv AUDIO_GETENC
|
2002-10-14 17:43:14 +04:00
|
|
|
is called.
|
|
|
|
It should fill the
|
1997-10-19 11:40:26 +04:00
|
|
|
.Va audio_encoding
|
1997-10-19 23:45:46 +04:00
|
|
|
structure and return 0 or, if there is no encoding with the
|
|
|
|
given number, return EINVAL.
|
2001-06-21 15:59:00 +04:00
|
|
|
.It Dv int set_params(void *hdl, int setmode, int usemode,
|
2005-01-11 10:19:28 +03:00
|
|
|
.Dv "audio_params_t *play, audio_params_t *rec,"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2005-01-11 10:19:28 +03:00
|
|
|
.Dv "stream_filter_list_t *pfil, stream_filter_list_t *rfil)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
1997-08-25 02:46:41 +04:00
|
|
|
Called to set the audio encoding mode.
|
|
|
|
.Va setmode
|
|
|
|
is a combination of the
|
|
|
|
.Dv AUMODE_RECORD
|
|
|
|
and
|
|
|
|
.Dv AUMODE_PLAY
|
|
|
|
flags to indicate which mode(s) are to be set.
|
|
|
|
.Va usemode
|
|
|
|
is also a combination of these flags, but indicates the current
|
2002-10-14 17:43:14 +04:00
|
|
|
mode of the device (i.e., the value of
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va mode
|
|
|
|
in the
|
|
|
|
.Va audio_info
|
|
|
|
struct).
|
2005-01-11 10:19:28 +03:00
|
|
|
.Pp
|
1997-08-25 02:46:41 +04:00
|
|
|
The
|
|
|
|
.Va play
|
|
|
|
and
|
|
|
|
.Va rec
|
|
|
|
structures contain the encoding parameters that should be set.
|
2005-01-11 10:19:28 +03:00
|
|
|
The values of the structures may also be modified if the hardware
|
|
|
|
cannot be set to exactly the requested mode (e.g., if the requested
|
|
|
|
sampling rate is not supported, but one close enough is).
|
2002-03-11 18:09:51 +03:00
|
|
|
.Pp
|
1997-08-25 02:46:41 +04:00
|
|
|
If the hardware requires software assistance with some encoding
|
2003-04-06 22:20:07 +04:00
|
|
|
(e.g., it might be lacking mu-law support) it should fill the
|
2005-01-11 10:19:28 +03:00
|
|
|
.Va pfil
|
|
|
|
for playing or
|
|
|
|
.Va rfil
|
|
|
|
for recording with conversion information.
|
2002-03-11 18:09:51 +03:00
|
|
|
For example, if
|
|
|
|
.Va play
|
2005-02-20 22:55:05 +03:00
|
|
|
requests [8000Hz, mu-law, 8/8bit, 1ch] and the hardware does not
|
|
|
|
support 8bit mu-law, but 16bit slinear_le, the driver should call
|
2005-02-20 22:48:47 +03:00
|
|
|
.Dv pfil-\*[Gt]append()
|
2005-01-11 10:19:28 +03:00
|
|
|
with
|
|
|
|
.Va pfil ,
|
|
|
|
.Va mulaw_to_slinear16 ,
|
|
|
|
and audio_params_t representing [8000Hz, slinear_le, 16/16bit, 2ch].
|
|
|
|
If the driver needs multiple conversions, a conversion nearest to the
|
|
|
|
hardware should be set to the head of
|
|
|
|
.Va pfil
|
|
|
|
or
|
|
|
|
.Va rfil .
|
|
|
|
The definition of
|
|
|
|
.Dv stream_filter_list_t
|
|
|
|
follows:
|
|
|
|
.Bd -literal
|
|
|
|
typedef struct stream_filter_list {
|
|
|
|
void (*append)(struct stream_filter_list *,
|
|
|
|
stream_filter_factory_t,
|
|
|
|
const audio_params_t *);
|
|
|
|
void (*prepend)(struct stream_filter_list *,
|
|
|
|
stream_filter_factory_t,
|
|
|
|
const audio_params_t *);
|
|
|
|
void (*set)(struct stream_filter_list *, int,
|
|
|
|
stream_filter_factory_t,
|
|
|
|
const audio_params_t *);
|
|
|
|
int req_size;
|
|
|
|
struct stream_filter_req {
|
|
|
|
stream_filter_factory_t *factory;
|
|
|
|
audio_params_t param; /* from-param for recording,
|
|
|
|
to-param for playing */
|
|
|
|
} filters[AUDIO_MAX_FILTERS];
|
|
|
|
} stream_filter_list_t;
|
|
|
|
.Ed
|
2002-03-11 18:09:51 +03:00
|
|
|
.Pp
|
2005-02-20 22:46:15 +03:00
|
|
|
For playing,
|
2005-01-11 10:19:28 +03:00
|
|
|
.Va pfil
|
|
|
|
constructs conversions as follows:
|
|
|
|
.Bd -literal
|
|
|
|
(play) == write(2) input
|
2005-02-20 22:48:47 +03:00
|
|
|
| pfil-\*[Gt]filters[pfil-\*[Gt]req_size-1].factory
|
|
|
|
(pfil-\*[Gt]filters[pfil-\*[Gt]req_size-1].param)
|
|
|
|
| pfil-\*[Gt]filters[pfil-\*[Gt]req_size-2].factory
|
2005-01-11 10:19:28 +03:00
|
|
|
:
|
2005-02-20 22:48:47 +03:00
|
|
|
| pfil-\*[Gt]filters[1].factory
|
|
|
|
(pfil-\*[Gt]filters[1].param)
|
|
|
|
| pfil-\*[Gt]filters[0].factory
|
|
|
|
(pfil-\*[Gt]filters[0].param) == hardware input
|
2005-01-11 10:19:28 +03:00
|
|
|
.Ed
|
2002-03-11 18:09:51 +03:00
|
|
|
.Pp
|
2005-02-20 22:46:15 +03:00
|
|
|
For recording,
|
2005-01-11 10:19:28 +03:00
|
|
|
.Va rfil
|
|
|
|
constructs conversions as follows:
|
|
|
|
.Bd -literal
|
2005-02-20 22:48:47 +03:00
|
|
|
(rfil-\*[Gt]filters[0].param) == hardware output
|
|
|
|
| rfil-\*[Gt]filters[0].factory
|
|
|
|
(rfil-\*[Gt]filters[1].param)
|
|
|
|
| rfil-\*[Gt]filters[1].factory
|
2005-01-11 10:19:28 +03:00
|
|
|
:
|
2005-02-20 22:48:47 +03:00
|
|
|
| rfil-\*[Gt]filters[rfil-\*[Gt]req_size-2].factory
|
|
|
|
(rfil-\*[Gt]filters[rfil-\*[Gt]req_size-1].param)
|
|
|
|
| rfil-\*[Gt]filters[rfil-\*[Gt]req_size-1].factory
|
2005-01-11 10:19:28 +03:00
|
|
|
(rec) == read(2) output
|
|
|
|
.Ed
|
2002-03-11 18:09:51 +03:00
|
|
|
.Pp
|
1997-08-25 02:46:41 +04:00
|
|
|
If the device does not have the
|
|
|
|
.Dv AUDIO_PROP_INDEPENDENT
|
|
|
|
property the same value is passed in both
|
|
|
|
.Va play
|
|
|
|
and
|
|
|
|
.Va rec
|
|
|
|
and the encoding parameters from
|
|
|
|
.Va play
|
|
|
|
is copied into
|
|
|
|
.Va rec
|
|
|
|
after the call to
|
|
|
|
.Va set_params .
|
|
|
|
Return 0 on success, otherwise an error code.
|
2005-01-11 10:19:28 +03:00
|
|
|
.It Dv int round_blocksize(void *hdl, int bs, int mode,
|
|
|
|
.Dv "const audio_params_t *param)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called with the block size,
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va bs ,
|
2005-01-11 10:19:28 +03:00
|
|
|
that has been computed by the upper layer,
|
|
|
|
.Va mode ,
|
|
|
|
.Dv AUMODE_PLAY
|
|
|
|
or
|
|
|
|
.Dv AUMODE_RECORD ,
|
|
|
|
and
|
|
|
|
.Va param ,
|
|
|
|
encoding parameters for the hardware.
|
2002-10-14 17:43:14 +04:00
|
|
|
It should return a block size, possibly changed according to the needs
|
|
|
|
of the hardware driver.
|
1997-08-25 02:46:41 +04:00
|
|
|
.It Dv int commit_settings(void *hdl)
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called after all calls to
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va set_params ,
|
1997-10-19 23:45:46 +04:00
|
|
|
and
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va set_port ,
|
2002-10-14 17:43:14 +04:00
|
|
|
are done.
|
|
|
|
A hardware driver that needs to get the hardware in and out of command
|
|
|
|
mode for each change can save all the changes during previous calls and
|
|
|
|
do them all here.
|
1997-08-25 02:46:41 +04:00
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int init_output(void *hdl, void *buffer, int size)
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called before any output starts, but when the total
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va size
|
|
|
|
of the output
|
2001-06-21 15:59:00 +04:00
|
|
|
.Va buffer
|
2002-10-14 17:43:14 +04:00
|
|
|
has been determined.
|
|
|
|
It can be used to initialize looping DMA for hardware that needs that.
|
1997-08-25 02:46:41 +04:00
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int init_input(void *hdl, void *buffer, int size)
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called before any input starts, but when the total
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va size
|
|
|
|
of the input
|
2001-06-21 15:59:00 +04:00
|
|
|
.Va buffer
|
2002-10-14 17:43:14 +04:00
|
|
|
has been determined.
|
|
|
|
It can be used to initialize looping DMA for hardware that needs that.
|
1997-08-25 02:46:41 +04:00
|
|
|
Return 0 on success, otherwise an error code.
|
2000-07-24 19:00:07 +04:00
|
|
|
.It Dv int start_output(void *hdl, void *block, int blksize,
|
1997-10-19 23:45:46 +04:00
|
|
|
.Dv "void (*intr)(void*), void *intrarg)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
1997-10-19 11:40:26 +04:00
|
|
|
is called to start the transfer of
|
2000-07-24 19:00:07 +04:00
|
|
|
.Va blksize
|
1997-08-25 02:46:41 +04:00
|
|
|
bytes from
|
|
|
|
.Va block
|
2002-10-14 17:43:14 +04:00
|
|
|
to the audio hardware.
|
|
|
|
The call should return when the data transfer has been initiated
|
|
|
|
(normally with DMA).
|
|
|
|
When the hardware is ready to accept more samples the function
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va intr
|
|
|
|
should be called with the argument
|
|
|
|
.Va intrarg .
|
|
|
|
Calling
|
|
|
|
.Va intr
|
|
|
|
will normally initiate another call to
|
|
|
|
.Va start_output .
|
|
|
|
Return 0 on success, otherwise an error code.
|
2000-07-24 19:00:07 +04:00
|
|
|
.It Dv int start_input(void *hdl, void *block, int blksize,
|
1997-10-19 23:45:46 +04:00
|
|
|
.Dv "void (*intr)(void*), void *intrarg)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
1997-10-19 11:40:26 +04:00
|
|
|
is called to start the transfer of
|
2000-07-24 19:00:07 +04:00
|
|
|
.Va blksize
|
1997-08-25 02:46:41 +04:00
|
|
|
bytes to
|
|
|
|
.Va block
|
2002-10-14 17:43:14 +04:00
|
|
|
from the audio hardware.
|
|
|
|
The call should return when the data transfer has been initiated
|
|
|
|
(normally with DMA).
|
|
|
|
When the hardware is ready to deliver more samples the function
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va intr
|
|
|
|
should be called with the argument
|
|
|
|
.Va intrarg .
|
|
|
|
Calling
|
|
|
|
.Va intr
|
|
|
|
will normally initiate another call to
|
2001-06-21 15:59:00 +04:00
|
|
|
.Va start_input .
|
1997-08-25 02:46:41 +04:00
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int halt_output(void *hdl)
|
1997-10-19 11:40:26 +04:00
|
|
|
is called to abort the output transfer (started by
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va start_output )
|
|
|
|
in progress.
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int halt_input(void *hdl)
|
1997-10-19 11:40:26 +04:00
|
|
|
is called to abort the input transfer (started by
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va start_input )
|
|
|
|
in progress.
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int speaker_ctl(void *hdl, int on)
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called when a half duplex device changes between
|
2002-10-14 17:43:14 +04:00
|
|
|
playing and recording.
|
|
|
|
It can, e.g., be used to turn on
|
1997-08-25 02:46:41 +04:00
|
|
|
and off the speaker.
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int getdev(void *hdl, struct audio_device *ret)
|
2001-06-21 15:59:00 +04:00
|
|
|
Should fill the
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va audio_device
|
|
|
|
struct with relevant information about the driver.
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int setfd(void *hdl, int fd)
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called when
|
1997-08-25 02:46:41 +04:00
|
|
|
.Dv AUDIO_SETFD
|
1997-10-11 19:33:26 +04:00
|
|
|
is used, but only if the device has AUDIO_PROP_FULLDUPLEX set.
|
1997-08-25 02:46:41 +04:00
|
|
|
Return 0 on success, otherwise an error code.
|
2007-11-10 23:54:56 +03:00
|
|
|
.It Dv int set_port(void *hdl, mixer_ctrl_t *mc)
|
1997-10-19 11:40:26 +04:00
|
|
|
is called in when
|
1997-08-25 02:46:41 +04:00
|
|
|
.Dv AUDIO_MIXER_WRITE
|
2002-10-14 17:43:14 +04:00
|
|
|
is used.
|
|
|
|
It should take data from the
|
2007-11-10 23:54:56 +03:00
|
|
|
.Va mixer_ctrl_t
|
1997-10-11 19:33:26 +04:00
|
|
|
struct at set the corresponding mixer values.
|
1997-08-25 02:46:41 +04:00
|
|
|
Return 0 on success, otherwise an error code.
|
2007-11-10 23:54:56 +03:00
|
|
|
.It Dv int get_port(void *hdl, mixer_ctrl_t *mc)
|
1997-10-19 11:40:26 +04:00
|
|
|
is called in when
|
1997-08-25 02:46:41 +04:00
|
|
|
.Dv AUDIO_MIXER_READ
|
2002-10-14 17:43:14 +04:00
|
|
|
is used.
|
|
|
|
It should fill the
|
2007-11-10 23:54:56 +03:00
|
|
|
.Va mixer_ctrl_t
|
1997-08-25 02:46:41 +04:00
|
|
|
struct.
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int query_devinfo(void *hdl, mixer_devinfo_t *di)
|
1997-10-19 11:40:26 +04:00
|
|
|
is called in when
|
1997-08-25 02:46:41 +04:00
|
|
|
.Dv AUDIO_MIXER_DEVINFO
|
2002-10-14 17:43:14 +04:00
|
|
|
is used.
|
|
|
|
It should fill the
|
1997-10-19 23:45:46 +04:00
|
|
|
.Va mixer_devinfo_t
|
1997-08-25 02:46:41 +04:00
|
|
|
struct.
|
|
|
|
Return 0 on success, otherwise an error code.
|
2003-05-06 00:52:52 +04:00
|
|
|
.It Dv "void *allocm(void *hdl, int direction, size_t size, struct malloc_type *type, int flags)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2002-10-14 17:43:14 +04:00
|
|
|
optional, is called to allocate the device buffers.
|
|
|
|
If not present
|
1997-08-25 02:46:41 +04:00
|
|
|
.Xr malloc 9
|
1999-06-16 18:19:27 +04:00
|
|
|
is used instead (with the same arguments but the first two).
|
1997-08-25 02:46:41 +04:00
|
|
|
The reason for using a device dependent routine instead of
|
|
|
|
.Xr malloc 9
|
|
|
|
is that some buses need special allocation to do DMA.
|
|
|
|
Returns the address of the buffer, or 0 on failure.
|
2003-05-06 00:52:52 +04:00
|
|
|
.It Dv void freem(void *hdl, void *addr, struct malloc_type *type)
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called to free memory allocated by
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va alloc .
|
|
|
|
If not supplied
|
|
|
|
.Xr free 9
|
|
|
|
is used.
|
1999-06-13 00:10:55 +04:00
|
|
|
.It Dv size_t round_buffersize(void *hdl, int direction, size_t bufsize)
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called at startup to determine the audio
|
2002-10-14 17:43:14 +04:00
|
|
|
buffer size.
|
|
|
|
The upper layer supplies the suggested size in
|
1997-08-25 02:46:41 +04:00
|
|
|
.Va bufsize ,
|
|
|
|
which the hardware driver can then change if needed.
|
|
|
|
E.g., DMA on the ISA bus cannot exceed 65536 bytes.
|
2003-05-06 00:52:52 +04:00
|
|
|
.It Dv "paddr_t mappage(void *hdl, void *addr, off_t offs, int prot)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
1997-10-19 11:40:26 +04:00
|
|
|
optional, is called for
|
1997-08-25 02:46:41 +04:00
|
|
|
.Xr mmap 2 .
|
|
|
|
Should return the map value for the page at offset
|
|
|
|
.Va offs
|
|
|
|
from address
|
|
|
|
.Va addr
|
|
|
|
mapped with protection
|
|
|
|
.Va prot .
|
|
|
|
Returns -1 on failure, or a machine dependent opaque value
|
|
|
|
on success.
|
|
|
|
.It Dv int get_props(void *hdl)
|
2002-10-14 17:43:14 +04:00
|
|
|
Should return the device properties; i.e., a combination of
|
1997-08-25 02:46:41 +04:00
|
|
|
AUDIO_PROP_xxx.
|
2000-02-12 01:56:15 +03:00
|
|
|
.It Dv int trigger_output(void *hdl, void *start, void *end,
|
|
|
|
.Dv "int blksize, void (*intr)(void*), void *intrarg,"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2005-01-11 10:19:28 +03:00
|
|
|
.Dv "const audio_params_t *param)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2000-02-12 01:56:15 +03:00
|
|
|
optional, is called to start the transfer of data from the circular buffer
|
|
|
|
delimited by
|
|
|
|
.Va start
|
|
|
|
and
|
|
|
|
.Va end
|
|
|
|
to the audio hardware, parameterized as in
|
|
|
|
.Va param .
|
|
|
|
The call should return when the data transfer has been initiated
|
2002-10-14 17:43:14 +04:00
|
|
|
(normally with DMA).
|
|
|
|
When the hardware is finished transferring each
|
2000-07-24 19:00:07 +04:00
|
|
|
.Va blksize
|
2000-02-12 01:56:15 +03:00
|
|
|
sized block, the function
|
|
|
|
.Va intr
|
|
|
|
should be called with the argument
|
|
|
|
.Va intrarg
|
|
|
|
(typically from the audio hardware interrupt service routine).
|
|
|
|
Once started the transfer may be stopped using
|
|
|
|
.Va halt_output .
|
|
|
|
Return 0 on success, otherwise an error code.
|
|
|
|
.It Dv int trigger_input(void *hdl, void *start, void *end,
|
|
|
|
.Dv "int blksize, void (*intr)(void*), void *intrarg,"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2005-01-11 10:19:28 +03:00
|
|
|
.Dv "const audio_params_t *param)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2000-02-12 01:56:15 +03:00
|
|
|
optional, is called to start the transfer of data from the audio hardware,
|
|
|
|
parameterized as in
|
|
|
|
.Va param ,
|
|
|
|
to the circular buffer delimited by
|
|
|
|
.Va start
|
|
|
|
and
|
|
|
|
.Va end .
|
|
|
|
The call should return when the data transfer has been initiated
|
2002-10-14 17:43:14 +04:00
|
|
|
(normally with DMA).
|
|
|
|
When the hardware is finished transferring each
|
2000-07-24 19:00:07 +04:00
|
|
|
.Va blksize
|
2000-02-12 01:56:15 +03:00
|
|
|
sized block, the function
|
|
|
|
.Va intr
|
|
|
|
should be called with the argument
|
|
|
|
.Va intrarg
|
|
|
|
(typically from the audio hardware interrupt service routine).
|
|
|
|
Once started the transfer may be stopped using
|
|
|
|
.Va halt_input .
|
|
|
|
Return 0 on success, otherwise an error code.
|
2007-03-07 03:41:16 +03:00
|
|
|
.It Dv int dev_ioctl(void *hdl, u_long cmd, void *addr,
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2005-12-20 22:53:14 +03:00
|
|
|
.Dv "int flag, struct lwp *l)"
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2001-10-03 03:58:03 +04:00
|
|
|
optional, is called when an
|
|
|
|
.Xr ioctl 2
|
|
|
|
is not recognized by the generic audio driver.
|
|
|
|
Return 0 on success, otherwise an error code.
|
2006-03-07 18:18:11 +03:00
|
|
|
.It Dv int powerstate(void *hdl, int state)
|
2006-03-11 14:52:17 +03:00
|
|
|
.Pp
|
2006-03-07 18:18:11 +03:00
|
|
|
optional, is called on the first open and last close of the audio
|
|
|
|
device.
|
|
|
|
.Va state
|
2006-03-11 14:52:17 +03:00
|
|
|
may be one of
|
|
|
|
.Dv AUDIOPOWER_ON
|
|
|
|
or
|
|
|
|
.Dv AUDIOPOWER_OFF .
|
|
|
|
Returns 0 on success, otherwise an error code.
|
1997-08-25 02:46:41 +04:00
|
|
|
.El
|
1999-03-24 09:46:30 +03:00
|
|
|
.Pp
|
1997-10-19 11:40:26 +04:00
|
|
|
The
|
|
|
|
.Va query_devinfo
|
|
|
|
method should define certain mixer controls for
|
|
|
|
.Dv AUDIO_SETINFO
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
to be able to change the port and gain,
|
|
|
|
and
|
|
|
|
.Dv AUDIO_GETINFO
|
|
|
|
to read them, as follows.
|
1997-10-19 11:40:26 +04:00
|
|
|
.Pp
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
If the record mixer is capable of input from more than one source,
|
|
|
|
it should define
|
1997-10-19 11:40:26 +04:00
|
|
|
.Dv AudioNsource
|
|
|
|
in class
|
|
|
|
.Dv AudioCrecord .
|
|
|
|
This mixer control should be of type
|
|
|
|
.Dv AUDIO_MIXER_ENUM
|
|
|
|
or
|
|
|
|
.Dv AUDIO_MIXER_SET
|
|
|
|
and enumerate the possible input sources.
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
Each of the named sources for which the recording level can be set
|
|
|
|
should have a control in the
|
|
|
|
.Dv AudioCrecord
|
1997-10-19 11:40:26 +04:00
|
|
|
class of type
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
.Dv AUDIO_MIXER_VALUE ,
|
|
|
|
except the
|
|
|
|
.Qq mixerout
|
|
|
|
source is special,
|
|
|
|
and will never have its own control.
|
|
|
|
Its selection signifies,
|
|
|
|
rather,
|
|
|
|
that various sources in class
|
|
|
|
.Dv AudioCrecord
|
2005-02-14 16:29:03 +03:00
|
|
|
will be combined and presented to the single recording output
|
2004-02-01 00:33:08 +03:00
|
|
|
in the same fashion that the sources of class
|
|
|
|
.Dv AudioCinputs
|
|
|
|
are combined and presented to the playback output(s).
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
If the overall recording level can be changed,
|
|
|
|
regardless of the input source,
|
|
|
|
then this control should be named
|
|
|
|
.Dv AudioNmaster
|
1997-10-19 11:40:26 +04:00
|
|
|
and be of class
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
.Dv AudioCrecord .
|
|
|
|
.Pp
|
|
|
|
Controls for various sources that affect only the playback output,
|
|
|
|
as opposed to recording,
|
|
|
|
should be in the
|
2004-02-01 00:33:08 +03:00
|
|
|
.Dv AudioCinputs
|
2005-02-14 16:28:24 +03:00
|
|
|
class,
|
|
|
|
as of course should any controls that affect both playback and recording.
|
1997-10-19 11:40:26 +04:00
|
|
|
.Pp
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
If the play
|
|
|
|
mixer is capable of output to more than one destination,
|
|
|
|
it should define
|
|
|
|
.Dv AudioNselect
|
1997-10-19 11:40:26 +04:00
|
|
|
in class
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
.Dv AudioCoutputs .
|
1997-10-19 11:40:26 +04:00
|
|
|
This mixer control should be of type
|
|
|
|
.Dv AUDIO_MIXER_ENUM
|
|
|
|
or
|
|
|
|
.Dv AUDIO_MIXER_SET
|
|
|
|
and enumerate the possible destinations.
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
For each of the named destinations for which the output level can be set,
|
|
|
|
there should be
|
1997-10-19 11:40:26 +04:00
|
|
|
a control in the
|
|
|
|
.Dv AudioCoutputs
|
|
|
|
class of type
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
.Dv AUDIO_MIXER_VALUE .
|
|
|
|
If the overall output level can be changed,
|
|
|
|
which is invariably the case,
|
|
|
|
then this control should be named
|
1997-10-19 11:40:26 +04:00
|
|
|
.Dv AudioNmaster
|
|
|
|
and be of class
|
|
|
|
.Dv AudioCoutputs .
|
Fix a couple of long-standing bugs in the volume control(s) part of the
audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
2004-01-31 03:07:56 +03:00
|
|
|
.Pp
|
|
|
|
There's one additional source recognized specially by
|
|
|
|
.Dv AUDIO_SETINFO
|
|
|
|
and
|
|
|
|
.Dv AUDIO_GETINFO ,
|
|
|
|
to be presented as monitor_gain,
|
|
|
|
and that is a control named
|
|
|
|
.Dv AudioNmonitor ,
|
|
|
|
of class
|
|
|
|
.Dv AudioCmonitor .
|
1997-08-25 02:46:41 +04:00
|
|
|
.Sh SEE ALSO
|
|
|
|
.Xr audio 4
|
1997-10-19 23:45:46 +04:00
|
|
|
.Sh HISTORY
|
|
|
|
This
|
|
|
|
.Nm
|
|
|
|
interface first appeared in
|
|
|
|
.Nx 1.3 .
|