Hi, Preface: all this stuff doesn't apply to A2DP (high-quality uni-directional sound playback), it works over USB HCI regardless of routing configuration.
Following information is based on AN107 [1] (CSR, 2002, describes SCO configuration for BC-01b and BC-02-External) and experience. Our devices are using a more recent version, BlueCore4-ROM, with firmware build name "odj_4hci_rom_bt2.0_19p2_0503071059_encr128 2005-03-07". The chip name suggests that we can't upgrade firmware via DFU so we'll have to live with that one anyway. Still this chip has some EEPROM area where various parameters are stored (called "ps keys" for some reason). How it works now: currently all CSR chips (BT adapters) installed on freerunners and gta01s (based on a small IRC survey) are pre-configured to route SCO data over PCM interface, connected to the WM8753's BT DAI. This allows to use BT headsets for GSM calls provided a reasonable routing inside WM8753 is used. This was tested and works. Alas there're some usecases where this scheme can't be employed, notably using BT headset for VoIP. Also one may want to use his BT earpiece to do voicenotes or recording his GSM conversations. There are probably much more possibilities where routing SCO over HCI can be desired. One may argue that tricky routing inside WM8753 can give SoC access to the signal, but as far as i understand (and that was confirmed in discussions with Joerg) that is not possible given hardware we have. What i tried: Installed bluez 4.30 on my laptop with a broadcom bluetooth chip. Paired with a cheap bluetooth earpiece using simple-agent from test. Tried to play a test wav (8000 Hz, S16_LE, mono) with hstest. It worked, that is the headset connected and i heard the sound i expected. Then i compiled the same bluez version on freerunner and repeated the procedure. Got no sound and sco packet counter (seen in hciconfig -a output) didn't increase. hciconfig hci0 revision showed "SCO mapping: PCM", that was obviously not what i expected. To change that bccmd psset mapsco 0 is supposed to work, but for unknown reasons it didn't. So i added csr_write_pskey_uint16(dd, 4, CSR_PSKEY_HOSTIO_MAP_SCO_PCM, 0x0000, 0); call to hciconfig instead and run it once. After that this setting permanently changed to "SCO mapping: HCI". Power-cycled the chip and after that the sco counters started to grow. Still i got no sound (though everything else seemed to work as expected). I gathered debug logs from bluetoothd and hcidump for both cases (working laptop and not-working freerunner) and contacted Johan Hedberg of BlueZ project. He said he found no oddities in FR's log and that it should work. Also he ensured me that we can issue any HCI commands without bluetoothd interfering, that will be needed if we finally get HCI routing to work to temporarily switch to PCM (according to the AN). To the best of my knowledge this SCO routing behaviour is not only chip-specific, but also firmware-specific, so i can't see how to move any further now. The logs are accessible from [2]. [1] http://case.cs.mnsu.edu/NSM%20Technology/141_HCI%20Implementation%20on%20BlueCore%20(AN107d).pdf [2] http://people.openmoko.org/joerg/PaulFerster/ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[email protected] _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
