RFC - a casual sound API on fd.o?

[Marc-André Lureau]

Thiago,

On 1/9/07, Thiago Macieira <thiago at kde.org> wrote:
>
>
> An out-of-process implementation of a few D-Bus API calls would be almost
> trivial to implement in a running daemon that desktop environments
> already provide. They already have theming capabilities -- or will
> have -- and already have all the necessary resources to play sound
> already.


That would mean it explicitly force programs to use dbus & a sound server to
play a sound. That sound a bit too much for me. We have mixing capabilities
in hw, or even in-process with dmix. Why should we "force" such a simple
library to depend on dbus a seperate process? As far as I know, e17 does not
depend on it (or at least, it seems you can disable it). Neither do Firefox
and people that simply use ion & vim on a limited terminal. I don't like the
idea to push dbus for something like playing simple sound events.
Notifications frameworks, for example, can justify the dependency on DBus.
But sound_play("bling") "dependent" on DBus looks a bit too much to convince
me... I would probably stick to an SDL_Mixer, or a PortAudio API to play a
"bling" in this case, if I need to write a small, static program for an
embedded use, for example.

And you could add the sound calls to DAPI. No need for an *extra* library
> (each .so is an added cost on program load time). Especially if your
> library would require loading of libogg, libvorbis and libalsa -- that's
> four DSO that would be loaded.


That would be loaded by an external process: libraries need to be loaded
anyway. Why people are more confident on system capabilities with IPC and
multiple process than on simple memory sharing (if we expect the code to be
runtime error clean)? I sometime wonder.

If I was not clear enough, this DS API has *also* the goal to define DBus
interfaces for fd.o. (btw this is just a C API, it can be quite easily
rewritten to any language, I seriously think).

Best regards,


-- 
Marc-André Lureau, GSmartMix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070110/a5441f5c/attachment.htm