<br><br><div><span class="gmail_quote">On 1/10/07, <b class="gmail_sendername">Thiago Macieira</b> <<a href="mailto:thiago@kde.org">thiago@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is the xdg mailing list -- cross desktop. I wonder what there is of<br>cross-desktop in your proposal if it were not to integrate with theming,<br>configuration and that kind of stuff that desktops provide.</blockquote>
<div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">When you mentioned in your proposal "playing events and very simple audio
<br>players", I thought you wanted to integrate to the Notification API.</blockquote><div><br>In one way, yes. I think a notification program could you such a simple API without worrying about who and what will be executed.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>>And you could add the sound calls to DAPI. No need for an *extra*<br>> >library
<br>>> (each .so is an added cost on program load time). Especially if your<br>>> library would require loading of libogg, libvorbis and libalsa --<br>>> that's four DSO that would be loaded.<br>>
<br>>That would be loaded by an external process: libraries need to be loaded<br>>anyway. Why people are more confident on system capabilities with IPC<br>> and multiple process than on simple memory sharing (if we expect the
<br>> code to be runtime error clean)? I sometime wonder.<br><br>Well, I do doubt that an IPC call via D-Bus (which will involve at least<br>two context switches) would be faster than simply playing the sound<br>locally, even if you could the extra time required to load the library.
</blockquote><div><br>I am not sure to really understand. Then we agree? </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">But if you start using a library for this, a library for that, etc., soon
<br>you'll end up with 30-50 more libraries in simple applications. THAT's a<br>waste, considering we're talking about simple applications.</blockquote><div><br>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)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What's more, existing frameworks are widely tested and hopefully have less
<br>bugs. If you reuse those -- especially the desktop-specific parts -- you<br>get a lot less problems for your proposal.</blockquote><div><br>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).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>If I was not clear enough, this DS API has *also* the goal to define<br>> DBus interfaces for
fd.o. (btw this is just a C API, it can be quite<br>> easily rewritten to any language, I seriously think).<br><br>D-Bus interfaces for which service? You need to define a service too,<br>which means a running daemon, which means we get back to what I proposed.
</blockquote><div><br>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")<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
PS: take a look at the Notification work.</blockquote><div><br>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 :)
<br></div><br></div><br>-- <br>Marc-André Lureau, GSmartMix