[mpris] [RFC] MPRIS2 Release Candidate

[Lennart Poettering]

On Sun, 08.08.10 13:25, Alex Merry (kde at randomguy3.me.uk) wrote:

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

Yes, exactly.

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

Does such an UI exist or is this just an idea?

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

Well, it's an object identifier. And D-Bus has the special "o" type for
these. That's why we should use it.

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

PulseAudio actually offers you this by default. We suggest that the UI
caps at 150% but the lower layers of the stack are actually without
limit. Since this spec should be considered a "lower layer of the stack"
it shouldn't limit this either.

Volume control is a science of its own. It's a complex thing I as the PA
dude have thought quite a bit about and we have this page now in our
wiki which tries to explain all the complexities involved:

http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders

For the MPRIS case a single unbounded positive volume floating point
value should be fine, where 0.0 is defined as "silence" and 1.0 as
"sensible max volume", and the scale should "feel right" for
human interaction.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.