• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 552 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TLV320AIC3254: Sporadic failure causing strange audio processing

Gamli
Prodigy 215 points
Part Number: TLV320AIC3254

Hello,

I wanted to check if you could give me any support with a problem we are having with the codec chip in our product.

We are using the TLV320AIC3254 codec that communicates with an MCU on a custom board. We are using I2C for control and I2S for sound transfer between a bluetooth module, the codec and an MCU. We are using the mDSP_A and mDSP_D for the audio processing. We are using PurePath studio to design the audio filtering, then using the generated header files in order to use it. The audio processing includes a mono mixer, biquad filter containing a variable Q bandpass filter, and additionally a VAD noise filtering block for outgoing sound. The incoming sound includes a bass booster and a mono mixer.

A specific scenario in the product requires switching between sampling frequencies. We switch between 44.1kHz and 8kHz depending on if it should process incoming audio as normal audio streaming (44.1kHz), or a phone call (8kHz).

The problem occurs in a phonecall (when switched to 8kHz), and occurs in about 10% of phonecalls, but it is very sporadic and unpredictable. When the problem occurs, the sound picked up by the microphone, and is processed by the codec and then sent to the other side of the phonecall, is suddenly of bad quality. I have attached two mp3 files, which are recordings of the other side of a phonecall. These recordings are using the same product and same scenario.

Can anyone help me out here? What might be going wrong in order for the sound quality to become so bad sometimes? Any support really appreciated!

  • 0
    TI__Guru 57800 points

    Hi, Gamli,

    Welcome to E2E, thanks for  your interest in our products!

    From the information you shared, it may be complicated to check what could be the root cause of the issue. Can you please share more details about the clocking architecture of the system where the codec is being used, as well as the codec clock settings? I have seen some issues when changing between sampling rates without properly adjusting the clock settings. Is it possible to share the process followed to change between sampling rates?.

    Best Regards,

      -Diego Meléndez López
       Audio Applications Engineer

  • 0 in reply to Diego Melendez
    Prodigy 215 points

    Hi Diego,

    Thanks for your reply. But yeah, to go into some more details:

    We are using the MCU to clock the codec. The clock settings are initialized using the generated header-files from PurePath. Initially we use clock settings for 8kHz and then when applicable, switch to 44.1kHz. The clock and power settings are initialized as follows:

        {  0,0x00},
//			# reg[  0][  1] = 0x01	; Initialize the device through software reset
    {  1,0x01},
    {254,0x0A},
    {  0,0x01},
//			# reg[  1][  1] = 0x08	; Power up AVDD LDO; Disable weak AVDD to DVDD connection; Enable Master Analog Power Control, AVDD LDO Powered; Disable weak AVDD to DVDD connection
    {  1,0x08},
//			# reg[  1][  2] = 0x01	; Enable Master Analog Power Control MODIFIED TO 1
    {  2,0x01},
//			# reg[  1][ 71] = 0x32	; Set the input power-up time to 3.1ms
    { 71,0x32},
//			# reg[  1][123] = 0x01	; Set REF charging time to 40ms (automatic)
    {123,0x01},
    {255,0x00},
    {255,0x01},
    {  0,0x00},
//			# reg[  0][ 60] = 0x80    ; DAC prog Mode: miniDSP_A and miniDSP_D ARE powered up together, miniDSP_A used for signal processing
    { 60,0x80},
//			# reg[  0][ 61] = 0x00	; SynchMode is disabled; DAC prog Mode: miniDSP_A and miniDSP_D NOT powered up together, miniDSP_A used for signal processing; Use miniDSP_A for signal processing
    { 61,0x00},
//			# reg[  0][ 17] = 0x08	; 8x Interpolation
    { 17,0x08},
//			# reg[  0][ 23] = 0x04	; 4x Decimation
    { 23,0x04},
    { 15,0x03},
    { 16,0x88},
    { 21,0x03},
    { 22,0x88},
    {  0,0x08},
//			# reg[  8][  1] = 0x04	; adaptive mode for ADC
    {  1,0x04},
    {  0,0x2C},
