Hi Suraj, On Thu, Jun 30, 2011, Sumangala, Suraj wrote: > Sometime ago we had a situation where we were testing a BT chip that > did NOT support SCO over HCI and supported only SCO over PCM. > > The problem was whenever SCO connection was made; my host (Ubuntu) > sent 2 or 3 SCO packets over HCI to the controller. The controller > could not handle these packets as it meant as only a SCO over PCM > device and crashed. > > So we had to drop the SCO packets in the HCI transport driver > explicitly. So, when we say in the configuration file that SCO is > over PCM should the stack make sure that no SCO packets are sent over > HCI? The user space part of BlueZ isn't actually responsible for sending any data over SCO at all. Instead this is the job of the audio subsystem (PulseAudio, GStreamer, ALSA, etc). If you have special hardware that only supports SCO over PCM you need to tell your audio subsystem about that. E.g. in PulseAudio there are parameters for giving an ALSA device to use for reading/writing the audio instead of using the SCO socket given by BlueZ. I.e. for a system where you have a dedicated PCM line to the controller you implement a kernel ALSA driver which abstracts this line to user space and then give the ALSA device exposed by that driver to PulseAudio (or whatever audio susbystem you might have). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
