Original patch by Chan-yeol Park <[email protected]>
While the streaming is in progress, the remote headset is capable
of buffering audio packets. When it buffered the more audio
packets, we are sending the SUSPEND command before initiating
sco connection. Some headset is able to process the SUSPEND
command only after processing the buffered audio packets, hence
the delay in the response. So in this case, increasing the
REQ_TIMEOUT from 6 to 10 will solve the issue.
---
audio/avdtp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/audio/avdtp.c b/audio/avdtp.c
index d3568ba..474c446 100644
--- a/audio/avdtp.c
+++ b/audio/avdtp.c
@@ -89,7 +89,7 @@
#define AVDTP_MSG_TYPE_ACCEPT 0x02
#define AVDTP_MSG_TYPE_REJECT 0x03
-#define REQ_TIMEOUT 6
+#define REQ_TIMEOUT 10
#define ABORT_TIMEOUT 2
#define DISCONNECT_TIMEOUT 1
#define STREAM_TIMEOUT 20
--
1.7.5.4
Hi Chethan,
On Wed, Dec 28, 2011 at 9:08 AM, Chethan T N <[email protected]> wrote:
> Original patch by Chan-yeol Park <[email protected]>
>
> While the streaming is in progress, the remote headset is capable
> of buffering audio packets. When it buffered the more audio
> packets, we are sending the SUSPEND command before initiating
> sco connection. Some headset is able to process the SUSPEND
> command only after processing the buffered audio packets, hence
> the delay in the response. So in this case, increasing the
> REQ_TIMEOUT from 6 to 10 will solve the issue.
What model does that? This use case is exactly when we need to proceed
fast to switch profiles because in between there wont be any route to
the audio and a lot of things can happen during 10 seconds. Now I
don't know what is going on in the headset side but it seems it should
be dropping the remaining buffered packets if a call is alerting/SCO
is needed, in that case it might be better/faster to just drop the
avdtp connection and reconnect forcing the headset to drop everything.
--
Luiz Augusto von Dentz
Hi,
--------------------------------------------------
From: "Luiz Augusto von Dentz" <[email protected]>
Sent: Wednesday, December 28, 2011 3:10 PM
To: "Chethan T N" <[email protected]>
Cc: <[email protected]>
Subject: Re: [PATCH] audio: Increased AVDTP request timeout
> Hi Chethan,
>
> On Wed, Dec 28, 2011 at 9:08 AM, Chethan T N <[email protected]>
> wrote:
>> Original patch by Chan-yeol Park <[email protected]>
>>
>> While the streaming is in progress, the remote headset is capable
>> of buffering audio packets. When it buffered the more audio
>> packets, we are sending the SUSPEND command before initiating
>> sco connection. Some headset is able to process the SUSPEND
>> command only after processing the buffered audio packets, hence
>> the delay in the response. So in this case, increasing the
>> REQ_TIMEOUT from 6 to 10 will solve the issue.
>
> What model does that? This use case is exactly when we need to proceed
> fast to switch profiles because in between there wont be any route to
> the audio and a lot of things can happen during 10 seconds. Now I
> don't know what is going on in the headset side but it seems it should
> be dropping the remaining buffered packets if a call is alerting/SCO
> is needed, in that case it might be better/faster to just drop the
> avdtp connection and reconnect forcing the headset to drop everything.
>
> --
> Luiz Augusto von Dentz
As mentioned the issue in the above mail, I could reproduce the issue with
Samsung SBH650 bluetooth stereo headset. I have pasted the complete log
in the below mentioned link.
http://pastebin.com/UF6KzTDF
After increasing the REQ_TIMEOUT from 6 to 10 the problem got resolved.
However as per you suggestion "drop the avdtp connection and reconnect
forcing the headset to drop everything", which is the right place to
re-initiate
connection "bluetoothd" or "application"?.
If application need to re-initiate then it should know/understand the reason
for
disconnection before initiating the re-connection to the headset.
Thanks and Regards
Chethan
> --
> 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