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
> <[email protected]> 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
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
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
2010/10/23 Jo?o Paulo Rechi Vita <[email protected]>:
> 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
> <[email protected]> wrote:
>> Hi,
>>
>> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
>> <[email protected]> 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.
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
<[email protected]> wrote:
> Hi,
>
> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
> <[email protected]> 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/
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
>
>
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
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
>
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
<[email protected]> wrote:
> Hi,
>
> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
> <[email protected]> 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 [email protected]
>> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Hi,
On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
<[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Luiz Augusto von Dentz
Computer Engineer