RFC - a casual sound API on fd.o?

[Thiago Macieira]

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