[mpris] MPRIS misdesigns

[Rémi Denis-Courmont]

       Hello,

Le mercredi 11 février 2009 22:28:38 Lennart Poettering, vous avez écrit :
> In PulseAudio we'd like to add some logic that would allow automatic
> pausing of music/movie streams when a voip call comes in. I am now
> considering forwarding those pause requests to the applications via
> MPRIS.

That looks like a terrible idea to me. But I'll come back to that later.

> However after having a rough look over MPRIS I have some issues 
> with the API design:
>
> - The Pause() API is broken by design: there is no way to reliably
> pause a stream without knowing the previous state of the stream in
> advance. This can be queried via GetStatus but it is inherently racy to
> do so the pause status might have changed already until we can call
> Pause().

Yes. In retrospect, the fact that our implementation of MPRIS is racy as well 
is not a surprise.

> Now you might say this is a tiny race.

But that's hardly an excuse.

> Unfortunately it is a  real problem for me: e.g. Gstreamer-based media
> players will get the pause request inline anyway, hence if they pause due to
> an inline request that might interfere with the MPRIS logic we would provide
> as fallback for non-Gstreamer media players. The API design is full of races
> like this, but this one is actually a problem for the use case I am
> interested in.
(...)
> - There is no way for PA to map a specific application stream to a
> media player instance on the bus. It would be good if at least the
> process name/PID of an MPRIS service could be queried so that we can
> reliably map streams to player instances.

The media players trust PulseAudio to do audio mixing, routing and perhaps 
apply a few fancy post-processing algorithm. They don't trust PulseAudio to 
callback into their input controls.

You mentioned that gstreamer would be notified of the audio output preemption 
inline. Why would other players not be notified as well, assuming they use 
PulseAudio in the first place? Silently muting ALSA emulation users seems 
like an acceptable limitation. On the other hand, VLC could well 
be "outputting" to a file or to the network. We don't want PulseAudio to 
blindly pause the media stream in that case.

Moreover, a completely separate notification channel will probably come with 
race conditions of its own.

> Or may I assume that the service name suffix as in "org.mpris.foobar"
> actually is the process name? I assume I may not, given that that is not
> documented. 

To the contrary, I actually assume that is how it was meant to be. Namely, VLC 
uses (abuses?) the MPRIS interface against itself to support queueing files 
to the playlist from file browsers. In other words, when the user "opens" a 
media file whose type is associated with VLC, VLC looks for another instance 
of itself on the bus using MPRIS. If there is on, it adds a track, and exits 
immediately.

This is a questionable design choice. As you can guess, it only allows one 
instance of a given media player at a time.

(...)
> Hmm, is anyone actually still working on MPRIS?

As far as I can see from the VLC side, it has not gone under any work for 
about a year, which would be when Raphaël Carré left the VideoLAN all but 
officially. Mirsail already stated he was busy.

(...)
> However the current interface has too many shortcomings to actually be
> useful except for the most trivial cases. Hence, I'd love if someone would
> beef up this spec and make sure it gets updated in the various players.

The VLC MPRIS plugin is currently an orphan, meaning it won't be updated.
Unlike(?) gstreamer, VLC is not (financially) supported by any handset and/or 
desktop distro vendor.

Best regards,

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary