John Plocher wrote:
> Garrett D'Amore wrote:
>> 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.
>
>
> What would happen if you inverted this assumption and presumed that
> anything that didn't use the new IOCTLs wanted to glom onto the global
> settings?
Many more applications would break. The problem is that in addition to
things like volume, the global settings also have values for sample,
eof, and error counters. This breaks some important applications like
realplay.
>
> The failure mode there would be less surprising - things would be able
> to change the volume, but would not play well with others...
They might not even work at all. realplayer, for example, would be
totally busted. I think sdtaudio might fail here as well.
>
> I still think it is both feasible and desirable for you to proactively
> fix the gnome and kde desktop audio tools to do the right thing.
>
> If you took these together, would it be enuf to eliminate the hack?
Possibly. The question is how many other desktop environments have
their own audio control apps.
Over time, when we have a better *documented* story about how to safely
use the audio APIs, I would expect things to get better. But the change
won't happen overnight, and the timer doesn't even *start* until we fix
our documentation.... and possibly not until we also deliver a
modernized Sun Ray audio system. (Sun Ray audio is stuck in the 80's
-- it has no notion of mixing or multiple audio streams, despite having
reasonably modern audio *hardware*.)
I don't see how I can start without delivering the hack. I do, however,
see a time when the hack can be removed.
-- Garrett
PS: Yes, the time has come several times when I really wanted to find
out who invented these brain damaged APIs (the audio/mixer and OSS apis)
just so I could punch him in the nose. I still rankle at the ugliness
that could have been easily avoided with just a little foresight about
sensible design and an understanding of the evils of indeterminism in
software design.
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
