[Portland] DAPI Sound for Portland? and general comments

Thu Jan 11 15:24:21 PST 2007

On 1/11/07, Mikael Hallendal <micke at imendio.com> wrote:

    I think it would make sense to have a call to play up a sound file,
    for example for when a new message arrives in your inbox. I think
    however that anything more advanced than a simple "PlaySoundFile"
    doesn't fit in the current design of DAPI.

Under the dapi.sound interface, there is a simple Play method.

Such methd, I would say, should not be limited to take only a filename. A
URI at least  would be much nicer. Another thing that comes to my mind, is
that PlaySoundFile under dapi has only a limited chance to succeed on a
cross-desktop project: if you need such function, then you probably need to
do more advanced things, like getting metadata (even if there is other way
for files, but lets talk about URI instead). Why? Because, if you refer to a
soundfile, that means you are probably not willing to play a sound event.
Right now, I only see a file manager for this "file" need (see Nautilus
sound, for example). But a file manager need more things, like changing the
playing state, seeking (and it would be nice, of course to set fadein/out!).
Basically, you need some control. So you need to define an object that
implement a sound.playback interface.

Let's talk rather about events (I see much more use in this case for
cross-desktop applications - even if such call should come from a
notification daemon/api), then you will have to give an id. Hopefully, all
this can be handled easily with the same method, or at least, I guess it
would be nice). And I agree, then, you probably don't want to see further
object/handler/control. But if you start thinking about theming, then you
will need some other object/interface like dapi.sound.theme. Still, lets
stick to something simple: Name, and PathList would be enough for
sound.theme (that should implement the waited fd.o spec).

What if you have to implement a classic game? background music would need
some control, volume level, and you might appreciate looping (see the very
simple QSound API that has been strimmed down over the year. They still
provide Loop property).

Hmm. No, let's talk about the cool things. Space positionning (an event come
from the position of your window, interesting, would it be ?). Priority! Of
course, I want to hear my phone ringing even if my resource is busy playing
something else - and that would be nice if the other apps lower.I'll call
that playback.advanced interface.

So we end up with a kind of list of requirement that would be nice to
provide. If you look at the use case for the desktop (I have done that, even
if I think that developpers are deaf because they don't use sound or because
it's not big priority, or because we don't have a clear way to do it, or
because it's boring to end up writing the samething all the time for dealing
with PCM streaming, negotiation...)

I try to unify desktop applications needs with a quite simple interface for
people, like me sometime, who don't really care about the default
API/backend, but would like to have a simple API that make a best effort for
any desktop.

Now, I can understand that maybe, DAPI is not the right place: I can imagine
reading the specs, that you can be expecting another completely different
behavior, like "opening the default media player for this particular desktop
with this sound (a la xdg script)". But I would suggest another api for
that: OpenSoundFile or even OpenFile (ala xdg-open). The discussions take
place to see where it could fit (we even thought about PortMusic or
PortAudio, it might finally be PortDesktop, but I would find that a bit
funny)

    More advanced functions such as setting volume, fade, loop, set
    position etc would probably fit better in it's own component for such
    applications (music players comes to mind) that need that.

And everyone write the same thing (in different ways, yes) to handle the
very same control over audio playback. But I don't really target music
players (I target my_first_music player, yep). Believe me, I know that music
players need more advanced things :) Even a common desktop sound API will
need other properties if they don't come from other common API (like program
name, application name, pid, user,...). one more thing I am considering is
to add a window id to the sound object. But there might be other way. There
is tons of things that we can define under DAPI. I just don't know what is
the border line for you guys :)

    > Regarding DAPI "core", what about a common vtable for main loops/
    > events, similar to the one of D-Bus (instead of just leaving fd to
    > watch for)? It is interesting for different services implementation
    > without big limitations, I guess.

    I take it this refers to the IPC layer that is not being used in the
    GNOME Dapi Daemon (where we use D-BUS). The idea is that all
    implementations will use the same IPC layer and as far as I know the
    current idea is to use D-BUS for this.

The idea is that I don't want to care if it's an underlying IPC. Sometime it
does not make sense to use IPC (for example with play sound or open!). Still
the DBus interface should be provided also, I can (to some extent) agree and
vote for it.

But async calls are important. And implementation of different static lib
version of the abstract api would need an event loop. And we face the very
difficult and embarrassing problem to define a common main loop for various
things (and other related needs).

    I can only talk about the GNOME part of DAPI but we are currently
    waiting a bit to see where the D-BUS GLib bindings will go with
    regards to generating the client side library from the D-BUS
    specification XML.

Ok, one flavour with Glib (I suppose you are talking about GObject instead).
And what about a plain C implementation that I suggest? That's the reason
why we can say that any flavour of an interface lib should share the
description of the main loop dbus currently use. That would be great.

Think about it, we could have:
- a sound lib that implement the C interface and use pulse or alsa directly
   - a plain C dapi library using the sound lib (and hence no DBus) OR/AND
DBus for other things (that is none of my business if I write C app)
   - a dbus daemon using the same sound lib for implementing DBus calls.

You end up with a nice integration, and still cross-desktop with different
flavors choices (choosen by ISV or power user).

I won't develop other ideas I have, I would probably regret it later :)

Regards,

-- 
Marc-André Lureau, GSmartMix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/portland/attachments/20070112/b2f61f64/attachment.htm