Hi all, @richard: A SoC project? why not, but there should be an agreement before someone /waste/ time. Tango for sound? BANGO! (http://freedesktop.org/wiki/Bango)
@rodney: I used your spec. It would be great to put it for real on fdo, with the xml (ala http://standards.freedesktop.org/icon-theme-spec/). @gustavo: there is a flash support for PulseAudio ( http://pulseaudio.revolutionlinux.com/PulseAudio) @etienne: well, true, I have been kidnapped in the country of trolls, Santa Claus, 1000 lakes (and bad-food said our actual president, especially coffee)... how lucky I am! The sound API proposal I made is http://etudiant.epita.fr/~lureau_m/ds-0.1/<http://etudiant.epita.fr/%7Elureau_m/ds-0.1/>. But this is ongoing work, the basic idea is that such API would offer everything you need for sound except audio streaming. That means, instead of dealing with streams, you only deal with sound objects. That is much easier to understand and to deal with for most of us. Of course, the simple use case of this API is ds_play ("bling"), and it will support theming. It is very clear to me that at this point, we are not discussing the implementation (whether the call is made to a server with dbus, or if the sound is played in-process with dmix and some audiolib, or using PulseAudio private protocol...). But I think it is important to provide a compatible D-Bus API at the same time (I did it), thus its easy to have a service on top of the actual implementation. And it helps to define the interfaces. Lennart P., Jean-Marc V. and Mikko L. did some preliminary work on a simple audio/PCM streaming API for the desktop, libsydney (see http://0pointer.de/blog/projects/foms-lca-recap.html). Lennart would like to provide a much simpler sound API with libsydney. That could be, of course, the final consensus. I have my own POV about libsydney, and I hope to meet some of you in Berlin at the end of the week to discuss it (http://www.kgw.tu-berlin.de/~lac2007/index.shtml<http://www.kgw.tu-berlin.de/%7Elac2007/index.shtml>). I really hope that you can make it Lennart. Ok now start the flame: everyone think these works are duplicate of something (if you look at my proposal, I really did study a lot of API). IMHO, they are not. Somehow, for me, the goal for a sound API is similar to DAPI ( http://lists.freedesktop.org/archives/portland/2007-January/thread.html#929) The notification service offers some sound event API. It could be the place where my proposal would be used. Then desktop app should only use Notification API. But I don't see background music in a game as a notification. Of course GStreamer should be used then. But if you think about it, the abstraction we need, in fact, is the GStreamer playbin API. I like Phonon for this reason. By chance, nothing need to be changed: ds_play ("/usr/local../toto.mp3") A better sound & PCM API is necessary to get rid of Esound correctly ( http://live.gnome.org/PulseAudio). Then GNOME will start to offer a better sound experience and it will be time to reconsider GSmartMix again (@etienne: the project is not dead ;) Hopefully Gmail will not screwed up the links this time... Cheers, -- Marc-André Lureau, GSmartMix On 3/19/07, Rodney Dawes <[EMAIL PROTECTED]> wrote:
On Mon, 2007-03-19 at 18:01 +0000, Richard Hughes wrote: > So we have a sound server. Can this play themed sounds? Once upon a time, I started a sound theme spec, based on the current Icon Theme specification, and sounds implementation in GNOME, as I have no idea how the KDE sound themes work. When I sent this to the XDG list, it received nothing but push back from all the KDE people on the list. Perhaps it's time to propose such a spec again, with a little revision, so that we can use it for both KDE and GNOME. We can also specify some basic desktop sound events. However, while it's great to have sounds for events in the desktop, there are other useful configuration options as well. I think it would be extremely useful to have an "events" spec which would deal with the events portion, and a sound theme spec to only deal with the sounds portion. The events spec could define basic desktop events, and what potential actions could be taken, such as play a sound, show a notification bubble, or run a program. -- dobey _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
