Hi,
Went through the archives, don't see this being discussed.
I read the AVRCPv1.3 spec section mentioned below and to me it looks
like it's been implemented the way it is supposed to be, However, the
question is WHY ?
/* Unregister event as per AVRCP 1.3 spec, section 5.4.2 */
player->registered_events ^= 1 << id;
Does that mean - A car-kit product would keep asking for new
notifications time and again ? That too, It needs to be requesting for
notification for each individual EVENT_ID again and again ? Since 1
notification request is good for 1 notification & for 1 particular
event ?
Wouldn't this make the devices more chatty then they are supposed to
be? Why not enable/disable notifications - And capability to OR
various event IDs ?
Thanks & Regards,
Pavan Savoy.
Hi Pavan
On Sun, Jul 22, 2012 at 5:07 AM, Pavan Savoy <[email protected]> wrote:
> Now, I am interested to know whether the "Playing" needs to be
> displayed or something like "Paused" along with another bit of info,
> which is My-Song.
> So, say to begin with I register for track-changed notification, now
> to read the attributes of song again, but If I have to display
> "Paused" then I will have to register for "Play Status" & I can get
> only 1 of them at a time ?
You can register multiple events simultaneously, the only problem is
that you need to register again every time it changes. Apparently this
idea of registration not being persistent came from AV/C spec, while
doing support for VolumeChanged event I actually step in it see patch:
AVRCP: Fix not registering to VolumeChanged event again when notified
Its pretty broken design if you ask me, but one that we have to live with...
On Sat, Jul 21, 2012 at 11:45 AM, Lucas De Marchi
<[email protected]> wrote:
> Hi Pavan,
>
> On Fri, Jul 20, 2012 at 5:39 PM, Pavan Savoy <[email protected]> wrote:
>> Hi,
>>
>> Went through the archives, don't see this being discussed.
>> I read the AVRCPv1.3 spec section mentioned below and to me it looks
>> like it's been implemented the way it is supposed to be, However, the
>> question is WHY ?
>>
>> /* Unregister event as per AVRCP 1.3 spec, section 5.4.2 */
>> player->registered_events ^= 1 << id;
>>
>> Does that mean - A car-kit product would keep asking for new
>> notifications time and again ? That too, It needs to be requesting for
>> notification for each individual EVENT_ID again and again ? Since 1
>> notification request is good for 1 notification & for 1 particular
>> event ?
>
> Yes, TG side can't send an event CT was not registered to. And that
> means we have to remove the registered event after it has been
> generated. It's indeed not well designed IMO, but it is what other
> devices are supposed to implement. Once they receive a notification,
> if they are still interested in a certain even, they register again to
> that event. It's racy, but devices out there use it expecting this
> behavior.
>
>>
>> Wouldn't this make the devices more chatty then they are supposed to
>> be? Why not enable/disable notifications - And capability to OR
>> various event IDs ?
>
> Not sure I understand what you mean here.
What I meant here is If I design a car-kit in which I plan to display say,
"Playing My-Song"
Now, I am interested to know whether the "Playing" needs to be
displayed or something like "Paused" along with another bit of info,
which is My-Song.
So, say to begin with I register for track-changed notification, now
to read the attributes of song again, but If I have to display
"Paused" then I will have to register for "Play Status" & I can get
only 1 of them at a time ?
I wonder how it should be implemented that's all..
>
> Lucas De Marchi
Hi Pavan,
On Fri, Jul 20, 2012 at 5:39 PM, Pavan Savoy <[email protected]> wrote:
> Hi,
>
> Went through the archives, don't see this being discussed.
> I read the AVRCPv1.3 spec section mentioned below and to me it looks
> like it's been implemented the way it is supposed to be, However, the
> question is WHY ?
>
> /* Unregister event as per AVRCP 1.3 spec, section 5.4.2 */
> player->registered_events ^= 1 << id;
>
> Does that mean - A car-kit product would keep asking for new
> notifications time and again ? That too, It needs to be requesting for
> notification for each individual EVENT_ID again and again ? Since 1
> notification request is good for 1 notification & for 1 particular
> event ?
Yes, TG side can't send an event CT was not registered to. And that
means we have to remove the registered event after it has been
generated. It's indeed not well designed IMO, but it is what other
devices are supposed to implement. Once they receive a notification,
if they are still interested in a certain even, they register again to
that event. It's racy, but devices out there use it expecting this
behavior.
>
> Wouldn't this make the devices more chatty then they are supposed to
> be? Why not enable/disable notifications - And capability to OR
> various event IDs ?
Not sure I understand what you mean here.
Lucas De Marchi