Re: Audio control API, part 1: libsndio, sndiod bits
On Mon, Feb 24, 2020 at 09:33:19AM GMT, Alexandre Ratchov wrote: > On Thu, Feb 13, 2020 at 05:15:34AM +, Raf Czlonka wrote: > > On Sun, Feb 09, 2020 at 12:13:02PM GMT, Alexandre Ratchov wrote: > > > +++ lib/libsndio/sioctl_aucat.c 8 Feb 2020 14:49:37 - > > > [...] > > > + * Copyright (c) 2010-2011 Alexandre Ratchov > > > > > > [...] > > > > > > +++ lib/libsndio/sioctl_open.38 Feb 2020 14:49:37 - > > > [...] > > > +.\" Copyright (c) 2011 Alexandre Ratchov > > > > > > [...] > > > > > > +++ lib/libsndio/sioctl_priv.h8 Feb 2020 14:49:38 - > > > [...] > > > + * Copyright (c) 2008 Alexandre Ratchov > > > > > > [...] > > > > > > +++ lib/libsndio/sioctl_sun.c 8 Feb 2020 14:49:38 - > > > [...] > > > + * Copyright (c) 2010-2011 Alexandre Ratchov > > > > > > [...] > > > > > > +++ lib/libsndio/sioctl.c 8 Feb 2020 14:49:37 - > > > [...] > > > + * Copyright (c) 2008 Alexandre Ratchov > > > > > > [...] > > > > > > +++ usr.bin/sndioctl/sndioctl.1 9 Feb 2020 11:05:02 - > > > [...] > > > +.\" Copyright (c) 2007 Alexandre Ratchov > > > > > > [...] > > > > > > +++ usr.bin/sndioctl/sndioctl.c 9 Feb 2020 11:05:02 - > > > [...] > > > + * Copyright (c) 2007-2011 Alexandre Ratchov > > > > > > [...] > > > > > > +++ usr.bin/sndiod/dev_sioctl.c 8 Feb 2020 14:49:38 - > > > [...] > > > + * Copyright (c) 2014 Alexandre Ratchov > > > > > > [...] > > > > > > +++ usr.bin/sndiod/dev_sioctl.h 8 Feb 2020 14:49:38 - > > > [...] > > > + * Copyright (c) 2014 Alexandre Ratchov > > > > > > [...] > > > > > > > Hi Alexandre, > > > > Shouldn't all of these dates be adjusted? > > > > Sure; added 2020 as copyright year. Thanks. Hi Alexandre, AFAIK, range would only be applicable if the files were "changed" (for a lack of a better term) each year between the years stated (inclusive)[0]. After license.template[1]: It is important to specify the year of the copyright. Additional years should be separated by a comma, e.g. Copyright (c) 2003, 2004 Which then *could* change to range should the, consecutive, years formed a long line, i.e.: Copyright (c) 2003-2010 [0] https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html [1] https://cvsweb.openbsd.org/src/share/misc/license.template?rev=HEAD Regards, Raf
Re: Audio control API, part 1: libsndio, sndiod bits
On Thu, Feb 13, 2020 at 05:15:34AM +, Raf Czlonka wrote: > On Sun, Feb 09, 2020 at 12:13:02PM GMT, Alexandre Ratchov wrote: > > +++ lib/libsndio/sioctl_aucat.c 8 Feb 2020 14:49:37 - > > [...] > > + * Copyright (c) 2010-2011 Alexandre Ratchov > > > > [...] > > > > +++ lib/libsndio/sioctl_open.3 8 Feb 2020 14:49:37 - > > [...] > > +.\" Copyright (c) 2011 Alexandre Ratchov > > > > [...] > > > > +++ lib/libsndio/sioctl_priv.h 8 Feb 2020 14:49:38 - > > [...] > > + * Copyright (c) 2008 Alexandre Ratchov > > > > [...] > > > > +++ lib/libsndio/sioctl_sun.c 8 Feb 2020 14:49:38 - > > [...] > > + * Copyright (c) 2010-2011 Alexandre Ratchov > > > > [...] > > > > +++ lib/libsndio/sioctl.c 8 Feb 2020 14:49:37 - > > [...] > > + * Copyright (c) 2008 Alexandre Ratchov > > > > [...] > > > > +++ usr.bin/sndioctl/sndioctl.1 9 Feb 2020 11:05:02 - > > [...] > > +.\" Copyright (c) 2007 Alexandre Ratchov > > > > [...] > > > > +++ usr.bin/sndioctl/sndioctl.c 9 Feb 2020 11:05:02 - > > [...] > > + * Copyright (c) 2007-2011 Alexandre Ratchov > > > > [...] > > > > +++ usr.bin/sndiod/dev_sioctl.c 8 Feb 2020 14:49:38 - > > [...] > > + * Copyright (c) 2014 Alexandre Ratchov > > > > [...] > > > > +++ usr.bin/sndiod/dev_sioctl.h 8 Feb 2020 14:49:38 - > > [...] > > + * Copyright (c) 2014 Alexandre Ratchov > > > > [...] > > > > Hi Alexandre, > > Shouldn't all of these dates be adjusted? > Sure; added 2020 as copyright year. Thanks.
Re: Audio control API, part 1: libsndio, sndiod bits
On Sun, Feb 09, 2020 at 12:13:02PM GMT, Alexandre Ratchov wrote: > +++ lib/libsndio/sioctl_aucat.c 8 Feb 2020 14:49:37 - > [...] > + * Copyright (c) 2010-2011 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl_open.38 Feb 2020 14:49:37 - > [...] > +.\" Copyright (c) 2011 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl_priv.h8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2008 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl_sun.c 8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2010-2011 Alexandre Ratchov > > [...] > > +++ lib/libsndio/sioctl.c 8 Feb 2020 14:49:37 - > [...] > + * Copyright (c) 2008 Alexandre Ratchov > > [...] > > +++ usr.bin/sndioctl/sndioctl.1 9 Feb 2020 11:05:02 - > [...] > +.\" Copyright (c) 2007 Alexandre Ratchov > > [...] > > +++ usr.bin/sndioctl/sndioctl.c 9 Feb 2020 11:05:02 - > [...] > + * Copyright (c) 2007-2011 Alexandre Ratchov > > [...] > > +++ usr.bin/sndiod/dev_sioctl.c 8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2014 Alexandre Ratchov > > [...] > > +++ usr.bin/sndiod/dev_sioctl.h 8 Feb 2020 14:49:38 - > [...] > + * Copyright (c) 2014 Alexandre Ratchov > > [...] > Hi Alexandre, Shouldn't all of these dates be adjusted? Regards, Raf
Re: Audio control API, part 1: libsndio, sndiod bits
On Tue, Feb 11, 2020 at 07:15:00PM GMT, Alexandre Ratchov wrote: > On Tue, Feb 11, 2020 at 07:01:28PM +0100, Florian Obser wrote: > > I've been running the base diffs since you posted them. Firefox, > > chrome and mpv still make noise :) > > > > I'm puzzled by this: > > > > $ cat /etc/mixerctl.conf > > > > outputs.master=255,255 > > record.enable=off > > > > $ mixerctl outputs.master > > > > outputs.master=255,255 > > > > $ sndioctl > > output.level=127 > > > > I don't understand how they relate and why one goes to 255 and the > > other to 127. > > The error reporting is confusing, too: > > > > $ sndioctl output.level=128 > > > > integer overflow > > > > But no regressions to report :) > > > > Thanks, the code is base on MIDI bits, which uses the 0..127 range; > sndiod, aucat and many codecs also use the 0..127 range. Anyway, > replaced the error message by: > > $ sndioctl output.level=128 > 128: expected integer in the 0..127 range > > [...] > > I'm wondering if persents or floating points in the [0:1] range would > be less confusing and solve most "units" problems. > Hi Alexandre, I have to say that I also find the two ranges mildly confusing, i.e. 0-255 in one place, and 0-127 in another. In terms of units, personally, I'm used to, and quite like, the granularity of 0-255. Again, not my place so others will certainly be more help here. One more point regarding the interface, though. This is the way mixerctl(1) currently behaves: $ mixerctl outputs.master outputs.master=255,255 $ mixerctl outputs.master=100 outputs.master: 255,255 -> 100,100 $ mixerctl outputs.master=300 outputs.master: 100,100 -> 255,255 Should sndioctl(1) behave the same way? Cheers, Raf
Re: Audio control API, part 1: libsndio, sndiod bits
On Feb 12 21:38:56, a...@caoua.org wrote: > On Wed, Feb 12, 2020 at 09:22:20PM +0100, Jan Stary wrote: > > Hi, > > > > On Feb 09 13:13:02, a...@caoua.org wrote: > > > cd /usr/src > > > patch -p0 <1.diff > > > patch -p0 <2.diff > > > patch -p0 <3.diff > > > cd /usr/src/include && doas make includes > > > cd /usr/src/lib/libsndio && make obj && make && doas make install > > > cd /usr/src/lib/libossaudio && make obj && make && doas make install > > > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > > > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > > > doas rcctl restart sndiod > > > > > > I'm very interested in any regression. > > > > After restarting sndiod (with empty flags), > > starting sndioctl -m makes sndiod crash with > > > > Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 > > > > That's ioctl(2). I don't see that in any of the three pledge(2) calls > > revealed by a grep in (the patched) .../sndiod/, but apparently > > the new code does call ioctl(). > > sndiod does unauthorized ioctls on this kernel, see below > > > > > Strangely, this happens on > > > > OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 > > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > but not on > > > > OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 > > h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > (Did I miss somethong pledge() related in that window?) > > > > Yes, there was a kernel commit to allow programs with the "audio" > promise (like sndiod) to use the mixer ioctl()s. Indeed, the problem disappears with the current curent. Sorry for the noise. Jan
Re: Audio control API, part 1: libsndio, sndiod bits
On Wed, Feb 12, 2020 at 09:28:38PM +0100, Jan Stary wrote: > Hi, > > On Feb 09 13:13:02, a...@caoua.org wrote: > > cd /usr/src > > patch -p0 <1.diff > > patch -p0 <2.diff > > patch -p0 <3.diff > > cd /usr/src/include && doas make includes > > cd /usr/src/lib/libsndio && make obj && make && doas make install > > cd /usr/src/lib/libossaudio && make obj && make && doas make install > > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > > doas rcctl restart sndiod > > cd /usr/ports > > patch -p0 <4.diff > > cd /usr/ports/audio/gqmpeg && make && make install > > cd /usr/ports/sysutils/tray-app && make && make install > > > > Feedback about the new features > > is of course welcome as well. > > sndioctl -m works fine with e.g. mplayer, > i.e. sndioctl notices the "added" app, > and reports the volume changes. great :) > With ffplay and firefox:youtube, volume changes are not reported. > Is that expected? Do they tweak their "internal" volume knob > but not the volume they register with sndio? As opposed to mplayer? Yes exactly. I haven't checked ffplay, but firefox uses an internal volume control because its internal API has no "getter", this is explained here: https://marc.info/?l=openbsd-ports=152641946326955
Re: Audio control API, part 1: libsndio, sndiod bits
On Wed, Feb 12, 2020 at 09:22:20PM +0100, Jan Stary wrote: > Hi, > > On Feb 09 13:13:02, a...@caoua.org wrote: > > cd /usr/src > > patch -p0 <1.diff > > patch -p0 <2.diff > > patch -p0 <3.diff > > cd /usr/src/include && doas make includes > > cd /usr/src/lib/libsndio && make obj && make && doas make install > > cd /usr/src/lib/libossaudio && make obj && make && doas make install > > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > > doas rcctl restart sndiod > > > > I'm very interested in any regression. > > After restarting sndiod (with empty flags), > starting sndioctl -m makes sndiod crash with > > Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 > > That's ioctl(2). I don't see that in any of the three pledge(2) calls > revealed by a grep in (the patched) .../sndiod/, but apparently > the new code does call ioctl(). sndiod does unauthorized ioctls on this kernel, see below > > Strangely, this happens on > > OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > but not on > > OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 > h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > (Did I miss somethong pledge() related in that window?) > Yes, there was a kernel commit to allow programs with the "audio" promise (like sndiod) to use the mixer ioctl()s.
Re: Audio control API, part 1: libsndio, sndiod bits
Hi, On Feb 09 13:13:02, a...@caoua.org wrote: > cd /usr/src > patch -p0 <1.diff > patch -p0 <2.diff > patch -p0 <3.diff > cd /usr/src/include && doas make includes > cd /usr/src/lib/libsndio && make obj && make && doas make install > cd /usr/src/lib/libossaudio && make obj && make && doas make install > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > doas rcctl restart sndiod > cd /usr/ports > patch -p0 <4.diff > cd /usr/ports/audio/gqmpeg && make && make install > cd /usr/ports/sysutils/tray-app && make && make install > > Feedback about the new features > is of course welcome as well. sndioctl -m works fine with e.g. mplayer, i.e. sndioctl notices the "added" app, and reports the volume changes. With ffplay and firefox:youtube, volume changes are not reported. Is that expected? Do they tweak their "internal" volume knob but not the volume they register with sndio? As opposed to mplayer? At any rate, thanks for the new tool! Jan
Re: Audio control API, part 1: libsndio, sndiod bits
Hi, On Feb 09 13:13:02, a...@caoua.org wrote: > cd /usr/src > patch -p0 <1.diff > patch -p0 <2.diff > patch -p0 <3.diff > cd /usr/src/include && doas make includes > cd /usr/src/lib/libsndio && make obj && make && doas make install > cd /usr/src/lib/libossaudio && make obj && make && doas make install > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > doas rcctl restart sndiod > > I'm very interested in any regression. After restarting sndiod (with empty flags), starting sndioctl -m makes sndiod crash with Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 That's ioctl(2). I don't see that in any of the three pledge(2) calls revealed by a grep in (the patched) .../sndiod/, but apparently the new code does call ioctl(). Strangely, this happens on OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP but not on OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP (Did I miss somethong pledge() related in that window?) Jan
Re: Audio control API, part 1: libsndio, sndiod bits
On Tue, Feb 11, 2020 at 07:01:28PM +0100, Florian Obser wrote: > I've been running the base diffs since you posted them. Firefox, > chrome and mpv still make noise :) > > I'm puzzled by this: > > $ cat /etc/mixerctl.conf > outputs.master=255,255 > record.enable=off > > $ mixerctl outputs.master > outputs.master=255,255 > > $ sndioctl > output.level=127 > > I don't understand how they relate and why one goes to 255 and the > other to 127. > The error reporting is confusing, too: > > $ sndioctl output.level=128 > integer overflow > > But no regressions to report :) > Thanks, the code is base on MIDI bits, which uses the 0..127 range; sndiod, aucat and many codecs also use the 0..127 range. Anyway, replaced the error message by: $ sndioctl output.level=128 128: expected integer in the 0..127 range [...] I'm wondering if persents or floating points in the [0:1] range would be less confusing and solve most "units" problems.
Re: Audio control API, part 1: libsndio, sndiod bits
I've been running the base diffs since you posted them. Firefox, chrome and mpv still make noise :) I'm puzzled by this: $ cat /etc/mixerctl.conf outputs.master=255,255 record.enable=off $ mixerctl outputs.master outputs.master=255,255 $ sndioctl output.level=127 I don't understand how they relate and why one goes to 255 and the other to 127. The error reporting is confusing, too: $ sndioctl output.level=128 integer overflow But no regressions to report :) -- I'm not entirely sure you are real.
Audio control API, part 1: libsndio, sndiod bits
This diff adds an API to control knobs of audio interfaces. It aims to
address these points:
- allow the controls of modern audio hardware and sndiod software
volume knobs in a uniform way. Hardware knobs are exposed by sndiod,
which will be also important from security standpoint: by default
programs using this API won't need to mess with /dev nodes.
- allow multiple programs to use the controls at the same time without
the need to continuously scan the controls.
- the API is multi-channel and allows programs to "clump" controls and
to represent many knobs as a single one. For instance the volume
knob of a "modern" 10-channel azalia(4) could be represented as a
single knob. This requires driver changes, not yet there.
- the API allows controls to be dynamically added or removed. This is
useful to avoid restarting programs when devices are swapped,
ex. when usb head-sets are used.
For now sndiod exposes only its own controls and the master output and
input volume knobs of the underlying hardware (if any). Other controls
don't seem necessary to expose to regular programs; we can keep things
simple and leave the other controls as configuration parameters set
only once, at system startup.
To ease discussions and review, the diff is split in 4 parts. This
diff is the first of 3 base diffs and 1 ports diff (see next
mails). To test the new code, apply all diffs, for instance:
cd /usr/src
patch -p0 <1.diff
patch -p0 <2.diff
patch -p0 <3.diff
cd /usr/src/include && doas make includes
cd /usr/src/lib/libsndio && make obj && make && doas make install
cd /usr/src/lib/libossaudio && make obj && make && doas make install
cd /usr/src/usr.bin/sndiod && make obj && make && doas make install
cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install
doas rcctl restart sndiod
cd /usr/ports
patch -p0 <4.diff
cd /usr/ports/audio/gqmpeg && make && make install
cd /usr/ports/sysutils/tray-app && make && make install
I'm very interested in any regression. Feedback about the new features
is of course welcome as well.
Enjoy,
Index: include/sndio.h
===
RCS file: /cvs/src/include/sndio.h,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 sndio.h
--- include/sndio.h 20 Dec 2015 11:29:29 - 1.9
+++ include/sndio.h 8 Feb 2020 14:49:37 -
@@ -24,12 +24,20 @@
*/
#define SIO_DEVANY "default"
#define MIO_PORTANY"default"
+#define SIOCTL_DEVANY "default"
+
+/*
+ * limits
+ */
+#define SIOCTL_NAMEMAX 12 /* max name length */
+#define SIOCTL_VALMAX 127 /* max control value */
/*
* private ``handle'' structure
*/
struct sio_hdl;
struct mio_hdl;
+struct sioctl_hdl;
/*
* parameters of a full-duplex stream
@@ -85,12 +93,39 @@ struct sio_cap {
#define SIO_XSTRINGS { "ignore", "sync", "error" }
/*
+ * controlled component of the device
+ */
+struct sioctl_node {
+ char name[SIOCTL_NAMEMAX]; /* ex. "spkr" */
+ int unit; /* optional number or -1 */
+};
+
+/*
+ * description of a control (index, value) pair
+ */
+struct sioctl_desc {
+ unsigned int addr; /* control address */
+#define SIOCTL_NONE0 /* deleted */
+#define SIOCTL_NUM 2 /* integer in the 0..127 range */
+#define SIOCTL_SW 3 /* on/off switch (0 or 1) */
+#define SIOCTL_VEC 4 /* number, element of vector */
+#define SIOCTL_LIST5 /* switch, element of a list */
+ unsigned int type; /* one of above */
+ char func[SIOCTL_NAMEMAX]; /* function name, ex. "level" */
+ char group[SIOCTL_NAMEMAX]; /* group this control belongs to */
+ struct sioctl_node node0; /* affected node */
+ struct sioctl_node node1; /* dito for SIOCTL_{VEC,LIST} */
+};
+
+/*
* mode bitmap
*/
#define SIO_PLAY 1
#define SIO_REC2
#define MIO_OUT4
#define MIO_IN 8
+#define SIOCTL_READ0x100
+#define SIOCTL_WRITE 0x200
/*
* default bytes per sample for the given bits per sample
@@ -144,10 +179,24 @@ int mio_pollfd(struct mio_hdl *, struct
int mio_revents(struct mio_hdl *, struct pollfd *);
int mio_eof(struct mio_hdl *);
+struct sioctl_hdl *sioctl_open(const char *, unsigned int, int);
+void sioctl_close(struct sioctl_hdl *);
+int sioctl_ondesc(struct sioctl_hdl *,
+void (*)(void *, struct sioctl_desc *, int), void *);
+int sioctl_onval(struct sioctl_hdl *,
+void (*)(void *, unsigned int, unsigned int), void *);
+int sioctl_setval(struct sioctl_hdl *, unsigned int, unsigned int);
+int sioctl_nfds(struct sioctl_hdl *);
+int sioctl_pollfd(struct sioctl_hdl *, struct pollfd *, int);
+int sioctl_revents(struct sioctl_hdl *, struct pollfd *);
+int sioctl_eof(struct sioctl_hdl *);
+
int mio_rmidi_getfd(const char *, unsigned int, int);
struct mio_hdl *mio_rmidi_fdopen(int,
