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
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
Hi,
On Thu, Sep 2, 2010 at 11:20 AM, Sander van Grieken
<[email protected]> 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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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