CC2564C: mSBC over HCI packets getting corrupted.

Hi TI,

We collected some more data on the issue. See if this helps.

Some issues with the buffer pointer we get from the HFRE_AudioDataIndication.

The original valid data seems to be offseted by some length from the pointer we get .

Example:

The data given below, shows the first three bytes of the pointer we get from  HFRE_AudioDataIndication when Packet is valid.

The data given below is when the issue occurs. In the data, you can see that the packets seem to be offset by 2 bytes.

* (in the above table(red)  data is taken only when decode fails, don't consider that as consecutive packets).

mSBC headers normally start with  0x01 followed by sequence number (0x08, 0x38, 0xC8, 0xF8). likewise.

In the above(table in red), we can see that the mSBC header is offset by 2 bytes.

Over time we observed that the offset is changing to 4,6,8,10,........ etc.

when we try to do the Pointer offset and decode the data, then the system has some immunity, and we are able to decode the packet (no guarantee the whole data is correct, but still the audio quality was fine.)

If the offset goes above 6, the quality is going bad(intermittent audio or robotic voice). If it enters into this error then we had to cut and make the call again to the phones.

Regards,

Vishnu

HI Ti,

Any update on this?

I have one more update.

We are observing this issue more on Samsung phones and some iPhones also.

Regards,

Vishnu

Hi Jacob,

I am adding the replies below.

1) Do you receive an error code in the Bluetopia stack? How do you know when the decoding is failing?  

Reply : When the decode is failing I won't get the  SBC_PROCESSING_COMPLETE  as the return from  "SBC_Decode_Data()" function. Instead we will get  SBC_PROCESSING_DATA.

And this issue we are seeing specifically on some phones (Samsung Galaxy J6, Iphone 12 pro, etc).  When the issue happens we can see that the sync word (0xAD) is getting offset by factors of 2. That is what I have shown in the table above, Even though I have taken the starting of the packet as a reference to point to the offset.(Before 0xAD there are 2 headers   | 1:0x01 | 2:Seq (0x08, 0x38, 0xC8, 0xF8) | . 

2) Is this related to a specific event during poor audio quality (i.e. connecting to BLE)?

Reply :  No, it is not specific to any events. it's completely random and very reliably reproducible on some phones. For most of the other phones Redmi, Oneplus, etc we are not observing this issue. 

3)Here is what I found from the HFP spec on mSBC header format:

Reply : Yes, Jacob. We are aware of these Sync Word and how the headers of the mSBC is decided etc.

Here we are seeing a fundamental problem of the packet headers being offset from the pointer we get from the HFRE_AudioDataIndication event. (the packetstatus says that it is a valid packet) . That is what we need the answer for.

Regards,

Vishnu

Also,

We like to know with what finding the following thread was closed.

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/789132/cc2564c-corrupted-msbc-data-seen-with-voice-over-hci .

There are some communications that happened over mail for that thread. We are not able to find that information. If you can get that information, that will be great.

Thanks!

Vishnu

Hello Jacob,

We are able to get the phone calls to work reliably on a majority of phones, and have collected the data on the errant phones so we can get specific assistance from the TI team. May I please request you to carefully read through the data that Vishnu has shared (please also consider looking at the other e2e thread that we have shared), and let us know how we can fix this issue.

Many thanks!

Hi Sundararajan,

I need to ask another clarification question: are you using WBS? I'm also sharing some documentation about audio features on the CC2564C here.

CC256x Advanced Voice and Audio Features - Texas Instruments Wiki.pdf

Best,
Jacob

Hi Jacob,

Jacob B. said:

I need to ask another clarification question: are you using WBS?

Yes, We are using WBS in unassisted mode ( that is data taken over HCI and decoders and encoders are running on a separate MCU(STM32F4) not on the assisted mode supported by CC2564C ).

Regards,

Vishnu

Hi Jacob

Please advise on what else we can try to fix this issue? thanks!

Hi Sundararajan,

Can you take firmware and HCI logs capturing the audio initialization event and issue you describe above?

Best,
Jacob