[mpris] [RFC] MPRIS2 Release Candidate

Sun Aug 8 14:25:24 CEST 2010

  On 08/08/10 11:47, Lennart Poettering wrote:
> On Sat, 07.08.10 23:53, Alex Merry (kde at randomguy3.me.uk) wrote:
>> 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.

For reference:

If one or more properties change on an object, the| 
|org.freedesktop.DBus.Properties.PropertiesChanged signal may be emitted 
(this signal was added in 0.14):||

org.freedesktop.DBus.Properties.PropertiesChanged (
STRING interface_name,
DICT<STRING,VARIANT> changed_properties,|
|ARRAY<STRING> invalidated_properties);|

|where changed_properties is a dictionary| |containing the changed 
properties with the new values and| |invalidated_properties is an array 
of| |properties that changed but the value is not conveyed.|

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

That's true - there is the possibility to offer more than one interface 
on the same object at once, and one could simply be a subset of the other.

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

It looks like a very nice way to expose a library.

However, for playlists, as well as wanting extra properties (like 
current track for the active playlist; not a problem to add, though), we 
are likely to have different interactions.  Playlists are likely to be 
modified more frequently than libraries, and may well be modified by the 
client (using D-Bus methods for that purpose).  The same track may well 
appear twice in the same container.  We don't want clients accidentally 
removing the wrong track from the playlist because they have a slightly 
out-of-date version of it - the trackid concept was specifically to 
avoid this kind of race.

On the other hand, following the MediaContainer2 spec, I would expect 
each track (not each occurrence in the playlist) to have a separate 
D-Bus object (especially when you consider the interactions between a 
library interface and a playlist interface).  But maybe I'm 
misunderstanding.

Also, I'd want more informative "changed" signals than just "Updated", 
but that doesn't stop us following the general concept.

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

Because clients want to know about what's coming up, or what's just been 
past.  But some crazy people put their entire collection in the 
playlist, and that's just insane, and we went for the option of allowing 
a "sensible subset" of such playlists.

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

I don't get how types come into it.  Whatever way you look at it, it's 
nothing more than a hunk of text - we're not offering objects on the 
bus, so why make it look like we are?  It just looks like a way to make 
implementation of the spec slightly more difficult.

If we were to go the MediaServer2 route, and have the entries in the 
playlist be actual D-Bus objects implementing a D-Bus interface, that 
would make sense, though.

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

And what software interface offers a way of doing this?  Other than 
audio-editing applications, of course, which MPRIS isn't concerned 
with.  I mean, I guess we can relax the spec to say that "1.0 is a 
sensible maximum, and servers can do what they want with greater 
values", but I don't really see the point.

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

Well, I suppose fewer conversions means fewer chances for screwing up, 
which is a good thing.  So, eh, I don't really have any objections to this.

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

I don't see why milliseconds won't do that - I'm not aware of videos 
that run at even 100fps, which is already 10x coarser than milliseconds.

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

Yeah, but we were faced with the same thing, and did something about it, 
which is why it came back to life again.  Anyway, the past is a 
fruitless area of discussion - we should work on improving the situation.

Alex