Re: Desktop sounds in Gnome

Hi all,

@richard: A SoC project? why not, but there should be an agreement before someone /waste/ time.
Tango for sound? BANGO! (

@rodney: I used your spec. It would be great to put it for real on fdo, with the xml (ala

@gustavo: there is a flash support for 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 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 ).

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 ( 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 (

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 ( 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...


Marc-André Lureau, GSmartMix

On 3/19/07, Rodney Dawes <dobey novell com> 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

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