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.

CC2564C: Audio issues in HFP when the CC2564C receive audio from Bluetooth

Part Number: CC2564C
Other Parts Discussed in Thread: CC2564


We are integrating in our design the CC2564C through the PAN 1326 with an IMX 6ULL with Bluez and BlueAlsa.

We are using the SPP, PAN and HFP profiles. The CC2564C is configured to send and receive the SCO packets through the HCI interface (we are not using the PCM interface.) 

On this point it seems by reading other post that the HCI interface is not recommended to use with SCO.

Can you confirm to us that even if it is not recommended, it is fully supported ? 

We are experiencing multiple audio issues but all issues are seen only on the path : Bluetooth -> CC2564C -> HCI -> HOST (The issues are not seen on the opposite path) 

Issue 1 : Audio Latency increasing

By default the audio is working properly, "randomly" after few seconds we observes that the audio seem to be played at half its normal frequency (so the latency increase).

It seems that when this issue occurs the following log appears "Erroneous Data - No Data Received" on the TX Debug pin

We have tried to configure the CC2564C with the vendor specific command to "refuse bad crc" Sco packet, in this case we see with a BTMON capture that a lot of SCO packet are missing for example during a Pan transfer. 

Questions : 

  • Why does the CC2564C seem to be missing packets? 
  • Do we overload it with our usage of multiple Bluetooth profile ? 
  • What does the "Erroneous Data - No Data Received" error means ? 

Issue 2 : The sound seems to "saturate"

When we send a "high" level audio signal from Bluetooth to the CC2564c, the audio send to the Host seems to saturate even after the "high" level audio signal is not send anymore. 

Question : 

  • What can be the effect of this behavior ? 
  • Is there some parameters that we can use to affect this behavior ?

Logs :  Please find attached the log captured through the TX debug pin


  • PCM should be used for synchronous transfers.  If HCI is used, you will run the risk of poor quality audio.  What is the usecase for your application?  Does the HFP data need to be routed to the host, or is it an application like phone to headset?  PCM loopback may be an option here if that is the case.  I'll have one of our device experts jump in with further feedback.



  • Hello, 

    Thanks for your reply. 

    From this part of your reply "PCM should be used for synchronous transfers.  If HCI is used, you will run the risk of poor quality audio.", i understand that the SCO over HCI is not officially supported, is it right? 

    Can we still hope to make the SCO over HCI work ?

    Our use case is that the CC2564C is integrated in a device that act as a "converter" for audio, serial, and IP between physical interface and a Bluetooth interface. In this use case our devices acts as an headset regarding the HFP roles. 

    In the design of our device the CC2564c is connected directly to an HOST and the PCM pin of the CC2564c are not populated as we though both PCM and HCI is supported for SCO. Then the host output the audio to analog interface via an codec component.

    We design the Host in between the Bluetooth component and the codec also because we wanted to output on the codec sound from other source that Bluetooth. ( this is why we did not connect directly the Bluetooth Component PCM pin to a Codec.)

    You are referring to the PCM loopback function of the CC2564c, 

    • How will this function work in our use case?
      • Is it a SCO loopback or a PCM loopback? 
      • Will it loopback SCO other HCI ?
    • Does this mean that the HCI vendor specific command to configure the PCM codec of the CC2564c also has an effect on the SCO over HCI?  

    We look forward the feedback of your device experts.



  • As, Travis mentioned PCM is the recommended interface for SCO connections. 

    The PCM loopback is to loopback the PCM interface from host back to itself. i.e TX from host is looped back to RX to the host.

    What is the HCI/UART baud rate? If it is below 3Mbps, please try at 3Mbps. In addition to the SCO connection, do you have any other active connections? (especially connections with data transfers) This can chew up the HCI buffers and lead to lack of buffer for SCO transfers. It seems, you have not taken the FW logs with HCI/LMP viewer enabled, so it not clear if it is a SCO or eSCO connection and if it NB or WB. WB would need more buffer bandwidth. 


  • This is the characteristics of our usage of the CC2564c:

    • HCI / Uart baud rate: 3Mbps (we have tested at 4 Mbps but with no improvement)
    • PCM/ I2S capacity : not used 
    • we are redirecting SCO to UART with the command HCI_VS_Write_SCO_Configuration (0xFE10) , with the following parameters :
      • Connection type = 1 ((HOST)
      • TX Buffer Size = 120 bytes
      • TX Buffer Max latency = 4* 120 bytes
      • Accept Packet with bad CRC = 1 (Accept)
    • The HFP audio caracteristics are : 
      • eSCO
      • CSVD
    • Bluetooth profiles used simultaneously : HFP, SPP (Serial port profiles) and PAN (Personal area network

    Did the FW logs with HCI/LMP viewer are also retrieve from the TX_DEBUG pin ? or are they retrieve from the HCI uart? 

  • Yes, the HCI/LMP viewer messages are enabled in the logger and retrieved through TX_DEBUG pin.

    Please, see Fig10 in the below document:


  • Hello, 

    We have been to make a new prototype which use the PCM interface instead of the HCI interface for audio transfer. 

    It's clear that the HCI interface is not working properly, I really think that you should clarify that the HCI interface is not suitable for audio transfer. 

    So we will switch to the PCM interface. 

    When doing test with the PCM interface and by sending data over PAN (HCI) at the same time we have captured the log via the TX Debug Pin of the CC2564 and we have notice the following log "ACL: not enough time to schedule" what does this log means ? 

    Please find attached the lgr capture.

  • We will review the FW logs. So, did you get the PCM interface voice/audio working?


  • Hello, 

    Yes we have been able to get the PCM interface working properly. 

    We look toward your review of the FW logs. 


  • From the logs it appears there is quite a bit AFH channel assessment and channel map updates. How is the radio environment? The log message it self is not fatal, it says it is not able to schedule a ACL scheduling a couple of times.. This may likely result in re-transmission.. Did, you try disabling Inquiry and page scans, after the SCO connection?