| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
ok jakemsr@, who promises to deal with any fallout, because he's a stand-up guy
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
|
| |
instead of 8-bit mono mulaw @ 8kHz.
this is just the infrastructure; no drivers are specifying a default
yet.
ok ratchov@, deanna@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- the endianness of the conversions don't depend on the endianness
of machine the conversions are built on, but the endianness of the
audio data itself. choose encoding conversions explicitly, instead
of relying on #defines based on the endianness of the machine.
- replace home-grown conversions with comparable conversions in
auconv.c and mulaw.c
- use the proper conversion for ulinear_be:16 -> slinear_le:16 in
auixp(4)
thanks ajacoutot@ and sthen@ for !x86 testing
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
will ease porting, and generally cleans up a bit
|
| |
|
|
| |
as the mmap offset.
|
| | |
|
| | |
|
| | |
|
|
|
otherwise OK (mixerctl works quite OK, very strange).
At the moment it is polled only, but it works quite OK that way too.
|
jakemsr
blambert
miod
mickey
ho
millert
ericj
art
deraadt
kstailey
niklas