One big concern with our sound frameworks in general is how mixing and multiple/concurrent sound requests are handled. These are of special interest to accessibility, so any move to revise/revamp the gnome sound interfaces needs to consider that issue and ensure that, at least for the maximum reasonable subset of hardware, concurrent sound is possible. Furthermore, some way of _preventing_ concurrent sounds (i.e. a policy that queues them sequentially instead) probably is necessary in order to support text-to-speech users. Another key characteristic and question is how such support will coexist with console applications/sessions which make use of sound, since many screen reader users also use console-mode text-to-speech systems when doing command-line and virtual terminal work.
I don't know the answers to these questions, or even know to what degree they can be addressed in gstreamer, but I do know that the answers are very important to some users. This is currently an area of active discussion which is slated to lead to standardization activity in the Free Standards Group in the future. Can those "in the know" clarify the relationship between the esd-compatibility wrappers, gstreamer, and the use cases/requirements I mention above with regard to software or hardware mixing and concurrent/sequential sound? Thanks in advance, Bill _______________________________________________ gnome-multimedia mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-multimedia
