AVRCP future

AVRCP future

[Sander van Grieken]

Hi All,

I've been looking into AVRCP a bit lately, since I'm interested in the 'Remote Control 
from Separate Controller' usecase as described in the AVRCP spec, section 2.3.1.1.

However, from the BlueZ source, it seems an AVRCP connection is only set up/allowed when 
there is a AVD sink present, which is in violation of the bluetooth spec, section 2.3.2

Also, the recent progress made by João Paulo Rechi Vita bind the control and audio stream 
closely together (basically disabling the control once audio is not pulseaudio-routed to 
the bluetooth peer).

Now, my questions:

- Is anyone working on AVRCP, besides jprvita?
- Aside from the proposed D-Bus API in doc/control-api.txt, has anyone done some research 
how an AVRCP1.4 interface should look?
- Are there objections to conforming to section 2.3.2, i.e. untying the AVRCP connection 
from the A2DP connection?

I'm willing to put some effort in improving AVRCP, but before I go off blindly coding such 
stuff, please give as much feedback as possible :)

grtz,
Sander

Re: AVRCP future

[Johan Hedberg]

Hi Sander,

On Wed, Sep 01, 2010, Sander van Grieken wrote:
> - Is anyone working on AVRCP, besides jprvita?

Maybe, but nothing I'm aware of.

> - Aside from the proposed D-Bus API in doc/control-api.txt, has anyone
> done some research how an AVRCP1.4 interface should look?

Mostly just ideas that haven't really been written down. It'd be easier
if we talked about specific features though than about a profile version
since different features will require different design solutions and
API's. E.g. in the MeeGo case we'd probably be talking to tracker in
order to implement media browsing, however other platforms might have a
different storage backend which means that we'll need some sort of
backend driver abstraction (we have a similar situation already in obexd
PBAP and contact storage).

> - Are there objections to conforming to section 2.3.2, i.e. untying
> the AVRCP connection from the A2DP connection?

If by that you mean adding Connect() and Disconnect() method calls to
the org.bluez.Control D-Bus interface, then I'd be happy to accept
patches for it. However, the automated connecting of AVRCP as triggered
by an A2DP connection should stay in order to keep good interoperability
and make things easy for the user interface code.

Johan

Re: AVRCP future

[Sander van Grieken]

Hi Johan, 

Thanks for your feedback.

On Wednesday 01 September 2010 20:57:29 Johan Hedberg wrote:
> Hi Sander,
> 
> On Wed, Sep 01, 2010, Sander van Grieken wrote:
> > - Is anyone working on AVRCP, besides jprvita?
> 
> Maybe, but nothing I'm aware of.
> 
> > - Aside from the proposed D-Bus API in doc/control-api.txt, has anyone
> > done some research how an AVRCP1.4 interface should look?
> 
> Mostly just ideas that haven't really been written down. 

Argh, there a wiki would come in handy ;) It has probably gone over the list a few times, 
but I just joined the list and the web archives are.. cumbersome, and google didn't find 
much of avrcp in the list.

> It'd be easier
> if we talked about specific features though than about a profile version
> since different features will require different design solutions and
> API's. E.g. in the MeeGo case we'd probably be talking to tracker in
> order to implement media browsing, however other platforms might have a
> different storage backend which means that we'll need some sort of
> backend driver abstraction (we have a similar situation already in obexd
> PBAP and contact storage).

I'm not in favor of having (multiple) storage plugins. Simply because a storage backend is 
not a player. This distinction is important. MeeGo/tracker is a semantic index, so in 
theory you could browse the media through it, but the player might have 'smart' playlist, 
or is only able to play media of a certain kind. Also the current playlist is a player-
only thing (and is also a browsable item). So I think browsing should go _through_ the 
player.

I was more thinking of exposing a dbus interface that allows a player (or any TG) to 
register itself as a TG, then acting on signals/sending events/responses.

