RFC - a casual sound API on fd.o?
marcandre.lureau at gmail.com
Tue Jan 9 14:56:02 PST 2007
On 1/10/07, Thiago Macieira <thiago at kde.org> wrote:
> 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.
Exactly. As far as I know theming support is is a very early stage, and it's
nice to have the advice of people that have experience on xdg about
interface that support it. But you are right, as it is stated at the very
first post, at least, it could help, one day, to define a cleaner GNOME api
(since PulseAudio is still a bit too complex and do not really target
play("bling"), or a kind of PartAudio API (ala PortMusic, for example). Or
even a private implementation. It would not be a problem if it is never
implemented. It is simply the way I express my concern about simple audio
API for the desktop that don't want to finish as a battle of PCM iface, hw
capabilites & in/out process discussions.
When you mentioned in your proposal "playing events and very simple audio
> players", I thought you wanted to integrate to the Notification API.
In one way, yes. I think a notification program could you such a simple API
without worrying about who and what will be executed.
>>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.
I am not sure to really understand. Then we agree?
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.
Yep, it depends on a larger decision. The problem is that today, we end up
with too much daemon (at least for limited computers) when we just need a
limited subset of them. And nice glueing of daemon (which involve a common
main loop api, I would say), is still a pending problem. So why the design
of a sound event API "should" imply DBus ? (DS Sound Iface would be provided
anyway, as I said)
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.
By framework, I suppose you are talking about mainloop, asynchronous,
errors, and simple polymorphism. Because everything is implementation detail
(for instance, the firsts backends would probably be GStreamer or
PulseAudio, or even DBus and my own limited daemon coded with a limited
version of the very same API with GStreamer).
>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.
Yes, you need to define a service. And you need to know where this service
will be running. Sometime, these questions doesn't make sense when I just
need play("my file")
PS: take a look at the Notification work.
I know a bit about libnotify. I am not sure that libnotify is the best
place. Do you like the idea that every (simple) desktop sound would be
played (or go through) it. I would rather see notification daemons as one of
the common use cases of it. But it might end up the other way :)
Marc-André Lureau, GSmartMix
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg