RFC - a casual sound API on fd.o?
Thiago Macieira
thiago at kde.org
Tue Jan 9 16:48:31 PST 2007
Marc-André Lureau wrote:
>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.
I have no idea what the state of the GNOME API. You are comparing your
idea to PortAudio/PortMusic, but from what I can tell, the goal is very
similar between you two. Why not join forces instead?
>>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.
I think instead that applications could bypass your library and use the
Notification API instead.
Again, I see overlap between the two. Why not join forces? Especially
since part of the Notification API is to play sound events. Though
Notification is not to be abused to be an audio player.
>> 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?
We agree that the cost of an IPC call is greater than the cost of loading
one extra, simple library.
My point (below) was that one library doesn't impact too much, the trend
of many libraries does. If we can avoid it, we shouldn't have an extra
library. Your API could conceivably fit inside libdapi.
>>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).
No. I meant the whole audio implementation. Desktops already have audio
components that are tested and working. They have backends for many
different audio systems (OSS, Alsa, NAS, NSS, GStreamer, Jack, the list
goes on) which you would have to code from the scratch.
On the other hand, requiring a D-Bus interface from the desktops would
hold back the adoption of your library for a year, at least.
>> 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")
Then you did not understand what I meant with a D-Bus service.
>>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 :)
I see three kinds of audio events, in my small view of the world:
1) notifications (reactions to user input or other events)
2) sound tracks from games or websites
3) complex audio output stemming from multimedia players (sometimes
requiring video synchronisation)
#1 is definitely libnotify's job. #3 is definitely not and also definitely
not your job either. So we end up with #2: do we need an extra
library/framework/API for doing that or can we simply fold back the
necessary features into something close?
Sorry to say, but it seems to me that you're reinventing the wheel here.
Notification and PortMusic (as well as Phonon, but that's not
cross-desktop) are very close to your goal already.
One more thing: have you verified if there is a demand for this kind of
API on a cross-desktop basis? I know you're worried about the state of
the GNOME API (you said so), but if this is restricted to GNOME, it might
be better to fix there.
--
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/20070110/125e1ce9/attachment.pgp
More information about the xdg
mailing list