Fwd: RFC - a casual sound API on fd.o?
marcandre.lureau at gmail.com
Tue Jan 9 17:44:05 PST 2007
---------- 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
> 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
> 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
> 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
#3 is definitely not and also definitely
> not your job either.
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,
Marc-André Lureau, GSmartMix
Marc-André Lureau, GSmartMix
More information about the xdg