On Mon, Feb 10, 2020 at 09:14:57PM GMT, Alexandre Ratchov wrote:
> On Mon, Feb 10, 2020 at 09:59:09AM +0000, 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 "<stream>[channel].<function>" 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
