RFC - a casual sound API on fd.o?

[Thiago Macieira]

Marc-André Lureau wrote:
>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.

This is the xdg mailing list -- cross desktop. I wonder what there is of 
cross-desktop in your proposal if it were not to integrate with theming, 
configuration and that kind of stuff that desktops provide.

When you mentioned in your proposal "playing events and very simple audio 
players", I thought you wanted to integrate to the Notification API.

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

Well, I do doubt that an IPC call via D-Bus (which will involve at least 
two context switches) would be faster than simply playing the sound 
locally, even if you could the extra time required to load the library.

But if you start using a library for this, a library for that, etc., soon 
you'll end up with 30-50 more libraries in simple applications. THAT's a 
waste, considering we're talking about simple applications.

What's more, existing frameworks are widely tested and hopefully have less 
bugs. If you reuse those -- especially the desktop-specific parts -- you 
get a lot less problems for your proposal.

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

D-Bus interfaces for which service? You need to define a service too, 
which means a running daemon, which means we get back to what I proposed.

PS: take a look at the Notification work.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20070109/0add7c18/attachment.pgp