marc-andre.lureau at nokia
Jul 30, 2007, 4:14 AM
Post #2 of 2
(1190 views)
Permalink
|
|
Re: com.osso.Playback.Manager and friends (libplayback-1-0 mostly)
[In reply to]
|
|
Hi Kemal,
On Sun, 2007-07-29 at 12:26 +0300, ext Kemal Hadimli wrote:
> I'm looking for info on com.osso.Playback.Manager, libplayback-1-0 and
> possibly osso-hss-control. If you have the time, a couple minutes free
> on your lunch break, a few words (preferably along with a few sample
> dbus calls) would suffice.
It's now lunch time!
In previous maemo releases, the media-server had two methods
com.nokia.osso_media_server.disable and .enable in order to "suspend"
the player when you made/receive a call. To improve the usability, it
was necessary to extend this behavior to any supported player (flash,
rhapsody, canola, to name a few) and also other voice applications.
We designed an interface that a player should implement in order to be
managed:
Each playback object /com/osso/playback%d has:
<interface name="com.osso.Playback">
<property name="State" type="s" access="readwrite"/>
<property name="AllowedState" type="as" access="readwrite"/>
<property name="Class" type="s" access="read"/>
</interface>
- State property allows the client to declare its current state (from a
limited set for now: None,Play,Stop), and a controller change the
playback State (it can fail)
- AllowedState property is a set of state that the user is allowed to
ask for (this give us a chance to grey out some UI buttons)
- Class is the playback object class from Media, VoIP, Event,
Background...
Those property are notify when they change (it uses a *non-standard
Notify* signal from DBUS_INTERFACE_PROPERTIES).
When a player need to make a state change, it has to kindly request it
to the com.osso.Playback.Manager (it could also *override* the
permission: this is generally a bad idea) using the RequestState method.
The reply is either an error, or the newly permitted state. Meanwhile,
the manager take care of changing the state of the other players (and
changing the allowed states).
The manager is currently provided by hss-control. And the rule is rather
simple: the first VoIP play request stops everything. The last Media
player to request "Play" get the "Play" lock. The Background class
remains playing, even if a Media is playing (Flash case).
> I was testing some stuff when I stumbled upon the com.osso.Playback
> signal, and followed from there. Tried some dbus calls with no luck.
> No reason, I'm just curious. Could help with a media player project
> though.
Eh eh, it is not enough to send a call via dbus-send (because the
manager need additional information from the requester, especially if
the first it asks is a new state...).
libplayback try to implement the interface the right way. An application
needs to worry for a minimal bunch of call/cb.
At some point we wanted to open a specification for this interface and
also support the library. But we had to postpone the sharing, because of
the lack of a "home" place in the stack. And the high subject-to-change
condition. We are thinking of two coming projects to land this proposal:
MPRIS (which could replace the client interface) and OHM or PulseAudio
for the managing bits.
> Thanks.
You're welcome!
Note: hss-control is a rather bad name for all its doing (at the
beginning it was handling headsets): now this daemon handles audio
routing/tuning stuffs, the playback management, a few legacy interfaces,
some audio power management, and the sound interactions (click-tap). We
are studying how to distribute this work in HAL/OHM and other projects.
|
