Crackle/pop noise heard in HFP audio

Just tried service pack 1.3, I can't even perform an inquiry now, I get no response and no indication that anything has failed.

I am able to do things like set inquiry mode, voice setting, query Bluetooth address, etc, but the inquiry function appears to not do anything.

I will revert to the previous configuration and try running the CC256x as clock master.

I should have followed up on this sooner. As it so happens, the other hardware configuration I'm using the CC256x in does in fact exhibit the noise issue (I just hadn't noticed it before, and sometimes it comes and goes at random, I wasn't listening for long enough), so I tried some more things to try to narrow it down to whether it was the board design, or the PAN1326B, or the CC256x.

This included VS_PCM_Loopback_Enable during the SCO audio session to verify that the problem was not in the PCM audio. Silence in brought silence out, music in brought music out, test tones in brought test tones out, and there were no noticeable artifacts in the PCM audio coming out. What was interesting to note that even during this PCM loopback mode, the CC256x was still transmitting noisy audio to the headset, decoupled from whatever PCM audio was being put in (I presume that during the loopback test, the CVSD encoder on the chip is simply given 0s to munch on as opposed to samples from the incoming PCM?).

I did try with the CC256x as master of the I2S clock to no avail

I have tried even on the DK-TM4C129X with CC256xQFNEM, using HFPAGDemo, and the noise is still present

Here's where things start to get a little hairy. I started wondering what else has this noise, so I paired the phone directly to the headset, without going through my board with the CC256x on it. Noise is present. Paired to an old Bluegiga WT32 evaluation board. Noise is present (on both ends, meaning whether I paired a phone to that board or a headset). Paired a phone to a Mad Catz aptX headset, noise is NOT present. Paired to my car, noise is not nearly as prominent (may in fact be a different kind of noise). In fact, paired to most vehicle systems, the noise was not heard. This leads me to suspect the problem is with CVSD / 8 khz mode, and that all of the implementations on which I've not heard the noise are all using WBS / mSBC / 16 khz. I will see if I can test that theory using WBS mode on the CC256x, but that won't help much for my application since I need to support 2 devices in call at once, and none of the targeted headsets seem to support WBS anyway.

The CC256x is always the master of the connection in my application due to the need for two SCO links at a time.

I have installed service pack 1.4. Not sure what went wrong with 1.3, maybe I forgot to disable sleep mode before converting to .h or maybe I was experiencing the race condition mentioned in the release notes. Will verify tomorrow whether it addresses the noise, as well as will check to see my theory on WBS.

Noise still heard on SP 1.4. I haven't quite gotten WBS working on HFPAGDemo yet, but was able to pair that headset with the board and still hear the noise in 8 khz / CVSD mode.

Hi dwf,

Maybe i'm missing something. You mentioned that the noise was heard when you connected the headset directly to your phone w/o CC256x involvement and also when you tested the CC256X loopback (in such case there should be no audio connection to the headset). 

Why do think that this issue is related to CC256X and not to specific headset?

I probably need better understanding of your system and your test environment.

br,

Kobi

In testing the loopback, I had to enable the call audio channel first (i.e. VS_PCM_Codec_Config 8khz and open the SCO link to the headset), then I could enable PCM loopback. If I tried to enable PCM loopback before setting codec config and opening SCO, it didn't give me loopback audio. Come to think of it, I didn't try merely setting codec config, but my application has those two operations tied together, to change the codec config then open the SCO.

Initially I did think it was CC256x specific until I tested those other things. I do not hear the crackle with the phone paired to most car audio systems, or to that one specific gaming headset I tried. Now, at this point, I'm trying to understand more of why this issue happens, so I'd like to get the CC256x M4 HFPAGDemo running in wide band speech mode to see if the noise is limited to 8 khz CVSD. I tried sending HFRE_Send_Select_Codec and it returned a -1005 error (invalid operation). There's no documentation on the HFP 1.6 features in the Bluetopia documentation supplied with the release, so I'm not sure what I'm missing.

I figured out the problem with error -1005, the HFRE port features defined up top weren't setting the codec negotiation feature bit. So I fixed that, and now the codec is configured for MSBC, but I'm hearing a buzzing noise instead of what I'd expect to hear, silence. I'm trying to get to a point where I can confirm the crackling noise I hear is limited to CVSD mode and have some reasonable evidence that there's nothing I could do in hardware to avoid it

Is there an additional step besides calling VS_EnableWBS that it needs to do to configure the codec properly for 16 khz? I notice there's a hardcoded blob that it sends which matches up to a VS_PCM_Codec_Config command

static const unsigned char SetCodec16KHzValues[] =
{
0x01,0x06,0xFD,0x22,0x00,0x0C,0x00,0x80,0x3E,0x00,0x00,0x01,0x00,0x00,0x00,0x00,
0x10,0x00,0x01,0x00,0x00,0x10,0x00,0x01,0x00,0x01,0x00,0x10,0x00,0x11,0x00,0x00,
0x10,0x00,0x11,0x00,0x01,0x00
};

Looks like it's setting up as output, 3072 khz PCM clock, 16khz Fsync, etc., so I don't see anything wrong with that

Hi,

Can you confirm if you've followed the steps from: processors.wiki.ti.com/.../CC256x_Advanced_Voice_and_Audio_Features

Regards,
Gigi Joseph.

Yes, I do follow those steps--the HFPAGDemo has a function call VS_EnableWBS that does the first few steps upon codec negotiation, then a command line "ManageAudio 1" that sets up the SCO connection.

Thanks!

Hello,

I think we have similar problem,and our audio expert think it's codec problem.

https://e2e.ti.com/support/wireless_connectivity/bluetooth_cc256x/f/660/t/503441

Do you have any clue to fix that?

Regards

Gao Hong