| Age | Commit message (Collapse) | Author |
|---|
|
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.
ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it
up a few weeks ago
|
|
the obvious cases to return EINVAL and ENXIO.
ok tedu deraadt
|
|
The audio side is a bit lacking; it does not yet mute all types of
devices.
from Alexander Polakov
ok jakemsr
|
|
#include "foo.h"
#if NFOO > 0
(whole file)
#endif
since config(8) file inclusion rules already do it for you.
ok deraadt@
|
|
context, because drivers (like eso(4) and envy(4)) might want to sleep
in their halt method.
|
|
DVACT_QUIESCE:
1) waits until ringbuffer current position wraps back to the start of
the buffer
2) stops playback and/or recording by way of the hardware drivers' "halt"
audio_hw_if method
3) blocks userland access to audio device
4) saves the current state of the master mute, then mutes it
DVACT_RESUME:
1) reprogram hardware stream parameters for playback or recording
if they were active at DVACT_QUIESCE by way of hardware drivers'
"set_params" audio_hw_if method
2) start playback or recording if they were active at DVACT_QUIESCE
by way of hardware drivers' "trigger" or "start" audio_hw_if method
3) restores master mute state as it was at DVACT_QUIESCE
4) wakes up blocked userland processes accessing the hardware
|
|
for both structs, the new members are 'bps' and 'msb', which
describe the number of bytes per sample and data alignment in the
sample, respectively. drivers must properly set these fields in
the 'query_encoding', 'set_parameters' and 'get_default_params'
hardware interface methods.
discussed with ratchov, deraadt
|
|
supported it doesn't do any harm), so put the KNOTE() in selwakeup() itself and
remove it from any occurences where both are used, except one for kqueue itself
and one in sys_pipe.c (where the selwakeup is under a PIPE_SEL flag).
Based on a diff from tedu.
ok deraadt
|
|
pointer to the low level driver's softc, not audio's softc. nothing
is actually using this yet.
ok ratchov
|
|
This is needed for the addition of further suspend/resume actions.
Okay deraadt@, marco@.
|
|
been written to the device, instead of waiting for a write(2)
when the buffer is or will be over the high water mark.
ok ratchov@
|
|
help from and ok jakemsr
|
|
make the audio driver missing blocks and, thus, breaking
full-duplex apps.
help and ok jakemsr
|
|
discussed with and ok ratchov; manpage tweak from naddy, thanks
|
|
playback parameters (like the macppc i2s devices), be sure to
synchronise recording parameters to playback parameters when
configuring for full-duplex operation, as audio(4) dictates.
ok ratchov
|
|
values of the audio_params structure during AUDIO_SETINFO if the
hardware cannot be set to exactly the requested mode.
some drivers do this sometimes. others always return EINVAL if there
isn't an exact match.
be more consistent. only return EINVAL if an absurd parameter was
requested, otherwise return a supported set of parameters, as close
as possible to what was requested.
with/ok ratchov@
|
|
ioctls.
ok ratchov@
|
|
|
|
properly in audio_rint(), the periodic boundary conditions aren't met. This
causes, later read(2) to return EFAULT while trying to access unmapped
regions of the kernel address space. Fix this by using the correct pointer
arithmetic.
ok jakemsr@
|
|
instead of 8-bit mono mulaw @ 8kHz.
this is just the infrastructure; no drivers are specifying a default
yet.
ok ratchov@, deanna@
|
|
for both recording and playback.
ok ratchov
|
|
record modes. This makes possible to have blocks of the same duration if the
play and record formats are different. The API change is backward
compatible, so it shouldn't be noticed by current audio ports.
ok jakemsr
|
|
audiosetinfo(), so the block size don't get scaled twice. Also fix the
formula used in audiosetinfo().
ok jakemsr
|
|
size minus one block. Otherwise, recording cannot work with 32kB blocks.
ok jakemsr@
|
|
blocksize sets the current audio blocksize. The generic audio
driver layer and the hardware driver have the opportunity to ad-
just this block size to get it within implementation-required
limits. Upon return from an AUDIO_SETINFO call, the actual
blocksize set is returned in this field. Normally the blocksize
is calculated to correspond to 50ms of sound and it is recalcu-
lated when the encoding parameter changes, but if the blocksize
is set explicitly this value becomes sticky, i.e., it remains
even when the encoding is changed. The stickiness can be cleared
by reopening the device or setting the blocksize to 0.
however, there were insufficient checks to make the blocksize is
actually sticky once it is set by the user. this adds them.
ok ratchov@
|
|
and monitor_gain; this makes play.gain always usable as general purpose
volume knob even on devices that don't have outputs.master.
ok jakemsr@, deanna@
|
|
(basically only audio_fill_silence() must be updated) and bump max channel
number to 12
ok jakemsr@
|
|
sample (eg. if write(2) have written an odd number of bytes and 16bit
encoding is used), so we'll not properly write silence. To fix this,
round start pointer to fill with silence uncomplete samples too.
ok jakemsr@
|
|
consider that the ring buffer has overrrun if (used >= usedhigh) and not
if (used >= usedhigh + blksize), otherwise recording doesn't work when
large enough blocks are used
ok jakemsr@
|
|
audio_calcwater() to do so
ok jakemsr@
|
|
is unusable with lowat = 1
ok jakemsr@
|
|
size to the given number of frames per second, all changes pass through it.
If parameters are changed or the user requested a new block size (or both),
the block size is recalculated.
ok jakemsr
|
|
the buffer size
ok jakemsr
|
|
data structure these ioctls use, audio_bufinfo.
these ioctls return information about the play and record buffers
into the audio_bufinfo structure.
these are being added to aid in porting non-native audio applications
and libraries, and to fix issues in our OSS audio emulation. these
ioctls exist only on OpenBSD and should not be used in code intended
for distribution.
ok ratchov
|
|
by deanna@
ok jakemsr@
|
|
uninitialized variable.
found by deanna@, ok jackmsr@
|
|
Sun audio.
input from and ok ratchov
|
|
functions instead of doing things the hard way.
also add some bits to au_set_gain() so it sets a gain that is within
limits. its possible to pass in an out-of-range value through
audioctl(1) as well.
ok ratchov
|
|
ok ratchov
|
|
ok jakemsr@
|
|
errors when running audioctl(1) on devices without master controls
ok jakemsr@
|
|
if the selected recording port is not a port the limited /dev/audio[ctl]
interface to mixer controls supports.
ok ratchov@
|
|
documentation change
the audio layer is still too "imperfect" for this change
fixes problems reported aanriot, matthieu and dtucker
requested by deraadt
|
|
convert to userland sample size when needed.
why this subsystem wasn't written with samples as the basic unit of
measure is beyond me.
|
|
the hardware drivers just set a conversion function.
when the MI audio layer needs to add silence, it adds silence in the
userland format, but the amount added is for the hardware sample size.
this diff fixes both record mode by sending the right amount, and
play mode by converting the silence to the right format.
|
|
this interface to mixer functionality is very limited, and is only
used for recording. it only recognizes 'mic', 'cd', and 'line' as
valid recording inputs. many devices have other inputs. because of
the way AUDIO_INITINFO works, it is impossible to expand this API to
include all devices.
this fixes another common cause of audioctl(1) problems. AUDIO_GETINFO
returns 0 for record.port when the recording port is something other
than 'mic', 'cd', or 'line', and the subsequent AUDIO_SETINFO would
fail on this.
|
|
the mixer layer to the audio layer, differentiate between the
'monitor' class and the 'outputs' class instead of lumping them
together. not all mixers have a monitor class entry which was
causing the outputs class to be ignored.
- look for monitor port in the monitor class, but if the monitor
port is not found in the monitor class look in the outputs class
as well. the code was effectively looking in both the monitor and
outputs classes before, so this is no real change.
sets up audio_info.play.[gain|balance] correctly on at least emu(4),
auich(4), auvia(4) and snapper(4) ... probably most other AC'97 devices
as well. as a result, audioctl(1) works much better and the overall
volume can be set with /dev/audio instead of needing to go through
/dev/mixer.
from deanna@
thanks again to those who tested this change
|
|
to allow buffer sizes and pointer to the buffer to be set to reasonable
values for the sample size of the data to be read/written.
fixes kernel corruption seen with azalia and probably other drivers
that are using something other than 8kHz monaural mulaw as the default
encoding when doing 'dd if=/dev/audio of=foo' as the first audio
operation after boot.
problem reported by deanna@
|
|
and the userland sample size matters.
there may be different sample size factors for play and record,
so use the appropriate factor when userland sets the blocksize.
the reported blocksize, hiwat and lowat are only for the play buffer.
IMO, it would be good to report the record blocksize, hiwat and lowat
as well, but that is another issue.
tested with emu(4) and an auvia(4) modified to only do stereo in
hardware.
|
|
may not be the same sample size as what userland is to receive.
account for the discrepency between the sample sizes when comparing
how much to copy out with what userland expects.
- only copy out the part of the buffer that is in the format userland
expects.
emu(4) can now record with all encodings it claims to be able to.
that is, dd if=/dev/audio of=foo does as audio(4) says (monaural
mu-law) and does it correctly.
AFAIKS, the only other driver that sets a read factor is uaudio(4),
and that depends on what the hardware supports.
tested on i386, amd64 and sgi with 3 different emu(4) cards
|
