Re: Audio control API, part 2: add new sndioctl(1) utility
On Mon, Feb 10, 2020 at 09:14:57PM GMT, Alexandre Ratchov wrote:
> On Mon, Feb 10, 2020 at 09:59:09AM +, Raf Czlonka wrote:
> > On Sun, Feb 09, 2020 at 12:14:47PM GMT, Alexandre Ratchov wrote:
> > > Here's a new sndioctl utility similar to mixerctl(1) but using the new
> > > sndio API. Example:
> > >
> > > $ sndioctl
> > > output.level=127
> > > app/aucat0.level=127
> > > app/firefox0.level=127
> > > app/firefox1.level=12
> > > app/midisyn0.level=127
> > > app/mpv0.level=127
> > > app/prog5.level=127
> > > app/prog6.level=127
> > > app/prog7.level=127
> > > hw/input.level=62
> > > hw/input.mute=0
> > > hw/output.level=63
> > > hw/output.mute=0
> > >
> >
> > Hi Alexandre,
> >
> > Just a quick question.
> >
> > Is there a good reason to have the above using "slash" ('/') as the
> > first separator instead of the, more familiar, "dot" ('.') known
> > from sysctl(8)'s MIB (Management Information Base) style names or
> > even the "pseudo" MIB know from mixerctl(1)?
>
> Hi,
>
> I don't know if the following qualifies as a "good reason". The first
> part (the group) is a prefix of the control identifier. The identifier
> itself has a strict "[channel]." format. The prefix
> is not always present, examples:
>
> output.level<- sndiod volume knob
> hw/output.level <- underlying hardware volume knob
>
> I tried to avoid the group part, but as mixers may be nested it seems
> necessary to avoid name clashes.
>
> In the sndioctl syntax, we could replace '/' by '.' but this looks
> confusing as the syntax doesn't map directly to the underlying
> model. But maybe we should hide such developer-centric details and
> just use only dots to make this look as a MIB.
>
> Another option I've considered is to drop the group concept in the API
> and simply prefix the stream name to make it unique; in turn we obtain
> a flat control list. It's uglier and seems to complicate GUIs
> task. For instance the group part could be used to represent controls
> of different groups in different sections or to filter-out certain
> groups).
Hi Alexandre,
I honestly can't tell which one of these would be "better" - best
if others chime in.
I was thinking only from a "uniform" interface angle, i.e. if (some
of) these are to be set from the command line, and its similarity
to MIB-like mixerctl(1) variables, I suspect it might cause some
"muscle memory"-related issues ;^)
If no one else shares it, then I rest my case.
Either way, thanks for the explanation.
Regards,
Raf
Re: Audio control API, part 2: add new sndioctl(1) utility
On Mon, Feb 10, 2020 at 09:59:09AM +, Raf Czlonka wrote:
> On Sun, Feb 09, 2020 at 12:14:47PM GMT, Alexandre Ratchov wrote:
> > Here's a new sndioctl utility similar to mixerctl(1) but using the new
> > sndio API. Example:
> >
> > $ sndioctl
> > output.level=127
> > app/aucat0.level=127
> > app/firefox0.level=127
> > app/firefox1.level=12
> > app/midisyn0.level=127
> > app/mpv0.level=127
> > app/prog5.level=127
> > app/prog6.level=127
> > app/prog7.level=127
> > hw/input.level=62
> > hw/input.mute=0
> > hw/output.level=63
> > hw/output.mute=0
> >
>
> Hi Alexandre,
>
> Just a quick question.
>
> Is there a good reason to have the above using "slash" ('/') as the
> first separator instead of the, more familiar, "dot" ('.') known
> from sysctl(8)'s MIB (Management Information Base) style names or
> even the "pseudo" MIB know from mixerctl(1)?
Hi,
I don't know if the following qualifies as a "good reason". The first
part (the group) is a prefix of the control identifier. The identifier
itself has a strict "[channel]." format. The prefix
is not always present, examples:
output.level<- sndiod volume knob
hw/output.level <- underlying hardware volume knob
I tried to avoid the group part, but as mixers may be nested it seems
necessary to avoid name clashes.
In the sndioctl syntax, we could replace '/' by '.' but this looks
confusing as the syntax doesn't map directly to the underlying
model. But maybe we should hide such developer-centric details and
just use only dots to make this look as a MIB.
Another option I've considered is to drop the group concept in the API
and simply prefix the stream name to make it unique; in turn we obtain
a flat control list. It's uglier and seems to complicate GUIs
task. For instance the group part could be used to represent controls
of different groups in different sections or to filter-out certain
groups).
Re: Audio control API, part 2: add new sndioctl(1) utility
On Sun, Feb 09, 2020 at 12:14:47PM GMT, Alexandre Ratchov wrote:
> Here's a new sndioctl utility similar to mixerctl(1) but using the new
> sndio API. Example:
>
> $ sndioctl
> output.level=127
> app/aucat0.level=127
> app/firefox0.level=127
> app/firefox1.level=12
> app/midisyn0.level=127
> app/mpv0.level=127
> app/prog5.level=127
> app/prog6.level=127
> app/prog7.level=127
> hw/input.level=62
> hw/input.mute=0
> hw/output.level=63
> hw/output.mute=0
>
Hi Alexandre,
Just a quick question.
Is there a good reason to have the above using "slash" ('/') as the
first separator instead of the, more familiar, "dot" ('.') known
from sysctl(8)'s MIB (Management Information Base) style names or
even the "pseudo" MIB know from mixerctl(1)?
Regards,
Raf
> Configuration parameters that are not exposed by sndiod will be
> handled by audioctl(1), including the /etc/mixerctl.conf file at
> system startup.
>
> Originally the program was designed to handle modern many-channel
> devices by presenting many-channel knobs on a single line; this
> feature isn't used yet as the corresponding kernel bits are missing.
>
> Index: usr.bin/Makefile
> ===
> RCS file: /cvs/src/usr.bin/Makefile,v
> retrieving revision 1.161
> diff -u -p -u -p -r1.161 Makefile
> --- usr.bin/Makefile 9 Aug 2019 06:18:25 - 1.161
> +++ usr.bin/Makefile 9 Feb 2020 11:05:02 -
> @@ -22,7 +22,7 @@ SUBDIR= apply arch at aucat audioctl awk
> pr printenv printf quota radioctl rcs rdist rdistd \
> readlink renice rev rpcgen rpcinfo rs rsync rup rusers rwall \
> sdiff script sed sendbug shar showmount signify skey \
> - skeyaudit skeyinfo skeyinit sndiod snmp \
> + skeyaudit skeyinfo skeyinit sndioctl sndiod snmp \
> sort spell split ssh stat su systat \
> tail talk tcpbench tee telnet tftp tic time \
> tmux top touch tput tr true tset tsort tty usbhidaction usbhidctl \
> Index: usr.bin/sndioctl/Makefile
> ===
> RCS file: usr.bin/sndioctl/Makefile
> diff -N usr.bin/sndioctl/Makefile
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ usr.bin/sndioctl/Makefile 9 Feb 2020 11:05:02 -
> @@ -0,0 +1,5 @@
> +#$OpenBSD$
> +
> +PROG=sndioctl
> +LDADD+= -lsndio
> +.include
> Index: usr.bin/sndioctl/sndioctl.1
> ===
> RCS file: usr.bin/sndioctl/sndioctl.1
> diff -N usr.bin/sndioctl/sndioctl.1
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ usr.bin/sndioctl/sndioctl.1 9 Feb 2020 11:05:02 -
> @@ -0,0 +1,148 @@
> +.\" $OpenBSD$
> +.\"
> +.\" Copyright (c) 2007 Alexandre Ratchov
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +.\"
> +.Dd $Mdocdate: April 8 2011 $
> +.Dt SNDIOCTL 1
> +.Os
> +.Sh NAME
> +.Nm sndioctl
> +.Nd control audio parameters
> +.Sh SYNOPSIS
> +.Nm
> +.Bk -words
> +.Op Fl iv
> +.Op Fl f Ar device
> +.Op Ar command ...
> +.Ek
> +.Nm
> +.Bk -words
> +.Fl d
> +.Ek
> +.Sh DESCRIPTION
> +The
> +.Nm
> +utility can display or change parameters of
> +.Xr sndio 7
> +audio devices.
> +The options are as follows:
> +.Bl -tag -width Ds
> +.It Fl d
> +Dump the raw list of available parameters and exit.
> +Useful as a debug tool.
> +.It Fl f Ar device
> +Use this
> +.Xr sndio 7
> +audio device.
> +.It Fl m
> +Monitor and display audio parameters changes.
> +.It Fl i
> +Display characteristics of requested parameters
> +instead of their values.
> +.It Fl v
> +Enable verbose mode, a.k.a. multi-channel mode.
> +By default parameters affecting different channels
> +of the same stream are disguised as a single mono
> +parameter to hide details that are not essential.
> +.El
> +.Pp
> +If no commands are specified all valid parameters are displayed on
> +.Em stdout .
> +Unless
> +.Fl d ,
> +.Fl m ,
> +or
> +.Fl i
> +are used, displayed parameters are valid commands.
> +The set of available controls depends on the control device.
> +.Pp
> +Commands use the following two formats to display and set
> +parameters respectively:
> +.Pp
> +.Dl group/stream[channel].function
> +.Dl group/stream[channel].function=value
> +.Pp
> +On the
Re: Audio control API, part 2: add new sndioctl(1) utility
On Sun, Feb 09, 2020 at 07:20:15PM +0100, Landry Breuil wrote: > On Sun, Feb 09, 2020 at 01:14:47PM +0100, Alexandre Ratchov wrote: > > Here's a new sndioctl utility similar to mixerctl(1) but using the new > > sndio API. Example: > > > > $ sndioctl > > output.level=127 > > app/aucat0.level=127 > > app/firefox0.level=127 > > app/firefox1.level=12 > > app/midisyn0.level=127 > > app/mpv0.level=127 > > app/prog5.level=127 > > app/prog6.level=127 > > app/prog7.level=127 > > hw/input.level=62 > > hw/input.mute=0 > > hw/output.level=63 > > hw/output.mute=0 > > i suppose that replaces audio/aucatctl port ? Yes. But aucatctl will continue to work, it's based on the MIDI interface that will stay for now. The advantage of sndioctl is that it exposes selected hardware controls, while aucatctl exposes sndiod internal knobs only. > audio/cmixer relies on the > latter but i'll have no issue migrating to it if sndioctl gets added. > The -m option might be useful to cmixer to get updates of the knobs state without the need to restart sndioctl periodically.
Re: Audio control API, part 2: add new sndioctl(1) utility
On Sun, Feb 09, 2020 at 01:14:47PM +0100, Alexandre Ratchov wrote: > Here's a new sndioctl utility similar to mixerctl(1) but using the new > sndio API. Example: > > $ sndioctl > output.level=127 > app/aucat0.level=127 > app/firefox0.level=127 > app/firefox1.level=12 > app/midisyn0.level=127 > app/mpv0.level=127 > app/prog5.level=127 > app/prog6.level=127 > app/prog7.level=127 > hw/input.level=62 > hw/input.mute=0 > hw/output.level=63 > hw/output.mute=0 i suppose that replaces audio/aucatctl port ? audio/cmixer relies on the latter but i'll have no issue migrating to it if sndioctl gets added.
Audio control API, part 2: add new sndioctl(1) utility
Here's a new sndioctl utility similar to mixerctl(1) but using the new sndio API. Example: $ sndioctl output.level=127 app/aucat0.level=127 app/firefox0.level=127 app/firefox1.level=12 app/midisyn0.level=127 app/mpv0.level=127 app/prog5.level=127 app/prog6.level=127 app/prog7.level=127 hw/input.level=62 hw/input.mute=0 hw/output.level=63 hw/output.mute=0 Configuration parameters that are not exposed by sndiod will be handled by audioctl(1), including the /etc/mixerctl.conf file at system startup. Originally the program was designed to handle modern many-channel devices by presenting many-channel knobs on a single line; this feature isn't used yet as the corresponding kernel bits are missing. Index: usr.bin/Makefile === RCS file: /cvs/src/usr.bin/Makefile,v retrieving revision 1.161 diff -u -p -u -p -r1.161 Makefile --- usr.bin/Makefile9 Aug 2019 06:18:25 - 1.161 +++ usr.bin/Makefile9 Feb 2020 11:05:02 - @@ -22,7 +22,7 @@ SUBDIR= apply arch at aucat audioctl awk pr printenv printf quota radioctl rcs rdist rdistd \ readlink renice rev rpcgen rpcinfo rs rsync rup rusers rwall \ sdiff script sed sendbug shar showmount signify skey \ - skeyaudit skeyinfo skeyinit sndiod snmp \ + skeyaudit skeyinfo skeyinit sndioctl sndiod snmp \ sort spell split ssh stat su systat \ tail talk tcpbench tee telnet tftp tic time \ tmux top touch tput tr true tset tsort tty usbhidaction usbhidctl \ Index: usr.bin/sndioctl/Makefile === RCS file: usr.bin/sndioctl/Makefile diff -N usr.bin/sndioctl/Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ usr.bin/sndioctl/Makefile 9 Feb 2020 11:05:02 - @@ -0,0 +1,5 @@ +# $OpenBSD$ + +PROG= sndioctl +LDADD+=-lsndio +.include Index: usr.bin/sndioctl/sndioctl.1 === RCS file: usr.bin/sndioctl/sndioctl.1 diff -N usr.bin/sndioctl/sndioctl.1 --- /dev/null 1 Jan 1970 00:00:00 - +++ usr.bin/sndioctl/sndioctl.1 9 Feb 2020 11:05:02 - @@ -0,0 +1,148 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2007 Alexandre Ratchov +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate: April 8 2011 $ +.Dt SNDIOCTL 1 +.Os +.Sh NAME +.Nm sndioctl +.Nd control audio parameters +.Sh SYNOPSIS +.Nm +.Bk -words +.Op Fl iv +.Op Fl f Ar device +.Op Ar command ... +.Ek +.Nm +.Bk -words +.Fl d +.Ek +.Sh DESCRIPTION +The +.Nm +utility can display or change parameters of +.Xr sndio 7 +audio devices. +The options are as follows: +.Bl -tag -width Ds +.It Fl d +Dump the raw list of available parameters and exit. +Useful as a debug tool. +.It Fl f Ar device +Use this +.Xr sndio 7 +audio device. +.It Fl m +Monitor and display audio parameters changes. +.It Fl i +Display characteristics of requested parameters +instead of their values. +.It Fl v +Enable verbose mode, a.k.a. multi-channel mode. +By default parameters affecting different channels +of the same stream are disguised as a single mono +parameter to hide details that are not essential. +.El +.Pp +If no commands are specified all valid parameters are displayed on +.Em stdout . +Unless +.Fl d , +.Fl m , +or +.Fl i +are used, displayed parameters are valid commands. +The set of available controls depends on the control device. +.Pp +Commands use the following two formats to display and set +parameters respectively: +.Pp +.Dl group/stream[channel].function +.Dl group/stream[channel].function=value +.Pp +On the left-hand side are specified the optional parameter group, +the affected stream name, and the optional channel number. +Examples of left-hand side terms: +.Pp +.Dl output.level +.Dl hw/spkr[6].mute +.Pp +There are 4 parameter types: switches, numbers, selectors, and vectors. +.Pp +Numbers are specified in decimal and follow the same semantics +as MIDI controllers. +Values are in the 0..127 range and 64 is the neutral state (if applicable). +Two-state controls (switches) take either 0 or 1 as value, +typically corresponding to the +.Em off +and +.Em on +states respectively. +.Pp +If a decimal is prefixed by the plus
