Hi All,
During the interop tests with BMW Carkit using DUT (Device under Test)
running Bluez stack, we observe that A2DP reconfiguration timeouts.
Scenario:
1) Connect A2DP from DUT
2) Start streaming
3) Power down the BMW carkit
4) Power on the BMW carkit
5) A2DP streaming not resuming.
>From the sniffer logs, firstly we observe that the BMW carkit supports
multiple stream endpoints whereas the DUT supports only one. We observe
that after powering on, the BMW carkit(CK) was initiating an inbound A2DP
connection there by configuring the stream (INT and ACP SEID were 1 for
set configuration). Later on we observe that the DUT tries to reconfigure
the stream by sending a AVDTP_CLOSE as the stream had capabilities
differing from the remote device (CK in this case). The BMW CK rightly
acknowledges the AVDTP_CLOSE (here ACP SEID = 1). Following this the DUT
sends a stream configuration with INT SEID as 1 and ACP SEID as 2. To this
the remote CK doesn't respond.
We suspect this behaviour because the set configuration lastly send from
the DUT after an AVDTP_CLOSE should have been with ACP SEID as 1 and not
2. As per our understanding of the code, 2 is used as the ACP SEID because
avdtp_get_seps returns the 1st not in use SEP from the list that was
contructed based on the device capabalities retreived by the DUT from the
remote CK. It is observed that the DISCOVER response from the remote CK
provided SEID 2 info before 1.
Change expected:
avdtp_get_seps should be able to provide the SEP of the one used in the
AVDTP_CLOSE previously. But there weren't any previously closed streams
then provide the SEP which is not in use (as done currently).
Kindly let us know whether our understanding is right and can this be a
suspected cause of the issue seen. Correct if mistaken.
Regards,
Royston Rodrigues
Hi Luiz,
On Fri, Dec 10, 2010, Luiz Augusto von Dentz wrote:
> I guess it would be better to have the call to
> avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
> there and less code too, but the fix is probably right.
Good point. Attach is a patch which does this. Could we now please get
some feedback from the reporter if this really helps? :)
Johan
Hi,
On Thu, Dec 9, 2010 at 4:41 PM, Johan Hedberg <[email protected]> wrote:
> Hi Royston,
>
> On Thu, Dec 09, 2010, [email protected] wrote:
>> Change expected:
>> avdtp_get_seps should be able to provide the SEP of the one used in the
>> AVDTP_CLOSE previously. But there weren't any previously closed streams
>> then provide the SEP which is not in use (as done currently).
>>
>> Kindly let us know whether our understanding is right and can this be a
>> suspected cause of the issue seen. Correct if mistaken.
>
> Sounds like that might be the cause. Have you experimented with patching
> the bluez code to reuse the same SEP as was used for the Close? If not
> I'd advice you to do that so we can be sure that a change to the ACP SEP
> selection logic makes sense.
>
> Right now the reconfiguration happens in audio/a2dp.c where there's a
> setup->reconfigure flag to track if a new stream should be configured
> after receiving close_ind. The a2dp_reconfigure function in a2dp.c is
> responsible for selecting the remote SEP. Could you try the attached
> (completely untested) patch to see if it helps? It stores the old remote
> SEP in the setup structure when starting the Close procedure in which
> case a2dp_reconfigure() shouldn't try to reselect a new remote SEP but
> use the stored one instead.
I guess it would be better to have the call to
avdtp_stream_get_remote_sep on close_cfm, it is probably safer to do
there and less code too, but the fix is probably right.
--
Luiz Augusto von Dentz
Computer Engineer
Hi Royston,
On Thu, Dec 09, 2010, [email protected] wrote:
> Change expected:
> avdtp_get_seps should be able to provide the SEP of the one used in the
> AVDTP_CLOSE previously. But there weren't any previously closed streams
> then provide the SEP which is not in use (as done currently).
>
> Kindly let us know whether our understanding is right and can this be a
> suspected cause of the issue seen. Correct if mistaken.
Sounds like that might be the cause. Have you experimented with patching
the bluez code to reuse the same SEP as was used for the Close? If not
I'd advice you to do that so we can be sure that a change to the ACP SEP
selection logic makes sense.
Right now the reconfiguration happens in audio/a2dp.c where there's a
setup->reconfigure flag to track if a new stream should be configured
after receiving close_ind. The a2dp_reconfigure function in a2dp.c is
responsible for selecting the remote SEP. Could you try the attached
(completely untested) patch to see if it helps? It stores the old remote
SEP in the setup structure when starting the Close procedure in which
case a2dp_reconfigure() shouldn't try to reselect a new remote SEP but
use the stored one instead.
Johan
Hi Henrik,
On Tue, Feb 08, 2011, H?glind, Henrik wrote:
> Hi Lukasz, Roystonr, Johan,
>
> >> Have provided the patch to the tester to verify as we don't have the BMW
> >> CK available locally. Would update the feedback received.
> >
> >I'm just wondering, Is it working for you ?
>
> We have been testing this patch and it fixes the problem.
Thanks for the confirmation. I've now pushed a patch for this upstream.
Johan
Hi Lukasz, Roystonr, Johan,
>> Have provided the patch to the tester to verify as we don't have the BMW
>> CK available locally. Would update the feedback received.
>
>I'm just wondering, Is it working for you ?
We have been testing this patch and it fixes the problem.
Best regards,
Henrik