AVRCP 1.4 : Future on Target Role

AVRCP 1.4 : Future on Target Role

[Shivendra Agrawal]

Hi All,

I have been looking at AVRCP 1.4 in BlueZ and intending to
enhance/develop this profile for the target role. I have been
following the discussion initiated by Sander van Grieken earlier last
month, and as I understand, they are premitive and has scope for
further enhancements.

In the current BlueZ implementation, control-api.txt mentions few
methods e.g. SendVendoeDependent, ChangePlayback..., that are not
referred/implemented in the code, or I may be unable to find at right
place.
Further, there are some more AVRCP 1.4 TG specific Notify and Browsing
commands that can be added.

I am willing to define some preliminary interface APIs for Target
Media Applications to register itself with BlueZ, and would come back
with some idea proposal for your suggestions on improvements.

I am keen to receive your feedback with some ideas and thoughts to put
my effort in right direction.

Question:
Is anyone working on AVRCP 1.4 Target role profile development?

Regards,
Shivendra

Re: AVRCP 1.4 : Future on Target Role

[Luiz Augusto von Dentz]

Hi,

On Tue, Oct 19, 2010 at 9:16 AM, Shivendra Agrawal
<ag.shivendra@gmail.com> wrote:
> Hi All,
>
> I have been looking at AVRCP 1.4 in BlueZ and intending to
> enhance/develop this profile for the target role. I have been
> following the discussion initiated by Sander van Grieken earlier last
> month, and as I understand, they are premitive and has scope for
> further enhancements.

Joao Paulo also did some work in this area using MPRIS, I guess he
even publish his tree somewhere.

> In the current BlueZ implementation, control-api.txt mentions few
> methods e.g. SendVendoeDependent, ChangePlayback..., that are not
> referred/implemented in the code, or I may be unable to find at right
> place.
> Further, there are some more AVRCP 1.4 TG specific Notify and Browsing
> commands that can be added.

I would suggest you to take a look at media-api.txt, this is what we
area planning to use for streams and we should probably add support
for metadata and browsing (those 2 seems to be the most asked features
from avrcp nowadays). Actually metadata seems to fit nicely there, we
just need another interface to receive stream metadata, now browsing
is probably not so easy.

> I am willing to define some preliminary interface APIs for Target
> Media Applications to register itself with BlueZ, and would come back
> with some idea proposal for your suggestions on improvements.

If media players all agree on using MPRIS than we probably don't need
to have them registering to us, in the other hand Im not sure if MPRIS
API do cover everything in terms of avrcp, maybe you can figure this
out.

> I am keen to receive your feedback with some ideas and thoughts to put
> my effort in right direction.
>
> Question:
> Is anyone working on AVRCP 1.4 Target role profile development?

Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)

Re: AVRCP 1.4 : Future on Target Role

[Sander van Grieken]

On Tuesday 19 October 2010 10:31:33 Luiz Augusto von Dentz wrote:
> Hi,
> 
> On Tue, Oct 19, 2010 at 9:16 AM, Shivendra Agrawal
> <ag.shivendra@gmail.com> wrote:
> > Hi All,
> >
> > I have been looking at AVRCP 1.4 in BlueZ and intending to
> > enhance/develop this profile for the target role. I have been
> > following the discussion initiated by Sander van Grieken earlier last
> > month, and as I understand, they are premitive and has scope for
> > further enhancements.
> 
> Joao Paulo also did some work in this area using MPRIS, I guess he
> even publish his tree somewhere.

Yes, it's at git://git.profusion.mobi/users/jprvita/bluez.git

> > In the current BlueZ implementation, control-api.txt mentions few
> > methods e.g. SendVendoeDependent, ChangePlayback..., that are not
> > referred/implemented in the code, or I may be unable to find at right
> > place.

Yes, the document is more like a proposal, than a description of the actual 
implementation.