//			# reg[ 44][  1] = 0x04	; adaptive mode for DAC
    {  1,0x04},
    {  0,0x00},
//			# reg[  0][  5] = 0x91	; P=1, R=1, J=24
    {  5,0x91},
//			# reg[  0][  6] = 0x18	; P=1, R=1, J=24
    {  6,0x18},
//			# reg[  0][  7] = 0x00	; D=0000 (MSB)
    {  7,0x00},
//			# reg[  0][  8] = 0x00	; D=0000 (LSB)
    {  8,0x00},
//			# reg[  0][  4] = 0x03	; PLL_clkin = MCLK, codec_clkin = PLL_CLK, PLL on
    {  4,0x03},
//			# reg[  0][ 12] = 0x88	; MDAC = 8, divider powered on
    { 12,0x88},
//			# reg[  0][ 13] = 0x03	; DOSR = 768 (MSB)
    { 13,0x03},
//			# reg[  0][ 14] = 0x00	; DOSR = 768 (LSB)
    { 14,0x00},
//			# reg[  0][ 18] = 0x02	; NADC = 2, divider powered off
    { 18,0x02},
//			# reg[  0][ 19] = 0xb0	; MADC = 48, divider powered on
    { 19,0xB0},
//			# reg[  0][ 20] = 0x80	; AOSR = 128
    { 20,0x80},
//			# reg[  0][ 11] = 0x82	; NDAC = 2, divider powered on
    { 11,0x82},

    When switching the sampling rate, we run the following process:

    • Mute ADC and DAC
    • Power down ADC and DAC
    • Change PLL to desired value (set PLL on then change value of J)
    • Set desired clock divider values for ADC and DAC.
    • Reprogram the mDSP with the correct DAC and ADC filter values
    • Power up ADC and DAG
    • Un-mute ADC and DAC

    Hopefully this gives a bit of an insight into what our problem is. From the audio files, can you draw any suggestions on what might be happening?

    Otherwise any suggestions are appreciated.

    /Gamli

  • 0 in reply to Gamli
    Prodigy 215 points
    Small update:
    As I don't really need to use filters specifically for 44.1kHz when using the mDSP_a, I tried skipping the part of reprogramming the values for mDSP_a, and skipped changing the clock for the ADC, so I only reconfigure mDSP_d and DAC clocks.
    Now it seems like the problem does not occur. Do you have any idea why it would sporadically not finish changing the ADC clock/filter values? Anything that you might think of that could cause this type of instability?
    BR,
    /Gamli
  • 0 in reply to Gamli
    Prodigy 215 points

    Hello,

    It seems like the root of the problem is that the PLL is not successfully set. If I manually insert a 50ms delay (random value that worked) right after I set the PLL value, the problem disappears. Is there some flag that I can check in order to verify that the PLL is set successfully? is that the recommended way of doing this? Or do I det the PLL at the wrong place in the procedure?

    A reply would be appreciated, TI employees, does not have to be a solution, but an acknowledgement that this is actually monitored would be nice...

    Best regards,
    Gamli

  • 0 in reply to Gamli
    TI__Guru 57800 points

    Hi, Gamli,

    Sorry for the delay, We have been quite busy lately. The PLL needs around 10ms of delay to output proper PLL_CLK after programming, otherwise the PLL_CLK may not be correct, leading into some issues.

    Best Regards,

      -Diego Meléndez López
       Audio Applications Engineer

  • 0 in reply to Diego Melendez
    Prodigy 215 points
    Hi Diego,
    A. Is that something I missed in the documentation or is it missing in the documentation?
    B. Is there a way to do it safely other than giving it a fixed delay?
    BR,
    Gamli
  • 0 in reply to Gamli
    TI__Guru 57800 points

    Hi, Gamli,

    This is specified on section 3.4 of the Chapter 3 of the AIC3254 applications reference Guide. There is no mechanism on the codec to indicate when the PLL_CLK is running properly, so adding the delay is the only way to make sure the PLL is running properly.

    Best Regards,

      -Diego Meléndez López
       Audio Applications Engineer