Fwd: RFC - a casual sound API on fd.o?

[Marc-André Lureau]

---------- Forwarded message ----------
From: Marc-André Lureau <marcandre.lureau at gmail.com>
Date: Jan 10, 2007 2:40 AM
Subject: Re: RFC - a casual sound API on fd.o?
To: Thiago Macieira <thiago at kde.org>


On 1/10/07, Thiago Macieira <thiago at kde.org> wrote:

> idea to PortAudio/PortMusic, but from what I can tell, the goal is very
> similar between you two. Why not join forces instead?

because portmusic goal is broader and in a very young stage. portaudio
concern is about portability. not defining  a common interface. But it
is an idea I am thinking of also. Iam not sure our goals can be
shared.


> I think instead that applications could bypass your library and use the
> Notification API instead.
 Yes they should, if notification api cover such case. But then, which
api will be used by the daemon? why couldnt it benefit from the
flexibility of a common interface? and leave the choice to the
distrib?

> Again, I see overlap between the two. Why not join forces?

This is all about joining forces. at least in my pov.

> Notification is not to be abused to be an audio player.

i couldnt agree more.

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

Agree. an interface proposal doesnt say where what library provide it.
Altthough it explicitly suggest as a thin wrapper library that could
be linked statically.

> library. Your API could conceivably fit inside libdapi.
I did not thought about that. it seems some ideas have already been
discussed for dapi audio iface. that might be a good place for it
then.


> No. I meant the whole audio implementation. Desktops already have audio

I really don't suggest to write yet again a new implementation. the
goal is to define iface that could become a thin wrapper either in
existing audio or desktop lib or new library.


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

good to know that you are as limited as I do.
>
> #1 is definitely libnotify's job.

Ok, but it might be cool to have the choice over the backend, and
expect it to react the same way if I glue a plugin or an intrusive
code.

#3 is definitely not and also definitely
> not your job either.

of course.

 So we end up with #2: do we need an extra lib?

I don't see any library or interface that covers what wa usually need
with flexibility and non abusive design.

> One more thing: have you verified if there is a demand for this kind of
> API on a cross-desktop basis?

Come on. We are on xdg!! should i spam every ml?

but if this is restricted to GNOME, it might
> be better to fix there.

That was the initial plan. As you say, joigning forces could be
possible. Furthermore, this not really dependant on gnome, nor gtk,
nor gib...
--
Marc-André Lureau, GSmartMix


-- 
Marc-André Lureau, GSmartMix