> > Further, there are some more AVRCP 1.4 TG specific Notify and Browsing
> > commands that can be added.
> 
> I would suggest you to take a look at media-api.txt, this is what we
> area planning to use for streams and we should probably add support
> for metadata and browsing (those 2 seems to be the most asked features
> from avrcp nowadays). Actually metadata seems to fit nicely there, we
> just need another interface to receive stream metadata, now browsing
> is probably not so easy.
> 
> > I am willing to define some preliminary interface APIs for Target
> > Media Applications to register itself with BlueZ, and would come back
> > with some idea proposal for your suggestions on improvements.
> 
> If media players all agree on using MPRIS than we probably don't need
> to have them registering to us, in the other hand Im not sure if MPRIS
> API do cover everything in terms of avrcp, maybe you can figure this
> out.

I am very much in favor of not directly depending on MPRIS, but instead letting 
applications registering themselves as a target. For two reasons:

- AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have 
different semantics, especially w.r.t. event notifications. So we would limit ourselves to 
the intersecting subset of both technologies.
- A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
enabled players, so we can have both full implementation of the AVRCP spec, AND generic 
MPRIS support.

> > I am keen to receive your feedback with some ideas and thoughts to put
> > my effort in right direction.
> >
> > Question:
> > Is anyone working on AVRCP 1.4 Target role profile development?
> 
> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)

Actually, the metadata work is not part of v1.4 of the spec, but 1.3

Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and 
some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his 
stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap 
and conflict with Joao's stuff, so I'm hesitant to go there.

Shivendra, before you start, let's sync so we don't duplicate efforts

grtz,
Sander

Re: AVRCP 1.4 : Future on Target Role

[Luiz Augusto von Dentz]

Hi,

On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
<sander@outrightsolutions.nl> wrote:
> I am very much in favor of not directly depending on MPRIS, but instead letting
> applications registering themselves as a target. For two reasons:
>
> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
> the intersecting subset of both technologies.
> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
> MPRIS support.

Sounds good to me, we can use Media API to register players as well.

>> > I am keen to receive your feedback with some ideas and thoughts to put
>> > my effort in right direction.
>> >
>> > Question:
>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>
>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>
> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>
> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
> and conflict with Joao's stuff, so I'm hesitant to go there.

I hope to see this code being push upstream soon, I will try to
contact Joao Paulo to get an idea if the code is ready to be
reviewed/pushed so we get the things rolling.

> Shivendra, before you start, let's sync so we don't duplicate efforts
>
> grtz,
> Sander
> --
> 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
Computer Engineer

Re: AVRCP 1.4 : Future on Target Role

[David Stockwell]

Your observation that AVRCP 1.3 is not implemented is correct, and I am 
(finally!) actively back at work on implementing AVRCP 1.3, based on the 
control-api.txt documentation.  IMO, this would be a good foundation for 
1.4.

For my purposes, I am not keen on 1.4, personally I find it overcomplicated 
for what should be a relatively simple interface; however, obviously others 
differ.

Do you have an AVRCP CT (other than a headset) that you are working with?

David Stockwell

--------------------------------------------------
From: "Shivendra Agrawal" <ag.shivendra@gmail.com>
Sent: Tuesday, October 19, 2010 1:16 AM
To: <linux-bluetooth@vger.kernel.org>
Subject: AVRCP 1.4 : Future on Target Role

> Hi All,
>
> I have been looking at AVRCP 1.4 in BlueZ and intending to
> enhance/develop this profile for the target role. I have been
> following the discussion initiated by Sander van Grieken earlier last
> month, and as I understand, they are premitive and has scope for
> further enhancements.
>
> In the current BlueZ implementation, control-api.txt mentions few
> methods e.g. SendVendoeDependent, ChangePlayback..., that are not
> referred/implemented in the code, or I may be unable to find at right
> place.
> Further, there are some more AVRCP 1.4 TG specific Notify and Browsing
> commands that can be added.
>
> I am willing to define some preliminary interface APIs for Target
> Media Applications to register itself with BlueZ, and would come back
> with some idea proposal for your suggestions on improvements.
>
> I am keen to receive your feedback with some ideas and thoughts to put
> my effort in right direction.
>
> Question:
> Is anyone working on AVRCP 1.4 Target role profile development?
>
> Regards,
> Shivendra
> --
> 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 1.4 : Future on Target Role

[Shivendra Agrawal]

Hi All,

