On Tue, May 19, 2026 at 04:42:57PM +0200, Jonathan Armani wrote:
> Hello Alex,
> 
> Some questions / feedbacks inline but works fine.
> 
> OK
> 
> On Tue, May 12, 2026, at 12:01, Alexandre Ratchov wrote:
> > ping
> >
> > ----- Forwarded message from Alexandre Ratchov <alex@caoua.org> -----
> >
> > Date: Sun, 15 Mar 2026 21:17:43 +0100
> > From: Alexandre Ratchov <alex@caoua.org>
> > To: tech@openbsd.org
> > Subject: sndiod: Add the server.mode control making the server mode dynamic
> >
> > This diff allows the server mode to be changed at run-time with the
> > new server.mode control exposed by sndioctl(1), ex:
> >
> > $ sndioctl server.mode=play,rec,mon
> >
> > Useful to record your screen with voiceover without restarting sndiod
> > twice. The -m option defines its initial value.
> >
> > If the server is switched to play-only mode, then existing clients
> > will start recording silence. Similarly if it's switched to rec-only
> > mode, clients are muted. Connections are never dropped.
> >
> > At sndiod startup, trying to determine the hardware mode based on the
> > -m options doesn't make sense anymore. So -m can no longer be used to
> > force the hardware mode, which is not very useful these days imho.
> 
> Maybe worth a man update ?
> 

Hi,

The way the hardware is open is not detailed in the man page, so the
current text still applies. The -m option remains the "sub-device
mode" even if it is not used to determine the hardware mode anymore.

> > @@ -1473,12 +1458,6 @@ slot_attach(struct slot *s)
> >  	struct dev *d = s->opt->dev;
> >  	long long pos;
> > 
> > -	if (((s->mode & MODE_PLAY) && !(s->opt->mode & MODE_PLAY)) ||
> > -	    ((s->mode & MODE_RECMASK) && !(s->opt->mode & MODE_RECMASK))) {
> > -		logx(1, "slot%zu at %s: mode not allowed", s - slot_array, s->opt->name);
> > -		return;
> > -	}
> > -
> 
> Where does server.mode is constrained to what hardware really support ? Not wanted ?
>

Programs are not constrained anymore, on purpose.

Currently if the hardware can't play (ex. webcam's microphone), we
allow clients to play but throw the data until the user switches to a
capable device (ex. with the server.device control). This diff, simply
extends this logic to the -m option and the server.mode control.

Constraining (i.e. disconnecting) the client if the hardware lacks the
capability would require to disconnect clients when server.device
passes through a non-capable device (or server.mode temporarily
disables one direction). This is unpractical because there's no way
for the user to roll-back (disconnected programs may need to be
restarted after server.device or server.mode change).

> > 
> > +struct opt_mode opt_modes[] = {
> > +	{MODE_PLAY, "play"},
> > +	{MODE_REC, "rec"},
> > +	{MODE_MON, "mon"},
> > +};
> > +
> 
> const ?
> 

yeah, I'll fix that as rsadowski@ noted as well, thanks.

> > @@ -486,19 +488,52 @@ opt_del(struct opt *o)
> >  void
> >  opt_init(struct opt *o)
> >  {
> > +	int i;
> > +
> > +	for (i = 0; i < sizeof(opt_modes) / sizeof(opt_modes[0]); i++) {
> 
> I don't ever remember if we have nitems ;D
> 

AFAIU, ntimes() would require including sys/param.h which we try to
avoid. I guess that's why many programs define their own nitems()
macro?

sndiod has already many instances of "size(x) / sizeof(x[0])", let's
handle them all in once in another diff.