Add sio_flush(3) function to stop playback immediately

The new sio_flush(3) functions works the same way as sio_stop(3),
except that it doesn't wait for play buffer to be drained. Instead,
it discards its contents and returns immediately.

Allow switching between alternate devices (-F option) with sndioctl(1)

Add a new SIOCTL_SEL control type to select one of a predefined set of
mutually exclusive values. It's the same as SIOCTL_LIST except that
exactly one list element may be selected.

Fix comments about sioctl_desc's maxval field

Add API to control audio device parameters exposed by sndiod.

The API exposes controls of modern audio hardware and sndiod software
volume knobs in a uniform way. Hardware knobs are exposed through
sndiod. Multiple programs may use the controls at the same time
without the need to continuously scan the controls.

For now sndiod exposes only its own controls and the master output and
input volumes of the underlying hardware (if any), i.e. those
typically exposed by acpi volume keys.

ok deraadt

Expose internal functions necessary to open audio devices and midi
ports using existing file descriptors.

hex constants unsigned, prevents some gcc warnings
okay ratchov@

Include sys/types.h rather than sys/param.h to pull BYTE_ORDER macros.
suggested by deraadt@

Make the "default" string a valid device name that has the same effect
as NULL has. This will (hopefully) simplify ports where the user
passes the device string.

Use "unsigned int" rather than "unsigned". No object change.
suggested by deraadt@

make sio_onvol(3) return a integer exposing whether a volume knob
is available for the stream. As we're at it, remove macros and
functions that are neither used nor documented.

use const qualifier in libsndio, making it slightly more consistent
with open(2) and write(2) syscalls.
from Thomas Pfaff, jakemsr is fine with it

Currently midi capable programs can control midi hardware, but
cannot cooperate with other programs. The aim of this change is
to allow any program to send midi data to other programs as they
were midi hardware. For instance, this change should solve the
longstanding problem of using a midi sequencer with software
synthesizers. More precisely:

- new midicat(1) utility (actually hardlink to aucat(1)).
it creates software midi thru boxes, allowing programs
to send midi messages to other programs as they were
midi(4) hardware.

- new midi api in libsndio (see mio_open(3)), to access
midi(4) devices and midicat(1) sockets in a uniform way.

- new device naming scheme <service>:<unit>[.<option>],
common to audio and midi.

- new sndio(7) manual describing concepts and naming

The current audio device naming still works, but people having
scripts or configuration files containing device names could read
the sndio(7) man page and slowly start updating device names.

discussed with jakemsr@ and deraadt@, help form jmc@

move src/lib/libsndio/sndio.h into src/include where other include
files leave.

requested by deraadt@, ok miod@

Allow switching between alternate devices (-F option) with sndioctl(1)

Add a new SIOCTL_SEL control type to select one of a predefined set of
mutually exclusive values. It's the same as SIOCTL_LIST except that
exactly one list element may be selected.

Fix comments about sioctl_desc's maxval field

Add API to control audio device parameters exposed by sndiod.

The API exposes controls of modern audio hardware and sndiod software
volume knobs in a uniform way. Hardware knobs are exposed through
sndiod. Multiple programs may use the controls at the same time
without the need to continuously scan the controls.

For now sndiod exposes only its own controls and the master output and
input volumes of the underlying hardware (if any), i.e. those
typically exposed by acpi volume keys.

ok deraadt

Expose internal functions necessary to open audio devices and midi
ports using existing file descriptors.

hex constants unsigned, prevents some gcc warnings
okay ratchov@

Include sys/types.h rather than sys/param.h to pull BYTE_ORDER macros.
suggested by deraadt@

Make the "default" string a valid device name that has the same effect
as NULL has. This will (hopefully) simplify ports where the user
passes the device string.

Use "unsigned int" rather than "unsigned". No object change.
suggested by deraadt@

make sio_onvol(3) return a integer exposing whether a volume knob
is available for the stream. As we're at it, remove macros and
functions that are neither used nor documented.

use const qualifier in libsndio, making it slightly more consistent
with open(2) and write(2) syscalls.
from Thomas Pfaff, jakemsr is fine with it

Currently midi capable programs can control midi hardware, but
cannot cooperate with other programs. The aim of this change is
to allow any program to send midi data to other programs as they
were midi hardware. For instance, this change should solve the
longstanding problem of using a midi sequencer with software
synthesizers. More precisely:

- new midicat(1) utility (actually hardlink to aucat(1)).
it creates software midi thru boxes, allowing programs
to send midi messages to other programs as they were
midi(4) hardware.

- new midi api in libsndio (see mio_open(3)), to access
midi(4) devices and midicat(1) sockets in a uniform way.

- new device naming scheme <service>:<unit>[.<option>],
common to audio and midi.

- new sndio(7) manual describing concepts and naming

The current audio device naming still works, but people having
scripts or configuration files containing device names could read
the sndio(7) man page and slowly start updating device names.

discussed with jakemsr@ and deraadt@, help form jmc@

move src/lib/libsndio/sndio.h into src/include where other include
files leave.

requested by deraadt@, ok miod@

Fix comments about sioctl_desc's maxval field

Add API to control audio device parameters exposed by sndiod.

The API exposes controls of modern audio hardware and sndiod software
volume knobs in a uniform way. Hardware knobs are exposed through
sndiod. Multiple programs may use the controls at the same time
without the need to continuously scan the controls.

For now sndiod exposes only its own controls and the master output and
input volumes of the underlying hardware (if any), i.e. those
typically exposed by acpi volume keys.

ok deraadt