> > - Are there objections to conforming to section 2.3.2, i.e. untying
> > the AVRCP connection from the A2DP connection?
> 
> If by that you mean adding Connect() and Disconnect() method calls to
> the org.bluez.Control D-Bus interface, then I'd be happy to accept
> patches for it. However, the automated connecting of AVRCP as triggered
> by an A2DP connection should stay in order to keep good interoperability
> and make things easy for the user interface code.

Agreed.

> 
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: AVRCP future

[Luiz Augusto von Dentz]

Hi,

On Thu, Sep 2, 2010 at 11:20 AM, Sander van Grieken
<sander@outrightsolutions.nl> wrote:
> I'm not in favor of having (multiple) storage plugins. Simply because a storage backend is
> not a player. This distinction is important. MeeGo/tracker is a semantic index, so in
> theory you could browse the media through it, but the player might have 'smart' playlist,
> or is only able to play media of a certain kind. Also the current playlist is a player-
> only thing (and is also a browsable item). So I think browsing should go _through_ the
> player.
>
> I was more thinking of exposing a dbus interface that allows a player (or any TG) to
> register itself as a TG, then acting on signals/sending events/responses.

That could be done, actually this is a similar idea as we are planning
to have[1] for replacing our audio ipc, but for things like progress
we would really need to cache it since most device Ive seem keep
polling this. Another possibility is to use MPRIS and PulseAudio
together, but the spec of MPRIS need some work right now the player
assume some name with a prefix e.g: org.freedesktop.MPRIS which is not
that nice, perhaps making MPRIS a separate daemon would make more
sense.

This means that for freedesktop we have:

    BlueZ <-> PulseAudio <-> MPRIS

For the rest:

    BlueZ <-> Player/whatever

If that is done in PulseAudio we could probably associate the metadata
directly with the stream using MPRIS, if it is up to the player then
we don't care they can set this information directly via some D-Bus
API that is yet to be defined, which wouldn't require player to
implement MPRIS spec. Joao Paulo has something already so I guess we
can start from there[2].

[1] http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
[2] http://git.profusion.mobi/cgit.cgi/jprvita/bluez/log/?h=avrcp_metadata

-- 
Luiz Augusto von Dentz
Computer Engineer

Re: AVRCP future

[Sander van Grieken]

On Thursday 02 September 2010 14:56:10 you wrote:
> On Thu, Sep 2, 2010 at 11:20 AM, Sander van Grieken
> > I was more thinking of exposing a dbus interface that allows a player (or any TG) to
> > register itself as a TG, then acting on signals/sending events/responses.
> 
> That could be done, actually this is a similar idea as we are planning
> to have[1] for replacing our audio ipc, but for things like progress
> we would really need to cache it since most device Ive seem keep
> polling this.
> Another possibility is to use MPRIS and PulseAudio
> together, but the spec of MPRIS need some work right now the player
> assume some name with a prefix e.g: org.freedesktop.MPRIS which is not
> that nice, perhaps making MPRIS a separate daemon would make more
> sense.
> 
> This means that for freedesktop we have:
> 
>     BlueZ <-> PulseAudio <-> MPRIS
> 
> For the rest:
> 
>     BlueZ <-> Player/whatever
> 
> If that is done in PulseAudio we could probably associate the metadata
> directly with the stream using MPRIS, if it is up to the player then
> we don't care they can set this information directly via some D-Bus
> API that is yet to be defined, which wouldn't require player to
> implement MPRIS spec. Joao Paulo has something already so I guess we
> can start from there[2].
> 
> [1] http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
> [2] http://git.profusion.mobi/cgit.cgi/jprvita/bluez/log/?h=avrcp_metadata

Thanks Luiz,

I'm aware of João's work. In fact I've already merged his work into my branch, he exposed 
much of the AVRCP controls.

I see the benefit of MPRIS+PulseAudio for AVRCP 1.3, but for 1.4 MPRIS is just too 
limited. Also, it's only for audio players [1], while AVRCP also specifies (TV) menu 
controls and such, so it exceeds the scope of MPRIS.

Your git looks interesting! Added to remotes :)

grtz,
Sander


[1] http://xmms2.org/wiki/Media_Player_Interfaces#Overview