Thanks a lot for nice feedback. I will do some study on the MPRIS and
suggestions for TG<->Media API, and would come back soon.
I would certainly sync with all to avoid any duplicate effort.

Meanwhile, I also found a need to enhance the sdp record for Browsing
PSM and feature set. This would be needed by CT to establish Browsing
Channel with TG.

Question:
Is anyone working on this or I could put some proposal for discussion?

David,
If you are going to resume AVRCP 1.3 implementation, can we sync
together as I have done some study on this part as well.
So far I don't have any device and guess PTS can be taken as start point.

Regards,
Shivendra

On Tue, Oct 19, 2010 at 9:44 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
> <sander@outrightsolutions.nl> wrote:
>> I am very much in favor of not directly depending on MPRIS, but instead letting
>> applications registering themselves as a target. For two reasons:
>>
>> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
>> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
>> the intersecting subset of both technologies.
>> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
>> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
>> MPRIS support.
>
> Sounds good to me, we can use Media API to register players as well.
>
>>> > I am keen to receive your feedback with some ideas and thoughts to put
>>> > my effort in right direction.
>>> >
>>> > Question:
>>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>>
>>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>>
>> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>>
>> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
>> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
>> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
>> and conflict with Joao's stuff, so I'm hesitant to go there.
>
> I hope to see this code being push upstream soon, I will try to
> contact Joao Paulo to get an idea if the code is ready to be
> reviewed/pushed so we get the things rolling.
>
>> Shivendra, before you start, let's sync so we don't duplicate efforts
>>
>> grtz,
>> Sander
>> --
>> 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
> Computer Engineer
> --
> 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 1.4 : Future on Target Role

[David Stockwell]

Hi Shivendra,

> Hi All,
>
> David,
> If you are going to resume AVRCP 1.3 implementation, can we sync
> together as I have done some study on this part as well.
> So far I don't have any device and guess PTS can be taken as start point.

(PTS??)

Regarding an AVRCP device, I have not found any on the market.  I designed 
and built a remote control based on a CSR BC4 chip, with LCD display and 
keypad controller (and battery charger, USB, etc., etc.).  Firmware is 
programmed using the CSR BlueCore SDK.  The latest version (version 4.1.2) 
of the SDK includes functions that provide support for AVRCP 1.3, but 
probably not for 1.4 AFAIK.

For my purposes, I am not implementing A2DP and headset capability in this 
remote.

David
>
> Regards,
> Shivendra
>
 

RE: AVRCP 1.4 : Future on Target Role

[Waldemar.Rymarkiewicz]

Hi David, 

>Regarding an AVRCP device, I have not found any on the market. 

There are already devices with AVRCP 1.4 on the market. See https://www.bluetooth.org/tpg/listings.cfm  for listing (use advanced searching).

Reagrads 
/Waldek

Re: AVRCP 1.4 : Future on Target Role

[David Stockwell]

Hi Waldek,

> Hi David,
>
>>Regarding an AVRCP device, I have not found any on the market.
>
> There are already devices with AVRCP 1.4 on the market. See 
> https://www.bluetooth.org/tpg/listings.cfm  for listing (use advanced 
> searching).

Thanks...I should have looked there, and will do so.

>
> Reagrads
> /Waldek
>
> 

Re: AVRCP 1.4 : Future on Target Role

[João Paulo Rechi Vita]

Hello all,

I've seen some discuss regarding how to add support for AVRCP 1.3 and
1.4 versions on the ML lately, and some expectations over the related
work I've done in BlueZ. Sorry for the long delay on replying, I've
been pretty busy lately and just didn't got the time. I'm planing to
put some effort again on this work on the coming weeks.

On Tue, Oct 19, 2010 at 14:14, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
> <sander@outrightsolutions.nl> wrote:
>> I am very much in favor of not directly depending on MPRIS, but instead letting
>> applications registering themselves as a target. For two reasons:
>>
>> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
>> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
>> the intersecting subset of both technologies.
>> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
>> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
>> MPRIS support.
>
> Sounds good to me, we can use Media API to register players as well.
>

