Hi Jason, > I placed one call, and everything worked (audio in out of the computer). I've > been able to get this to happen once in a while. > I disconnect the call from the phone. I placed a second call, there wasn't > any audio, and my logs scroll like this: > [ 1052.809382] Bluetooth: hci0 SCO packet for unknown connection handle 2 > [ 1052.809964] Bluetooth: hci0 SCO packet for unknown connection handle 16384 > [ 1052.810563] Bluetooth: hci0 SCO packet for unknown connection handle 48 > [ 1052.811371] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.811982] Bluetooth: hci0 SCO packet for unknown connection handle 256 > [ 1052.812581] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.813378] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.813968] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.814712] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.815681] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.816536] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.817712] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.818544] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.819508] Bluetooth: hci0 SCO packet for unknown connection handle 1 > [ 1052.820332] Bluetooth: hci0 SCO packet for unknown connection handle 1
Messages "SCO packet for unknown connection handle" at SCO creation are produced when there is an issue in packet reassembly. It basically means that the driver failed to assemble USB packet into SCO packets and what is pushed up is not audio but garbage. When this is printed continuously on the console, it means you are not going to have any audio, until it stops. Most common cause is that there is a fragment of SCO packet cached in the driver. Controller usually fragment packets into 3 parts, that the kernel needs to put together and create one SCO packet that is forwarded to upper layers. On connection close a fragment may be left in the driver. When another call is established, this fragment is going to be used, and further fragments are going to be attached to it. You are using kernel 3.16, which has certain guards removed (that are in older kernels), that would help the kernel to quickly recover from this issue. I've made a patch for this issue. It's already in Bluetooth-next tree and was merged to linux-next. It is not yet in any official kernel. It removes any leftover fragments that are there between SCO connections. If you are able to compile you own kernel then add this commit: http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=8f9d02f470f48416444ac3a1eacecdd0f743f1a7 Also note that SCO handling is a bit buggy in the kernel. I'm now pursuing few crashes at SCO creation and disconnection. Kuba Pawlak Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul Chairperson of the Supervisory Board: Tiffany Doon Silva Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 _______________________________________________ ofono mailing list [email protected] https://lists.ofono.org/mailman/listinfo/ofono
