>There's a *very* good reason for it for some programs:  Alerts.

Not good enough. There is no way to ensure that the output will be
heard. So, if the alert is critical, the person may miss it. If its
not critical, why bother?

>Sound almost never benefits a program that you're paying attention to.
>It's when you need reminding that you are NOT paying attention to it that
>sound is a winner.

Unless your audio setup means that you don't hear it anyway.

Hint: no existing method of delivering audio in a "desktop" system
will ensure that it will be heard. there are many reasons why
this may be so. Here are a few:

     * the audio interface may be busy and may not support multi-open
     * the audio interface may have a mixer and the relevant channel(s)
            may be "turned off"
     * the audio interface may be a soundserver that routes audio
            over the network, and such routing may be disabled
     * the audio interface may be in use by another program whose
            output obscures or hides the alert signal	    
     * there may be more than one audio interface installed, and only
            one of them has a "permanent" connection to any
	    kind of output device (this is true in my system, for example)
	    How can the program know which one?

If there's an important reason for sending the sound, it doesn't seem
good enough to say "oh, we did our best to get it to the user, we
can't do anymore".

If alerts are desired, the program should signal this in some other
way, and have a daemon running to ensure that alerts are sent to the
user one way or another. audio may not be the right way, or it
might. this sounds like a desktop project, which means - excuse me, i
have better things to do :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]