CC2564C: low latency A2DP audio

Humm.. In general a2dp is a streaming service so, latencies should not be a problem. IMO, around 100 msec end to end is acceptable.

Do, you see any retransmissions of the data packets on the air? Are, you using 'HCI_Flow_Specification' command for the a2dp acl connections? Please try with 'Best Effort' for service type..

Thanks

Hi Hari,

The 100ms is just for the CC2564 - not end to end.  The other end is adding about 50-80ms of latency, which makes a total of 150 to 180ms of delay for the system.  This is borderline for audio synchronization with video - which is my use case.  I have TV audio flowing into a Cypress BT module controlled by a Linux system which then gets transmitted over A2DP to the CC2564 for output to speakers.  I have a hard time believing the Linux system can outperform the CC2564 in terms of latency.  

Are you saying there is no way to adjust or lower this delay through the CC2564?  I need to be able to explain this 100ms.  Articles I've read (such as this one: http://searanllc.com/audio-latency-using-sbc-codec/) seem to indicate that SBC is pretty low latency and that delays less than 50ms are possible.

While I wait for your reply, I will try to suggestions you gave to see if this improves things.

Jason

Changing the service type to "Best Effort" does not seem to have an impact on latency.  Consistently measuring 100-120ms of latency from in-air packet to speaker output.  MAX9880A codec datasheet specifies worst case latency of 1.2ms for 8kHz sample rate from digital inputs to analog output and only lessens as sample rate increases.  There is no other significant device in the audio path.  

Hi Jason,

100 ms just across the controller is on higher side. Since, you are using assisted mode, the the mSBC decoder on the AVPR co-processors (dedicated CM3 for audio) comes into play to decode and send samples on the PCM bus. Is the sample rates on the PCM and air i/f matching. If not the rate conversion may add few ms. 

How are you measuring the latency across the controller? Can, you also take FW logs to check if there are any issues..

Thanks

Hari,

I have an Ellisys Vanguard analyzer and oscilloscope. 

To measure overall latency, I use the oscilloscope by placing one probe on the analog audio input to the system (line in) and one probe on the analog output of the system (speakers).  I then drive a full-scale sine wave to the line in and measure the delay using the scope to the output of that sine wave on the speakers.  Going from silence to a full-scale sine wave provides a nice trigger point for the scope to take a measurement.

I use the Ellisys analyzer to pinpoint the audio packets in-air.  I have the same analog input (full scan sine wave) connected to my Ellisys, so I can measure the delay from the start of the analog sine wave to the audio packet containing the start of the sine wave.  This gives me the latency of my front-end system.

Subtracting that front-end latency from the overall latency gives me the latency of the back-end system (which has the CC2654).  All that is in the audio path is the CC2654 and a MAX9880A codec.

Can you please provide instructions on getting the FW logs?  I should probably mention that this CC2564 is part of an integrated module from BDE (BDM209A) which combines the CC2564C and an MSP432 in one module - so I don't have access to all the pins of the CC2564.

Jason

Please check this doc for logger details: https://www.ti.com/lit/pdf/swau058

Thanks