Darren J Moffat wrote:
> Lets look at this another way, if you do nothing what is the outcome for
> these apps ?
>
They aren't able to control the master volume settings. It turns them
into "doorstops". (They wind up controlling logical channels assigned
to them, but since they don't do any playback or record on their own, it
winds up looking like the volume controls do "nothing".)
> Does the system volume go so high that my ear drums are brust and my
> speakers fried ?
>
No.
> Does some ancient app need to get its volume tweaked independently using
> the control in the app rather than the "desktop mixer" ?
>
Many application expect to be able to control the volume via
/dev/audioctl. Logically, they should be controlling their *own*
volume, and not the volume of all applications on the system. This is
the semantic I've applied, by assuming the controls apply to the logical
channel.
(It goes beyond that -- some applications, realplay in particular, also
assume that they have a "private" copy of the EOF and sample counters
that are managed by AUDIO_GETINFO/SETINFO, and would behave quite badly
if those counters were shared values.)
> I'm lacking context of what happens as far as the end user is concerned
> to help me evaluate the risks of the various approaches.
>
> But I must say that I hate the idea of any interpretation of cli
> arguments being done in kernel and just as bad any interpretation of the
> command name.
>
The process arguments are not interpreted, only passed back out to a
mixer panel application so that the end user who wants to adjust the
volume associated with a specific application can do so from a common
mixer application.
The command name is different -- it is used to trigger different
behavior for applications that need to adjust global values but that
don't use new-style ioctls. Right now the "whitelist" is comprised of
"gnome-volume-control" and "mixer_applet2" (and yes, truncation occurs
and is handled properly), but I wouldn't be surprised if other
applications wind up getting added, especially as we support other
desktop environments. (I'm thinking of KDE, Afterstep, FVWM, etc.
here.) Notably sdtaudiocontrol does *not* need this hack, because I can
identify it because it uses a couple of new ioctls that would only ever
be used by a mixer savvy application. (Specifically AUDIO_GET_NUM_CHS.)
Applications that use AUDIO_MIXER_MULTIPLE_OPEN, AUDIO_MIXER,
AUDIO_GET_CH_NUMBER, AUDIO_GET_CH_TYPE, AUDIO_MIXERCTL_{S,G}ET_CH_INFO,
AUDIO_MIXERCTL_{S,G}_ET_INFO are recognized as being "modernized", and
are assumed that they want hardware global settings when using
AUDIO_{GS}ETINFO on /dev/audioctl. It would be even better if those
applications simply did not use AUDIO_{GS}ETINFO on /dev/audioctl, but
instead used unambiguous ioctls such as AUDIO_MIXERCTL_GET_CHINFO (for
the logical channel) or AUDIO_MIXERCTL_GETINFO (for hardware global
settings).
The AUDIO_GETINFO/SETINFO calls are *always* assumed to apply to a
logical channel when issued against /dev/audio instead of /dev/audioctl.
If I had my way, *no* application would ever use AUDIO_GETINFO/SETINFO
on /dev/audioctl. I feel so strongly about this particular ugliness
that I'll probably be asking to mark that particular usage Obsolete as
part of PSARC 2008/318.
> Sometimes it is better to just break the compatibility.
>
Sometimes yes. But the installed base of applications here is *huge*.
And, to make matters worse, the documentation we have supplied for these
APIs is dismal, and fails to make clear any of the caveats or even
recommendations about correct usage.
Making matters worse, there is an alternate implementation (Sun Ray
audio) that probably doesn't even *support* the new style ioctls. (Sun
Ray audio lacks any kind of mixer functionality. This is a bug we hope
to fix in a future release, once we finish getting the core Solaris work
done first. When we do the Sun Ray audio, it will be a full participant
in the new audio framework rather than a bolt-on on the side.)
-- Garrett
> --
> Darren J Moffat
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
