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!
Ref: Previous discussion subject: "AVRCP 1.4 : Future on Target Role"
Regards,
Shivendra
Hi,
On Wed, Oct 27, 2010 at 11:23 AM, [email protected]
<[email protected]> wrote:
> 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!
>
> Ref: Previous discussion subject: "AVRCP 1.4 : Future on Target Role"
I guess for all people that are interested in AVRCP 1.4 we can start
adding items to TODO list, to make it easier to share development
between us. Since this may be too much to handle in a single global
TODO maybe we can have a separated file like audio/TODO.
--
Luiz Augusto von Dentz
Computer Engineer
Hi Shivendra,
> AVRCP 1.4
> ==========
>
> - Add SDP record for AVRCP 1.4 to inform CT of the version and features
> supported by target.
>
> Priority: Medium
> Complexity: C1
One extra issue here is that the SDP record needs to vary according to the players running: if the AVRCP layer statically set the AVRCP version in the SDP record to be 1.4, AND the player(s) was a legacy pre-1.4 application that did not know about browsing then the device integrator would have compliance issues.
So I believe there is a need for an API that the player would set if it can support mandatory v.1.4 target features. If the API is not called (eg by backwards compatibility) then the SDP record would continue to publish version 1.3.
This may increase your complexity value.
> As per spec section 6.6.1 GetElementAttributes
> As per spec section 6.10.4.3 GetItemAttributes
Note that by overall spec design these are very similar. Indeed, according to 6.10.4.3, AVRCP 1.4 CTs shall only use GIA when communicating with 1.4 TGs - GEA is effectively deprecated (of course a 1.4 TG may see a GEA from a legacy CT). I believe it would assist media players if these operations were multiplexed through one API to hide their underlying differences. It would be annoying for players to have to implement two callbacks to process these two similar operations.
This may change (decrease?) your complexity for these.
Cheers
Tim
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
> I guess for all people that are interested in AVRCP 1.4 we can start
> adding items to TODO list, to make it easier to share development
> between us. Since this may be too much to handle in a single global
> TODO maybe we can have a separated file like audio/TODO.
>
Somehow I was unable to send the file with TODO list for AVRCP 1.4
So I have copied here for initial feedback from all.
If this needs any modifications please let me know and I would come
back with updates asap.
Background
==========
- Priority scale: High, Medium and Low
- Complexity scale: C1, C2, C4 and C8. The complexity scale is exponential,
with complexity 1 being the lowest complexity. Complexity is a function
of both task 'complexity' and task 'scope'.
The general rule of thumb is that a complexity 1 task should take 1-2 weeks
for a person very familiar with BlueZ codebase. Higher complexity tasks
require more time and have higher uncertainty.
Higher complexity tasks should be refined into several lower complexity tasks
once the task is better understood.
AVRCP 1.4
==========
- Add SDP record for AVRCP 1.4 to inform CT of the version and features
supported by target.
Priority: Medium
Complexity: C1
- Add callback to accept browsing channel establishment.
Priority: Medium
Complexity: C1
- Enhancing bt_io_listen for browsing PSM
Priority: Medium
Complexity: C2
- Features to be added
All below mentioned features will have
Priority: Medium
Complexity: C2
As per spec section 6.4.1 GetCapabilities
As per spec section 6.5.1 ListPlayerApplicationSettingAttributes
As per spec section 6.5.2 ListPlayerApplicationSettingValues
As per spec section 6.5.3 GetCurrentPlayerApplicationSettingValue
As per spec section 6.5.4 SetPlayerApplicationSettingValue
As per spec section 6.5.5 GetPlayerApplicationSettingAttributeText
As per spec section 6.5.6 GetPlayerApplicationSettingValueText
As per spec section 6.5.7 InformDisplayableCharacterSet
As per spec section 6.5.8 InformBatteryStatusOfCT
As per spec section 6.6.1 GetElementAttributes
As per spec section 6.7.1 GetPlayStatus
As per spec section 6.7.2 RegisterNotification
As per spec section 6.8.1 RequestContinuingResponse
As per spec section 6.8.2 AbortContinuingResponse
As per spec section 6.9.1 SetAddressedPlayer
As per spec section 6.9.2 Addressed Player Changed Notification
As per spec section 6.9.3 SetBrowsedPlayer
As per spec section 6.9.4 Available Players Changed Notification
As per spec section 6.9.5 Notify Now Playing Content Changed
As per spec section 6.10.3.3 UIDs Changed Notification
As per spec section 6.10.4.1 ChangePath
As per spec section 6.10.4.2 GetFolderItems
As per spec section 6.10.4.3 GetItemAttributes
As per spec section 6.12.1 PlayItem
As per spec section 6.13.1 Absolute Volume
As per spec section 6.13.3 Notify volume change
On Tue, Dec 7, 2010 at 3:52 PM, <[email protected]> wrote:
>
> Hi Shivendra,
>
> > AVRCP 1.4
> > ==========
> >
> > - Add SDP record for AVRCP 1.4 to inform CT of the version and features
> > ? supported by target.
> >
> > ? Priority: Medium
> > ? Complexity: C1
>
> One extra issue here is that the SDP record needs to vary according to the players running: if the AVRCP layer statically set the AVRCP version in the SDP record to be 1.4, AND the player(s) was a legacy pre-1.4 application that did not know about browsing then the device integrator would have compliance issues.
>
> So I believe there is a need for an API that the player would set if it can support mandatory v.1.4 target features. ?If the API is not called (eg by backwards compatibility) then the SDP record would continue to publish version 1.3.
As I understand from AVRCP Spec 1.4 section 6.10.2.1 SDP record is
used as to indicate what the avrcp profile implementation is capable
of supporting. The Player Feature Bitmask provides information on the
capabilities of specific player. So Even if you Publish 1.4 SDP
Record, depending on the player/s registed the capability is exposed.
>
> This may increase your complexity value.
>
> > ? ? ? ? ? ? ? As per spec section 6.6.1 ? ? GetElementAttributes
> > ? ? ? ? ? ? ? As per spec section 6.10.4.3 ? ?GetItemAttributes
>
> Note that by overall spec design these are very similar. ?Indeed, according to 6.10.4.3, AVRCP 1.4 CTs shall only use GIA when communicating with 1.4 TGs - GEA is effectively deprecated (of course a 1.4 TG may see a GEA from a legacy CT). ?I believe it would assist media players if these operations were multiplexed through one API to hide their underlying differences. ?It would be annoying for players to have to implement two callbacks to process these two similar operations.
>
> This may change (decrease?) your complexity for these.
>
>
> Cheers
>
> Tim
>
>
> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. ?If you have received it in error, please notify the sender immediately and delete the original. ?Any other use of the email by you is prohibited.
> --
> 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
Regards
Santhosh AJ