| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
- remove argument names from function prototypes
OK jasper@, ray@, "Didn't notice any errors" marc@
|
|
data is expanded before it goes in the buffer. all sizes
and offsets used internally are of this expanded data.
there's no need to compensate for this fact except when
showing information to the user in case their actions
depend on how many bytes are in the buffer.
|
|
try to go past the end of the buffer.
this and the last commit allow ffplay and gnash to work properly
on devices that may need to do mono to stereo conversion, like
auich(4).
problem reported by and much debugging deanna@
|
|
by taking into account expansion we may have done in cases such as
playing monoaural media on a device that only plays stereo, like
auich(4).
|
|
read-write and it supports full-duplex operation.
- update documentation to match this behaviour.
see http://marc.info/?l=openbsd-tech&m=118310788926431&w=2 for
more background on this change
"patches look correct to me" marc@
|
|
buffer, not the record buffer.
inspired by recent similar change in NetBSD.
"patches look correct to me" marc@
|
|
originally from Alexandre Ratchov
"patches look correct to me" marco@
|
|
attribute to '0'. this function may be called when executing an
AUDIO_SETINFO ioctl where the pause attribute was set to '1', and
setting it to '0' in this function will cause unexpected bahaviour.
- according to audio(4), the AUDIO_FLUSH ioctl "restarts recording
and playback". therefor, it should set the pause attributes to '0'.
this was previously accomplished indirectly, because it calls
audio_init_ringbuffer(), which was setting pause to '0'.
- the pause attribute must be set to '0' in audio_open() so that
recording and playback buffers can be "activated" when the device
is opened. this was apparently forgotten when audiosetinfo()
was split off of audio_open() and the logic in audiosetinfo()
was changed to accomodate being run at times other than open().
also, this only really affects read() with poll(), which may
explain why the problem was not noticed for some time.
originally part of a patch Alexandre Ratchov sent to tech@ a
while back
fixes PR 3813
"patches look correct to me" marco@
|
|
For instance, it may not set POLLIN when samples become available,
or may set POLLOUT when write(2) will block.
Fix this by making conditions used by poll (FILTREAD and FILTWRITE
macros) match the blocking conditions in audio_read() and audio_write().
originally from Alexandre Ratchov, with a small tweak by me.
"patches look correct to me" marco@
|
|
so remove the option too. if you have audio and wskbd, you have hotkeys.
ok dlg
|
|
|
|
rather than NWSKBD being nonzero.
|
|
from alexandre ratchov. ok claudio
|
|
something, then it MUST return zero on DVACT_ACTIVATE, not EOPNOTSUPP;
this very popular bug has been cut and pasted a lot of times...
ok deraadt@ mickey@
|
