Implement audio input source selection.

from jon at elytron dot openbsd dot amsterdam
feedback and ok miod@

Make audio(9) get_props() optional, remove it from duplex drivers

The property bits of audio(9) are obsolete and ought to be removed
completely.

sys/dev/audio.c:audio_open() currently uses get_prop

Make audio(9) get_props() optional, remove it from duplex drivers

The property bits of audio(9) are obsolete and ought to be removed
completely.

sys/dev/audio.c:audio_open() currently uses get_props() to bail out if
read *and* write was requested on a non-duplex driver.

Drivers that currently support playing but not recording need adjustment
before the API can be cleaned up.

Drivers that advertise themselves as full duplex, i.e. those that always
return AUDIO_PROP_FULLDUPLEX unconditionally in their get_props() currently
always succeed this check.

As this is the only property, losen audio_open()'s DIAGNOSTIC check and only
do the duplex check if the driver provides get_props().

This allows for simple removal of get_props() from full-duplex drivers
without adding any other code or without changing functionality.

This includes all audio drivers under sys/dev/pci/ (maestro(4) being the
only unfinished exception here).

Other drivers as well as the API change can then follow in smaller diffs.

This builds on amd64, arm64, i386, macppc and sparc64.
amd64 with azalia(4) still plays, records as well as plays and records
at the same time on my X230 as tested with

$ aucat -i play.wav [-o rec.wav]

alpha and hppa tests by miod
OK ratchov miod

show more ...

Use C99 struct init for struct audio_hw_if

This audio(9) struct will lose a member, but drivers init their struct quite
inconsistently, most pre-C99 style.

Use C99 style everywhere, to get rid of a

Use C99 struct init for struct audio_hw_if

This audio(9) struct will lose a member, but drivers init their struct quite
inconsistently, most pre-C99 style.

Use C99 style everywhere, to get rid of all annoying differences and allow
for easy member removals/additions:
- don't change current order of members
- no explicit NULL members
- no comments or blank lines
- trailing comma in last member line

GENERIC.MP builds fine with this on arm64, amd64, i386 and sparc64.

macppc and alpha build-tested by miod
OK ratchov miod

show more ...

Constify struct {audio,midi,radio,video}_hw_if. No functional change.

ok mpi@ ratchov@ "More const is good" deraadt@

Constify struct cfattach.

ok miod@

Make room for a cookie argument passed to audio_attach_mi(). Currently
unused but intended to be used to correlate audio and wskbd devices.

ok ratchov@

Remove unused getdev() audio driver functions.

Remove drain(), query_encoding(), mappage() and get_default_params()
methods from all audio drivers and from the audio_if structure as they
are never called.

Do not do strncmp comparisons on dv_xname because longer device names which
look similar could arrive in the future. Instead, compare directly against
dv_cfdata->cf_driver->cd_name
Issue originally

Do not do strncmp comparisons on dv_xname because longer device names which
look similar could arrive in the future. Instead, compare directly against
dv_cfdata->cf_driver->cd_name
Issue originally spotted by miod

show more ...

native default parameters for i2s devices instead of 8kHz
mulaw mono, which few can even do.

"Please just get this in." brad@

allow low level audio drivers to specify a default sample format,
instead of 8-bit mono mulaw @ 8kHz.

this is just the infrastructure; no drivers are specifying a default
yet.

ok ratchov@, deanna@

rename drivers with numbers in them; ok gwk drahn

Fix totally bogus previous commit.

Make sure we match the correct driver for newer macppc systems.
tested by xsa@, ok joris@, brad@

- add a datasheet for daca(4)
- add a datasheet for a very similar chipset to onyx(4); From kettenis@

don't say datasheet yet, but at least mention product info.

add the datasheet URL.

Apple "onyx" audio device driver.