---------- Forwarded message ---------- From: Marc-André Lureau <[EMAIL PROTECTED]> Date: Jan 10, 2007 2:40 AM Subject: Re: RFC - a casual sound API on fd.o? To: Thiago Macieira <[EMAIL PROTECTED]>
On 1/10/07, Thiago Macieira <[EMAIL PROTECTED]> 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