Expose internal functions necessary to open audio devices and midi
ports using existing file descriptors.

hex constants unsigned, prevents some gcc warnings
okay ratchov@

Include sys/types.h rather than sys/param.h to pull BYTE_ORDER macros.
suggested by deraadt@

Make the "default" string a valid device name that has the same effect
as NULL has. This will (hopefully) simplify ports where the user
passes the device string.

Use "unsigned int" rather than "unsigned". No object change.
suggested by deraadt@

make sio_onvol(3) return a integer exposing whether a volume knob
is available for the stream. As we're at it, remove macros and
functions that are neither used nor documented.

use const qualifier in libsndio, making it slightly more consistent
with open(2) and write(2) syscalls.
from Thomas Pfaff, jakemsr is fine with it

Currently midi capable programs can control midi hardware, but
cannot cooperate with other programs. The aim of this change is
to allow any program to send midi data to other programs as they
were midi hardware. For instance, this change should solve the
longstanding problem of using a midi sequencer with software
synthesizers. More precisely:

- new midicat(1) utility (actually hardlink to aucat(1)).
it creates software midi thru boxes, allowing programs
to send midi messages to other programs as they were
midi(4) hardware.

- new midi api in libsndio (see mio_open(3)), to access
midi(4) devices and midicat(1) sockets in a uniform way.

- new device naming scheme <service>:<unit>[.<option>],
common to audio and midi.

- new sndio(7) manual describing concepts and naming

The current audio device naming still works, but people having
scripts or configuration files containing device names could read
the sndio(7) man page and slowly start updating device names.

discussed with jakemsr@ and deraadt@, help form jmc@

move src/lib/libsndio/sndio.h into src/include where other include
files leave.

requested by deraadt@, ok miod@

Add API to control audio device parameters exposed by sndiod.

The API exposes controls of modern audio hardware and sndiod software
volume knobs in a uniform way. Hardware knobs are exposed through
sndiod. Multiple programs may use the controls at the same time
without the need to continuously scan the controls.

For now sndiod exposes only its own controls and the master output and
input volumes of the underlying hardware (if any), i.e. those
typically exposed by acpi volume keys.

ok deraadt

Expose internal functions necessary to open audio devices and midi
ports using existing file descriptors.

hex constants unsigned, prevents some gcc warnings
okay ratchov@

Include sys/types.h rather than sys/param.h to pull BYTE_ORDER macros.
suggested by deraadt@

Make the "default" string a valid device name that has the same effect
as NULL has. This will (hopefully) simplify ports where the user
passes the device string.

Use "unsigned int" rather than "unsigned". No object change.
suggested by deraadt@

make sio_onvol(3) return a integer exposing whether a volume knob
is available for the stream. As we're at it, remove macros and
functions that are neither used nor documented.

use const qualifier in libsndio, making it slightly more consistent
with open(2) and write(2) syscalls.
from Thomas Pfaff, jakemsr is fine with it

Currently midi capable programs can control midi hardware, but
cannot cooperate with other programs. The aim of this change is
to allow any program to send midi data to other programs as they
were midi hardware. For instance, this change should solve the
longstanding problem of using a midi sequencer with software
synthesizers. More precisely:

- new midicat(1) utility (actually hardlink to aucat(1)).
it creates software midi thru boxes, allowing programs
to send midi messages to other programs as they were
midi(4) hardware.

- new midi api in libsndio (see mio_open(3)), to access
midi(4) devices and midicat(1) sockets in a uniform way.

- new device naming scheme <service>:<unit>[.<option>],
common to audio and midi.

- new sndio(7) manual describing concepts and naming

The current audio device naming still works, but people having
scripts or configuration files containing device names could read
the sndio(7) man page and slowly start updating device names.

discussed with jakemsr@ and deraadt@, help form jmc@

move src/lib/libsndio/sndio.h into src/include where other include
files leave.

requested by deraadt@, ok miod@

Expose internal functions necessary to open audio devices and midi
ports using existing file descriptors.

hex constants unsigned, prevents some gcc warnings
okay ratchov@

Include sys/types.h rather than sys/param.h to pull BYTE_ORDER macros.
suggested by deraadt@

Make the "default" string a valid device name that has the same effect
as NULL has. This will (hopefully) simplify ports where the user
passes the device string.

Use "unsigned int" rather than "unsigned". No object change.
suggested by deraadt@

make sio_onvol(3) return a integer exposing whether a volume knob
is available for the stream. As we're at it, remove macros and
functions that are neither used nor documented.

use const qualifier in libsndio, making it slightly more consistent
with open(2) and write(2) syscalls.
from Thomas Pfaff, jakemsr is fine with it

Currently midi capable programs can control midi hardware, but
cannot cooperate with other programs. The aim of this change is
to allow any program to send midi data to other programs as they
were midi hardware. For instance, this change should solve the
longstanding problem of using a midi sequencer with software
synthesizers. More precisely:

- new midicat(1) utility (actually hardlink to aucat(1)).
it creates software midi thru boxes, allowing programs
to send midi messages to other programs as they were
midi(4) hardware.

- new midi api in libsndio (see mio_open(3)), to access
midi(4) devices and midicat(1) sockets in a uniform way.

- new device naming scheme <service>:<unit>[.<option>],
common to audio and midi.

- new sndio(7) manual describing concepts and naming

The current audio device naming still works, but people having
scripts or configuration files containing device names could read
the sndio(7) man page and slowly start updating device names.

discussed with jakemsr@ and deraadt@, help form jmc@

move src/lib/libsndio/sndio.h into src/include where other include
files leave.

requested by deraadt@, ok miod@