Re: AVRCP 1.6

Hi Niek,

On Thu, Jun 23, 2016 at 12:15 AM, Niek Vlessert [off-list ref] wrote:

quoted

quoted

- Bluez supports AVRCP up to 1.5

Actually we can do up to 1.6 but just the mandatory commands which
don't include the ones necessary for cover art, etc.

Ok, great!

quoted

Android has support only to 1.3, there are vendors that extend to
1.4/1.5 like samsung but they have to change all the way from HAL to
java to interface this to the application.

Interesting, do you know any reasons why Google won't incorperate a newer
version ?

I guess it will demand some effort given that it affects not only the
stack but the API in the players to deal with the new commands. But as
far as cover art is concern I guess it is a no go because OBEX in
Android is actually implemented in java which would probably not
interact that well when called directly from the underline stack.

quoted

You can use tools/bluetooth-player if you want to control it from the
command line, another alternative is to use tools/mpris-proxy and then
control it using a MPRIS controller.

Great, I've been looking into those. It seems to me bluetooth-player as the
CT and mprix-proxy as the TG can provide a test setup for future AVRCP 1.6
testing. It's interesting to see that the mpris spec supports an artUrl
already:
https://www.freedesktop.org/wiki/Specifications/mpris-spec/metadata/#index3h4.
I'm thinking bluetooth-player sends the image through AVRCP 1.6 to the
mpris-proxy. mpris-proxy puts it in /tmp/ and provides a url like
file:///tmp/<randomstring>.bmp to the mediaplayer through the Art URL. What
do you think of this approach?

Yep, it was made to be easy to interact with MPRIS which is a more
common interface for media players in Linux, but note that it is
usually the other way around as bluetooth-player is the CT it should
be the one receiving the cover art from the mpris-proxy TG which can
of course use the artUrl. You can also use 2 instances of mpris-proxy,
one in each box, or just one if you have 2 bluetooth controllers
plugged in the same host, mpris-proxy works both ways as it can create
MPRIS players from remote devices as well as expose local players.

quoted

quoted

- Would you consider it possible to put the right hex into my Android app
and transmit that to my Bluetooth connection so I can implement it
without
the Android Bluez stack supporting it? If target devices will ever
support
it... Since it's serial communication, I thought why not? I never did
anything like this with Bluetooth programming so forgive my ignorance. :)
Something like this: create L2CAP channel with the Cover Art UUID. Wait
for
response; encode picture in the right data packages, and here we go.
Leave
other Bluetooth communication requirements to Android.

You can do whatever you want, but since it would be non-standard this
would limit a lot the usage.

Well, I was hoping I could keep it standard compliant using this method.
However since you responded like this; do you think it's not possible to
create the correct hex strings in my own program for some reason?

AVRCP has its own commands to transfer the cover art using OBEX, and
as far I know it is the only adopted profile capable of doing this.

quoted

quoted

- Or maybe I could use the cddb support? Maybe it's possible to redirect
traffic to cddb to somewhere else, provide the cddb interface and offer
the
image like that? I know, it's horrible... ;)

Also non-standard, perhaps investing time in doing a AVRCP 1.6 would be
better.

That would be awesome. I'm not that good at c but maybe I can try to
implement it in the player and the proxy with tips from you, adding it to
BlueZ however is another story I guess. :)

You would be very welcome if you do that.

-- 
Luiz Augusto von Dentz