AVRCP future

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

Hi Sander,

Maybe, but nothing I'm aware of.

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

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

Hi Johan,

Thanks for your feedback.

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.

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.

Agreed.

Hi,

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

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