AVRCP 1.6

AVRCP 1.6

[Niek Vlessert]

Hello list,

I've developed some player thing with chiptune music in the browser and 
I wanted an Android app using Webview to be able to change tracks and 
see the titles with my car audio system. After some experimenting I got 
it done using the MediaSession/PlaybackState/MediaMetadata Android 
provides. However I wondered about album art. After experimenting and a 
lot of google I'm currently here;

- Album art was standardised in AVRCP 1.6 although older versions had 
some openings that could be used but nobody did.
- As far as I know no car media system supports AVRCP 1.6 yet, but there 
seems to be some reference platform for car manufacturers; AudioVideoSDK 
3.0, that supports it.
- Bluez supports AVRCP up to 1.5
- I can't find any evidence it's been worked on
- MediaMetadata has support for images, but I suppose that's 
non-bluetooth related (Chromecast?).
- Some car systems with an iPhone can use the internet connection 
provided by the phone to download album art from cddb, which is why some 
people believe iPhone supports AVRCP 1.6. I don't think that's 
implemented in non iPhone devices?
- Some others support it in the MP3 file on the local SD card, but I'm 
not using MP3.
- Currently I'm testing my little Android app in conjunction with an 
Ubuntu VM on my iMac, because Ubuntu can run in A2DP sink mode thanks to 
Bluez.
- I'm testing AVRCP with D-feet, previous/next etc. works fine!!
- Using Wireshark on my VM I can see what's going on

So onto my questions:

- Is there any work being done on this?
- Is there any software on Linux out there to test AVRCP 1.6? I can't 
find any.
- 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.
- 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... ;)

And of course I'm ready to test.

Regards,

Niek Vlessert

Re: AVRCP 1.6

[Luiz Augusto von Dentz]

Hi Niek,

On Tue, Jun 21, 2016 at 1:08 AM, Niek Vlessert <niekvlessert@gmail.com> wrote:
> Hello list,
>
> I've developed some player thing with chiptune music in the browser and I
> wanted an Android app using Webview to be able to change tracks and see the
> titles with my car audio system. After some experimenting I got it done
> using the MediaSession/PlaybackState/MediaMetadata Android provides. However
> I wondered about album art. After experimenting and a lot of google I'm
> currently here;
>
> - Album art was standardised in AVRCP 1.6 although older versions had some
> openings that could be used but nobody did.
> - As far as I know no car media system supports AVRCP 1.6 yet, but there
> seems to be some reference platform for car manufacturers; AudioVideoSDK
> 3.0, that supports it.
> - 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.

> - I can't find any evidence it's been worked on
> - MediaMetadata has support for images, but I suppose that's non-bluetooth
> related (Chromecast?).

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.

> - Some car systems with an iPhone can use the internet connection provided
> by the phone to download album art from cddb, which is why some people
> believe iPhone supports AVRCP 1.6. I don't think that's implemented in non
> iPhone devices?

I don't think so either, even in case of chromecast it is a custom
protocol by the application or the full tab if you are using chrome to
cast.

> - Some others support it in the MP3 file on the local SD card, but I'm not
> using MP3.
> - Currently I'm testing my little Android app in conjunction with an Ubuntu
> VM on my iMac, because Ubuntu can run in A2DP sink mode thanks to Bluez.
> - I'm testing AVRCP with D-feet, previous/next etc. works fine!!

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.

> - Using Wireshark on my VM I can see what's going on
>
> So onto my questions:
>
> - Is there any work being done on this?
> - Is there any software on Linux out there to test AVRCP 1.6? I can't find
> any.

I don't think anyone has come to implement AVRCP 1.6 for any OS
actually, at least not the commands necessary for cover art transfer.

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

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

> And of course I'm ready to test.
>
> Regards,
>
> Niek Vlessert
> --
> 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



-- 
Luiz Augusto von Dentz

Re: AVRCP 1.6

[Niek Vlessert]

>> - 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!

>
> 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 ?

>
> 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?

>
>> - 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?

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

Re: AVRCP 1.6

[Luiz Augusto von Dentz]

Hi Niek,

On Thu, Jun 23, 2016 at 12:15 AM, Niek Vlessert <niekvlessert@gmail.com> wrote:
>
>>> - 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!
>
>>
>> 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.

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

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

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