Audacious

This came up in a report from a user of the GSConnect gnome-shell plugin who was experiencing high CPU usage from GSConnect when playing music in Audacious.

GSConnect is a local implementation of the KDE Connect protocol for two-way communication with one or more paired Android devices on the local network, and in concert with the KDE Connect Android app, proxies various services and interactions between the device(s) and Gnome Shell in both directions. This proxying includes MPRIS2 media control, with the Android app providing status display and transport controls for any compatible media players running on the desktop.

The high CPU load was determined to be caused by the flood of Position updates emitted whenever Audacious is playing a track, due to all of those updates being proxied to the Android device. This condition is not encountered with any other media player (that we are aware of), and in our reading of the MPRIS2 spec, is improper behavior on the part of Audacious' MPRIS2 plugin.

The MPRIS2 D-Bus Interface Specification documentation of the MediaPlayer2.Player interface has this to say about Position (emphasis mine):

Position — x (Time_In_Us)
Read only
The org.freedesktop.DBus.Properties.PropertiesChanged signal is not emitted when this property changes.
The current track position in microseconds, between 0 and the 'mpris:length' metadata entry (see Metadata).

Note: If the media player allows it, the current playback position can be changed either the SetPosition method or the Seek method on this interface. If this is not the case, the CanSeek property is false, and setting this property has no effect and can raise an error.

If the playback progresses in a way that is inconstistant with the Rate property, the Seeked signal is emited.

In typical operation (based on empirical testing with both VLC and MPD), an MPRIS2 server would emit the Position property only once at the start of play, or at song change. The client would then use the Position and Rate properties to run a local timer for position updates, independent of the MPRIS2 server application. Until a transport event (play stop, track skip, etc.), further signals would not be emitted except, as the spec indicates, If the playback progresses in a way that is inconstistant with the Rate property. If play is proceeding normally, it is not necessary to emit Position updates on the session bus, because the client will keep track itself based on the emitted playback parameters.

My testing was performed on Fedora 29 using the current audacious-3.10-1.fc29.x86_64 and audacious-plugins-3.10-1.fc29.x86_64 packages. However, the current source of mpris2/plugin.cc still contains the update() function to emit position (Lines 170-183), and the 4 Hz timer that causes them to be emitted four times per second (Line 360), so I would expect this issue to affect all releases newer than 3.10, as well as the current git HEAD.