bluetooth: synchronous sco disconnect
Henrik Höglind
We have a fair amount of IOT problems related sco connection
management. Typical
scenarios are resume music after call, and call audio transfer in the
phone app.
Typical errors are that start audio streaming or new sco connection is
rejected by
remote device.
I think the root cause of these issues is that sco disconnection is
asynchronous,
which leads to that the next activity (stream start or sco connect) is
done
"too early" in the sense that local stack, local hardware or remote
device is
not ready for the new activity.
I made an attempt to make the sco disconnection synchronous. It is
asynchronous
in two places, sco socket implementation in kernel and
android_bluetooth_ScoSocket in framework.
I applied the upstream patch for the kernel for sco socket shutdown.
http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-2.6.git;a=commit;h=0da67bed835fdde68ca0e924d2a2d6ac82c70833
I changed closeNative function to wait for an ack from the work_thread
when the
sco socket is closed. The work_thread sets SO_LINGER to wait for max
of 3
seconds for the sco to be shutdown.
I also changed the kernel so link will be set to active mode before
disconnecting sco (in a simliar fashion as is done for sco connects)
to get the
link state change to happen at a certain time, instead of relying on
the
automatic unsniff when acl packets (i.e. streaming start) packet is
sent.
That was needed to make the resume-streaming-after-call to work with
one IOT
device.
Behaviour differs depending on what hardware you are using, maybe
because they
handle acl data differently during link state and sco connection
transitions.
I am a bit concerned about the effects of blocking closeNative,
typically for
about a second, and worst case 3 seconds.
Any comments? Is worth contributing?
Best regards,
Henrik
Jaikumar Ganesh
The SCO socket code has been changed to use BluetoothSockets in
Honeycomb code base.
The audio system listens to the disconnection intent before starting
the A2DP streaming channel.
After these changes, the problem below shouldn't happen. We tested it
at UPF where older android phones were running into this problem with
headsets.
However, as this code change has happened in Honeycomb code base, for
phones it will be available in ice cream sandwich.
If you can't wait for the code to be open sourced, it might make sense
to implement the SCO part using BluetoothSocket. Since all the
Bluetooth Socket infrastructure is already there, this is a relatively
easy task.
> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>
>
Jaikumar Ganesh
upstream the SCO disconnect - active mode patch ?
Thanks
"Höglind, Henrik"
/Henrik
> > To unsubscribe from this group, send email to android-
> platform+u...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/android-platform?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-
> platform+u...@googlegroups.com.
"Höglind, Henrik"
I think changing to BluetoothSockets should solve the part of closeNative being asynchronous. But unless the kernel patch for sco shutdown is applied and the linger option is set, it should still be asynchronous.
My main concern is about the effects on middleware by blocking 1-2 seconds while waiting for sco disconnect completion.
> -----Original Message-----
> From: android-...@googlegroups.com [mailto:android-
> plat...@googlegroups.com] On Behalf Of Jaikumar Ganesh
> Sent: onsdag den 15 juni 2011 06:19
> To: android-...@googlegroups.com
> Subject: Re: bluetooth: synchronous sco disconnect
>
> > To unsubscribe from this group, send email to android-
> platform+u...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/android-platform?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-
> platform+u...@googlegroups.com.
Jaikumar Ganesh
<Henrik....@sonyericsson.com> wrote:
> It took some time before I got time to do this... :-(
>
> I think changing to BluetoothSockets should solve the part of closeNative being asynchronous. But unless the kernel patch for sco shutdown is applied and the linger option is set, it should still be asynchronous.
>
> My main concern is about the effects on middleware by blocking 1-2 seconds while waiting for sco disconnect completion.
All of that happens in a separate thread and not in the UI thread and
they are callbacks which inform the change in state.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.