This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2564MODN: Simultaneous Hands-Free Profile (HFP) and Bluetooth Low Energy (BLE) causes audio bilps and pops

Part Number: CC2564MODN

I am developing an application that requires the use of both the Hands Free Profile and Bluetooth Low Energy GATT server simultaneously. Currently, we are able to connect our product, which includes a CC256x chip, with both HFP and BLE to the same smartphone at the same time. However, I have noticed an issue that crops up when both connections are active at the same time.

The audio stream has very frequent blips and pops (perhaps 10-15 per second). From testing, we can reduce these blips by increasing the BLE maximum connection length using the BluetopiaPM function DEVM_Set_And_Update_Connection_And_Scan_Parameters(). Unfortunately, when we increase the BLE maximum connection time, even from the default 45 ms to just 150 ms, the BLE GATT latency increases dramatically. Reading or writing a single GATT characteristic composed of a single byte of data takes about 3 seconds.

     

    Here are some details about our setup that may be useful for you:

    • We are streaming the audio data to the CC256x chip using PCM at 8 ksps. Each sample is 16 bits, and we are using both the input and output data from a single channel (i.e. a bidirectional monaural stream).
    • We are using the CVSD codec for the HFP stream. The CC256x chip is handling the encoding and decoding of the CVSD data, which I believe is done on the CC256x coprocessor unit. Unless I'm mistaken, I think the BLE GATT transactions are also handled by the coprocessor.
    • We are using encrypted BLE transmissions (i.e. only paired devices may read/write the GATT characteristics). Would the encryption be adding additional strain to the CC256x coprocessor?

     

    Is it possible to reduce the blips of the HFP stream while also reducing the BLE latency? I suspect the CC256x's coprocessor might be overtaxed when in HFP + BLE mode. Is there a way we can reduce its load or increase its performance? Several possibilities that I would like some advice about are: increasing the coprocessor's clock rate, decreasing the CVSD bits-per-sample to reduce computational complexity, offloading the HFP CVSD processing to an external DSP (could we still use PCM to transmit the unprocessed CVSD data to the DSP, or do we have to use the Bluetooth HCI UART connection for this?).

     

    Any advice or direction you could provide to address these issues would be greatly appreciated.

     

    Thanks.