[mpris] [RFC] MPRIS2 Release Candidate

[Lennart Poettering]

On Sat, 07.08.10 23:53, Alex Merry (kde at randomguy3.me.uk) wrote:

> 
>  On 07/08/10 19:20, Lennart Poettering wrote:
> >- please use the recently standardized property change signals when
> >   properties change. Don't cook your own signals.
> 
> There's a recent standard for property change signals?  I can't find
> it with a cursory search of the web (or the D-Bus site), but I'm not
> really sure what I'm looking for.  Could you point us to it?

It's in the D-Bus spec in the dbus repo (unfortunately the online
version of the spec has not been updated yet). See
doc/dbus-specification.xml in the dbus git repo.

> >- i am not a particular fan of using integers for bit flag fields/enums
> >   on D-Bus. I think it is usually much nicer to use strings for
> >   enums. And bitfields should probably be just seperate bool
> >   properties. modern bindings such as gdbus optimize this nicely and
> >   retrieve all flags with a single call.
> 
> That's probably reasonable.  It's a pity that Qt doesn't support
> retrieving all properties at once.

Well, I think a D-Bus intzerface should be designed correct, and not be
designed with one specific D-Bus glue code generator in mind. Or in
otherwise: make sure Qt gets fixed, don't let Qt brokeness reflect to
the interface.

> >- It makes little sense to me that "capabilities" might change. What's
> >   the rationale? CapabilitiesChanged is redundant I believe.
> 
> Capabilities simply indicate what is possible _at this moment_.  For
> example, it is not possible to go to the next track if there is no
> next track.  It allows clients to present a disabled interface
> element, for example.

As mentioned elsewhere I don't think that "capabilities" is a good name
for that.

> I'm undecided about the minor one.  On the one hand, the
> UnknownMethod error should be sufficient, but it's potentially
> useful to clients to know in advance what to expect (they might
> offer a slightly different interface depending on the version
> implemented, for example).

Well, you can do that easily with ifaces: if the user asks for
org.mpris.Foobar1.Waldo() then he problably means a different
implementation then if he asks for org.mpris.Foobar2.Waldo().

> >- i wonder how scalabale the playlist stuff is. i.e. does it always make
> >   sense to send the list of playlist in a single msg? If there's a
> >   substantial amount of playlists (and there might very likely be as
> >   most music on the internet ship with an .m3u or .pls file). I think
> >   this needs some logic to allow splitting up requests and responses
> >   into chunks, so that multiple small messages may be sent instead of a
> >   single big one.
> 
> Do you have a suggestion for a sane way of doing this?

the mediaserver spec as implemented by rygel, pa, the dvb daemons and
grilo does it right.

> Everything in your music collection?  The tracklist is just what is
> in the current tracklist, or in a particular playlist.  And we don't
> even require that the server exposes the _entire_ tracklist.

Well, but what's the point of not showing the full thing? I mean, either
you wrap the track list or you don't. What's the point of doing it only
partially? use case?

> >- i think the track id should be a dbus object path. That's how we
> >   identify objects in dbus. this wouldn't even have to mean that you
> >   expose any interfaces for these objects...
> 
> I don't think we need to require that.  There's no particular use
> for it.  If implementations want to do that, they can, but I don't
> see why we should constrain them in that regard.

Well, it's a question of type-safety. If you have an object you identify
it with an object path. It's how D-Bus does object
identification. There's no point in adding multiple different kinds of
object identifiers.

> >- what unit is the value for AdjustVolume in? dB? linear? probably
> >   neither? given that for many audio devices the volume scale is unknown
> >   it is probably not smart using dB/linear here. Hence you should probably say that 0.0 is
> >   silence and 1.0 is a "sensible maximum volume", but you probably
> >   should allow the volume to go beyond 1.0. and everything in between
> >   should be in a scale that "feels right" to the user.
> 
> Well, in a way, it's whatever scale the implementation considers
> sensible.  The user will expect a slider control for the volume in
> the client to behave in the same way as the volume control provided
> by the media app itself, so that's how it should work.  0.0 is
> minimum, 1.0 is maximum, what happens in between should be
> "sensible".

I think it is a bad idea to imply that there is a maximum. Amplification
in theory can be without limits (even if it sounds terrible due to
digital amplification artifacts).

> >- If you pass times use 64bit integers and use usec as unit. That's what
> >   most media systems do these days and i think is a the only unit that
> >   makes remotely sense.
> 
> microseconds?  This is for music players, not real-time audio
> editing.  Given the latencies involved in sending messages over
> D-Bus and what humans can generally deal with, even milliseconds is
> probably overzealous, but it's a nice easy value to deal with that's
> finer than seconds.

Well, that's not the point. It's a simple question of not having to
convert times all the time. You should use a single time unit
everywhere. Because otherwise you lose precision all the time by
conversion. While you probably don't care about the precision here it is
still a problem: let's say app seeks to time x usec. then it reads back
the time to figure out if anything changed. If you always convert then
it might appear the time changed even though the stgream might actually
have been paused.

You don't want to convert all the times, absolutely not. It's just a
waste of thinking. Use usec as unit. It's the least common denominator
and you win nothing by giving up on precision here.

Also, in case I presume a non-trivial number of media players might not
only play music but also video. For those accurate timing actually might
matter, sind with them you could select a specific video frame or so
when in pause mode. 

> >Also, I wonder how this actually relates to the grilo dbus apis? also,
> >the mediaserver dbus spec seems similar a bit too (if only for the track list
> >part). There might be a good opportunity to reuse existing interfaces or
> >at least make the interfaces feel similar in style.
> 
> http://live.gnome.org/Rygel/MediaPlayerSpec
> 
> Oh, joy, another media player control spec.  What was MPRIS for again?

Well, don't blame Zeeshan for that. You must admit that MPRIS appeared
kinda dead in the last months. It's great that it came to life again,
and maybe we can streamline this now.

Also note that Zeeshan's use for upnp actually means the dbus api must
support a certain set of features otherwise not necessary.

> Is http://live.gnome.org/Rygel/MediaServer2Spec the media server
> spec you were referring to?  I can't find the Grilo D-Bus apis,
> unless that's the media player spec I linked to above.

Yes, that's the spec I was referring to. I don't have any specs for
grilo handy either.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.