I agree with Sander's opinion that MPRIS seems a bit limited for 1.4.
OTOH it's an already defined and under-adoption standard. If we have
applications registering themselves directly with us, we'll have to
define a new interface for that and push this to the player
applications. Do you guys already have a draft of these interfaces
(for the applications and extensions to the Media API)? I guess we
should try to define exactly what we need first, and them see what's
missing from MPRIS.

>>> > I am keen to receive your feedback with some ideas and thoughts to put
>>> > my effort in right direction.
>>> >
>>> > Question:
>>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>>
>>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>>
>> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>>
>> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
>> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
>> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
>> and conflict with Joao's stuff, so I'm hesitant to go there.
>

Have you published this code somewhere?

> I hope to see this code being push upstream soon, I will try to
> contact Joao Paulo to get an idea if the code is ready to be
> reviewed/pushed so we get the things rolling.
>

I'm finally here :) I've focused mostly in the 1.3 version of the spec
and having pulseaudio as a middle-man in my work, and have written
most of the code in pulseaudio to handle these new functionality. Even
if we take the approach described above for 1.4, IMO it makes sense to
upstream this so we can have earlier support for 1.3 and also to
support Sander's work. Luiz, Johan, what do you think?

I'll review the code once more, since I've written it a few months
ago, but my main concern about pushing it upstream right now is that
it hasn't been tested yet. I have no device to test against and PTS
can't give us no guarantee whether the code really works in practice
or not (but it's still better than nothing). Sander, David, have you
tested my code against any real device?

-- 
João Paulo Rechi Vita
http://jprvita.wordpress.com/

Re: AVRCP 1.4 : Future on Target Role

[shivendra.agrawal@stericsson.com]

Hi All,

ST-Ericsson plans to implement the commands to support target role of
AVRCP 1.4 Profile, and we would like to contribute it to BlueZ.
With our initial discussion, I would be aligning with BlueZ
contributors and would propose for the ideas that has not been
touched/developed so far, in order to have a design/implementation
that can be accepted.

As a very first, and very rough, design proposal for the BlueZ parts:
- A new SDP record for AVRCP 1.4 would be added to inform CT of the
version and features supported by target.
- A new callback to accept browsing channel establishment.
- Enhancing similar to bt_io_listen for browsing PSM.
- A new browsing command handler
- Incremental addition to AVRCP 1.4 commands.

Any feedback is very much appreciated!

Regards,
Shivendra


2010/10/25 João Paulo Rechi Vita <jprvita@gmail.com>:
> 2010/10/25 Shivendra Agrawal <ag.shivendra@gmail.com>:
>> 2010/10/23 João Paulo Rechi Vita <jprvita@gmail.com>:
>>> Hello all,
>>>
>>> I've seen some discuss regarding how to add support for AVRCP 1.3 and
>>> 1.4 versions on the ML lately, and some expectations over the related
>>> work I've done in BlueZ. Sorry for the long delay on replying, I've
>>> been pretty busy lately and just didn't got the time. I'm planing to
>>> put some effort again on this work on the coming weeks.
>>>
>>> On Tue, Oct 19, 2010 at 14:14, Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
>>>> <sander@outrightsolutions.nl> wrote:
>>>>> I am very much in favor of not directly depending on MPRIS, but instead letting
>>>>> applications registering themselves as a target. For two reasons:
>>>>>
>>>>> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
>>>>> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
>>>>> the intersecting subset of both technologies.
>>>>> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
>>>>> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
>>>>> MPRIS support.
>>>>
>>>> Sounds good to me, we can use Media API to register players as well.
>>>>
>>>
>>> I agree with Sander's opinion that MPRIS seems a bit limited for 1.4.
>>> OTOH it's an already defined and under-adoption standard. If we have
>>> applications registering themselves directly with us, we'll have to
>>> define a new interface for that and push this to the player
>>> applications. Do you guys already have a draft of these interfaces
>>> (for the applications and extensions to the Media API)? I guess we
>>> should try to define exactly what we need first, and them see what's
>>> missing from MPRIS.
>>>
>>>>>> > I am keen to receive your feedback with some ideas and thoughts to put
>>>>>> > my effort in right direction.
>>>>>> >
>>>>>> > Question:
>>>>>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>>>>>
>>>>>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>>>>>
>>>>> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>>>>>
>>>>> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
>>>>> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
>>>>> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
>>>>> and conflict with Joao's stuff, so I'm hesitant to go there.
>>>>
>>>
>>> Have you published this code somewhere?
>>>
>>>> I hope to see this code being push upstream soon, I will try to
>>>> contact Joao Paulo to get an idea if the code is ready to be
>>>> reviewed/pushed so we get the things rolling.
>>>>
>>>
>>> I'm finally here :) I've focused mostly in the 1.3 version of the spec
>>> and having pulseaudio as a middle-man in my work, and have written
>>> most of the code in pulseaudio to handle these new functionality. Even
>>> if we take the approach described above for 1.4, IMO it makes sense to
>>> upstream this so we can have earlier support for 1.3 and also to
>>> support Sander's work. Luiz, Johan, what do you think?
>>>
>>> I'll review the code once more, since I've written it a few months
>>> ago, but my main concern about pushing it upstream right now is that
>>> it hasn't been tested yet. I have no device to test against and PTS
>>> can't give us no guarantee whether the code really works in practice
>>> or not (but it's still better than nothing). Sander, David, have you
>>> tested my code against any real device?
>>
>> You are right, PTS does not guarantee, but I guess, PTS viewer can support
>> checking the frame that is sent is as per protocol.
>> This could give a safe hands of the implementation. Does that assumption helps?
>
> Yes, you can view what is passing by the bluetooth radio, but it's
> still the same as testing against the PTS only. The best would be to
> have device which someone could test against.
>
> --
> João Paulo Rechi Vita
> http://jprvita.wordpress.com/
>

Re: AVRCP 1.4 : Future on Target Role

[Gustavo F. Padovan]

Hi Shivendra,

* shivendra.agrawal@stericsson.com <ag.shivendra@gmail.com> [2010-10-27 12:27:54 +0530]:

> Hi All,
> 
> ST-Ericsson plans to implement the commands to support target role of
> AVRCP 1.4 Profile, and we would like to contribute it to BlueZ.
> With our initial discussion, I would be aligning with BlueZ
> contributors and would propose for the ideas that has not been
> touched/developed so far, in order to have a design/implementation
> that can be accepted.
> 
> As a very first, and very rough, design proposal for the BlueZ parts:
> - A new SDP record for AVRCP 1.4 would be added to inform CT of the
> version and features supported by target.
> - A new callback to accept browsing channel establishment.
> - Enhancing similar to bt_io_listen for browsing PSM.
> - A new browsing command handler
> - Incremental addition to AVRCP 1.4 commands.
> 
> Any feedback is very much appreciated!

Top posting is not allowed in this mailing list. Thanks. ;)

-- 
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

Re: AVRCP 1.4 : Future on Target Role

[shivendra.agrawal@stericsson.com]

2010/10/23 João Paulo Rechi Vita <jprvita@gmail.com>:
> Hello all,
>
> I've seen some discuss regarding how to add support for AVRCP 1.3 and
> 1.4 versions on the ML lately, and some expectations over the related
> work I've done in BlueZ. Sorry for the long delay on replying, I've
> been pretty busy lately and just didn't got the time. I'm planing to
> put some effort again on this work on the coming weeks.
>
> On Tue, Oct 19, 2010 at 14:14, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
>> <sander@outrightsolutions.nl> wrote:
>>> I am very much in favor of not directly depending on MPRIS, but instead letting
>>> applications registering themselves as a target. For two reasons:
>>>
>>> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
>>> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
>>> the intersecting subset of both technologies.
>>> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
>>> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
>>> MPRIS support.
>>
>> Sounds good to me, we can use Media API to register players as well.
>>
>
> I agree with Sander's opinion that MPRIS seems a bit limited for 1.4.
> OTOH it's an already defined and under-adoption standard. If we have
> applications registering themselves directly with us, we'll have to
> define a new interface for that and push this to the player
> applications. Do you guys already have a draft of these interfaces
> (for the applications and extensions to the Media API)? I guess we
> should try to define exactly what we need first, and them see what's
> missing from MPRIS.
>
>>>> > I am keen to receive your feedback with some ideas and thoughts to put
>>>> > my effort in right direction.
>>>> >
>>>> > Question:
>>>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>>>
>>>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>>>
>>> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>>>
>>> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
>>> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
>>> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
>>> and conflict with Joao's stuff, so I'm hesitant to go there.
>>
>
> Have you published this code somewhere?
>
>> I hope to see this code being push upstream soon, I will try to
>> contact Joao Paulo to get an idea if the code is ready to be
>> reviewed/pushed so we get the things rolling.
>>
>
> I'm finally here :) I've focused mostly in the 1.3 version of the spec
> and having pulseaudio as a middle-man in my work, and have written
> most of the code in pulseaudio to handle these new functionality. Even
> if we take the approach described above for 1.4, IMO it makes sense to
> upstream this so we can have earlier support for 1.3 and also to
> support Sander's work. Luiz, Johan, what do you think?
>
> I'll review the code once more, since I've written it a few months
> ago, but my main concern about pushing it upstream right now is that
> it hasn't been tested yet. I have no device to test against and PTS
> can't give us no guarantee whether the code really works in practice
> or not (but it's still better than nothing). Sander, David, have you
> tested my code against any real device?
>
I have requested some inputs from all to start exchange our ideas as
Subject: [RFC] AVRCP 1.4 : Design proposal for future on Target Role
I would be keen to receive your feedback. Thanks in advance.

AVRCP 1.3/1.4 current implementation

[David Stockwell]

Hello to all,

In my earlier work, I noticed that in audio/manager.c, function 
handle_uuids, when the UUID was found for an AVRCP target or controller, it 
would only launch avrcp_connect IF a Sink was enabled and present.

I suspect this was done to make sure that if a headset or similar was 
connecting, it would make sure the audio side of the connection was up and 
running before enabling the control side of the interface.

However, my device has no audio side, it is a pure AVRCP CT, so there is no 
audio-side connection.  In previous testing, I just unconditionally started 
avrcp_connect and it all worked fine for my purposes.  I am wondering if 
there is any other impact.

I could submit the patch in which avrcp_connect is unconditionally called. 
Or, I could just wait until all of the uuids are processed (after the 
g_slist_foreach in audio_probe), then launch avrcp_connect if either (a) a 
sink is connected and enabled as at present, or (b) if no sink is called for 
or provided by the CT/TG (as expressed in SDP), just launch avrcp_connect 
without the sink.  Are there any other impacts that this might cause?

To Joao, I would like to test my device against the GSOC work you did; can 
you send me the URL?  If you are farther along, no sense re-inventing the 
wheel. Thanks/obrigado.

David Stockwell 

Re: AVRCP 1.3/1.4 current implementation

[Sander van Grieken]

On Saturday 30 October 2010 19:57:31 David Stockwell wrote:
> Hello to all,
> 
> In my earlier work, I noticed that in audio/manager.c, function 
> handle_uuids, when the UUID was found for an AVRCP target or controller, it 
> would only launch avrcp_connect IF a Sink was enabled and present.
> 
> I suspect this was done to make sure that if a headset or similar was 
> connecting, it would make sure the audio side of the connection was up and 
> running before enabling the control side of the interface.
> 
> However, my device has no audio side, it is a pure AVRCP CT, so there is no 
> audio-side connection.  In previous testing, I just unconditionally started 
> avrcp_connect and it all worked fine for my purposes.  I am wondering if 
> there is any other impact.

Yes the current implementation only (implicitly) connects the RCP if a connection is made 
to a DTP (audio) profile, or if a RCP connection request is received from the peer.

I have already implemented a DBUS method to connect only the RCP, but is only tested with 
devices that also have the DTP profile, so this might not work if there's no DTP profile 
detected on the peer. The code uses a struct audio_device * to pass along to the various 
RCP functions, that might or might not be available when the peer has no DTP profile..

I think we can add the factoring out of the audio_device dependency to the TODO list. 
Probably something along the lines of defining a struct control_device and have a pointer 
to an optional audio_device struct in there.

I've made this stuff available in my git at github:

git://github.com/accumulator/bluez.git

grtz,
Sander