TLV320AIC3105: I2S vs TDM Mode Offset?

Thank you for your response. 

Can you confirm that the only offset setting is at  //Table 15. Page 0/Register 10: Audio Serial Data Interface Control Register C? Changing this setting will have an affect on both the ADC and DAC, correct? The DAC works fine in TDM mode, it's the ADC that is off. 

One test I plan on running today is to bypass one of the buffers. On the DAC, BCLK, MCLK, LRCLK I have a 74LVC1G125GV on the sending end (not on receiving). on the ADC SDOUT I have a 74LVC1G125GV on the output, and then another on the receiving end. This was done because that data line is reversible (on other configs), and it was easier to do it that way than to have a bypass for receiving.  I wonder if that double buffer is causing a slight enough delay at the high speed used in TDM to cause issues. It works fine when in I2S mode, so I thought I'd ask before I dug more into this. 

Edit: I just bypassed the SDOUT and went directly into the MCU and it did not change the issue. 

Hi Jay,

Sorry, you're right the offset is universal. TDM mode typically does not contain an offset, so I would double check if your receiver is expecting one. Also the BCLK alignment changes between I2S and TDM mode, you'll need to double check that your receiver is expecting the correct latching edge.

Best regards,
Jeff McPherson

What's the difference between TDM and DSP? Related: https://e2e.ti.com/support/audio-group/audio/f/audio-forum/1246732/tas6584-q1-dsp-mode-vs-tdm-mode?tisearch=e2e-sitesearch&keymatch=tdm%2520vs%2520dsp#

Does the TLV320AIC3105 support TDM left-justified? It appears that DSP is sending right-justified? Or the DSP mode is altogether not the same as TDM mode?

Jeff McPherson said:

the BCLK alignment changes between I2S and TDM mode, you'll need to double check that your receiver is expecting the correct latching edge.

Yes my MCU seems to be expecting left justified. It might be blind luck that it's working for the DAC because maybe the 3105 can receive the signal I'm sending it interchangeably. But my MCU expects the data bits to start at the rising edge of BCLK (with 1 bit offset). 

Is the ADC output on the 3105 delayed by 1 bit? It appears that the 3105 is sending the ADC on an offset of 2, and the DAC is being received at an offset of 1. The MCU expects an offset of 1 for both. 

Yellow = LRCLK
Purple = DAC Data (out of mainboard, into 3105)
Green = BCLK
Blue = ADC Data

You'll see below that the blue ADC signal is slightly right of the DAC signal. Definitely enough to cause the MCU to think it's one bit off. 

Hi Jay,

TDM is the generic form of I2S and has no standardized format. DSP and TDM are typically interchangeable but care should be taken to ensure that the formatting is as expected.  DSP mode according to the datasheet contains no data buffering, meaning the data of channel 2 immediately follows the data from channel 1. This is most similar to TDM mode. The left justified mode in the AIC3105 is a stereo only mode that is basically the equivalent of I2S except the offset is removed.

I wouldn't expect an additional offset in the ADC. It's hard to say if there is an offset looking at only one sample. Does the MSB appear to always be low? Even then this would be a shift to the right, which would make the signal softer, not louder. Also the DAC signal is being generated from the controller isn't it? What happens if you add an offset to the DAC signal to make them match?

Also I have concerns about how triangular your bit clock is. Could you double check that it's meeting the timing requirements?

I know that's a lot of questions but timing questions like this usually have a lot of approaches to solve.

Best regards,
Jeff McPherson

Hello Jeff, 

No problem with the questions. It's helpful. Thanks.

Jeff McPherson said:

Also I have concerns about how triangular your bit clock is. Could you double check that it's meeting the timing requirements?

 The ground wasn't tied correctly. it's a bit less triangle now. 

Jeff McPherson said:

Also the DAC signal is being generated from the controller isn't it? What happens if you add an offset to the DAC signal to make them match?

Yes the DAC is generated by the Teensy. I don't know how I can offset the signal any.... 

On this picture I'm sending a 1khz sine wave from this video to both my PC>USB>Mainboard>3105 and a phone>3105>mainboard.  It looks to me that the ADC is sending it's bit slightly right of the DAC is being received. I know this is just one sample, but this seems to be the case in general no matter how many shots I take of it. I have a 1 kHz sine playing from USB>Teensy>3105 and also from Phone>3105>Teensy using this video: https://www.youtube.com/watch?v=3FBijeNg_Gs

Notice the ADC is to the right of the DAC...

I'm wondering about my PLL and clocks too. Here is what I currently have. I enabled the PLL but no change. Do I need to spend more time configuring clocks than I am here? The rest of my code is just configuring the mixers and volumes. 

bool AudioControlTLV320AIC3105::aic3105_enableTDM(select_wire wires, device dev) {

// Table 7. Page 0/Register 2: Codec Sample Rate Select Register
// In the TLV320AIC3105, for page 0, register 2, the ADC fS must be set equal to the DAC
// fS. This is done by setting the value of bits D7–D4 equal to that of bits D3–D0.
// Sample Rate Select
// 0000: DAC fS = fS(ref)/1
// 0001: DAC fS = fS(ref)/1.5
// 0010: DAC fS = fS(ref)/2
// 0011: DAC fS = fS(ref)/2.5
// 0100: DAC fS = fS(ref)/3
// 0101: DAC fS = fS(ref)/3.5
// 0110: DAC fS = fS(ref)/4
// 0111: DAC fS = fS(ref)/4.5
// 1000: DAC fS = fS(ref)/5
// 1001: DAC fS = fS(ref)/5.5
// 1010: DAC fS = fS(ref)/6
// 1011–1111 : Reserved, do not write these sequences.
//  writeRegister(wires, dev, Page_00, 2, 0b00000000);

//Table 8. Page 0/Register 3: PLL Programming Register A
// D7 1: PLL is enabled
 writeRegister(wires, dev, Page_00, 3, 0b10000000);


  //Table 12. Page 0/Register 7: Codec Datapath Setup Register
  writeRegister(wires, dev, Page_00, 0x07, 0b10001010);// w 30 07 8A P0_R7	 0b10001010
  //Table 13. Page 0/Register 8: Audio Serial Data Interface Control Register A
  // D5 R/W 0 Serial Output Data Driver (DOUT) 3-State Control
    // 0: Do not place DOUT in high-impedance state when valid data is not being sent.
    // 1: Place DOUT in high-impedance state when valid data is not being sent.
  writeRegister(wires, dev, Page_00, 0x09, 0b00100000);

  //Table 14. Page 0/Register 9: Audio Serial Data Interface Control Register B
  //Set to DSP mode
  //Specify 32 bit word length.
  writeRegister(wires, dev, Page_00, 9, 0b01000000); 

  //Table 15. Page 0/Register 10: Audio Serial Data Interface Control Register C
  //Set the Offset 1 bit clock - 255 bit clocks.
  // 16 Bit Mode: device 1 shift 1 | device 2 shift 33 | device 3 shift 65 | device 4 shift 97
  writeRegister(wires, dev, Page_00, 10, 1); 


  return true;
}

Thanks, 

Jay

I2S mode works great with both DAC and ADC. It sounds good. But doesn't this look funny still with the data lines seemingly behind the clock. It should be on the rising edge, right?

Hi Jay,

In I2S mode there is an automatic 1 bit shift, that's why it looks delayed in your second picture. Also the clocks look much more improved in the second picture: the data is clearly latched to the falling edge (data becomes valid on rising edge). In the prior picture it seems like it's not a 1 bit offset, but rather the DAC data and ADC data are latched to different edges.

I highly doubt it's a PLL issue. There's no reason I can think of that the clocking would need to change between I2S and TDM mode if I2S mode sounds good. I still suspect a mismatch between what the codec is trying to output through the ADC and what the Teensy is outputting to the codec DAC.

Best regards,
Jeff McPherson 

The data is right justified, I guess. Teensy (purple) and the ADC (blue). I'm not sure what this proves but it was interesting to me nonetheless. 

Jeff McPherson said:

I still suspect a mismatch between what the codec is trying to output through the ADC and what the Teensy is outputting to the codec DAC.

I will continue to dig into that.

Another user on the Teensy forum said my probes needed to be 10x'd and to retake the shots. So i did. They clearly show the ADC being sent late in TDM mode. My yellow probe's 10x switch is broken so I'm doing one line at a time. 

TDM example, ADC line. 

TDM example, DAC line

I2S example, ADC line

i2s Example, DAC line. 

The ADC is being sent late. I just don't know why. I don't believe the Teensy is the issue. It must be something in the clocks. The 3105 is just late in sending out the ADC bits....

Hi Jay,

Looking back at the datasheet, the timings are listed independently between I2S and TDM mode even though they are almost identical. So I think this may just be a characteristic of the device and it appears to be within spec (delay between BCLK edge and SDOUT <20ns).

Even though it's late, the data is stable by the next half cycle (falling edge) so I think as long as the edge alignment is correct between the receiver and the device, it should be able to work.

Best regards,
Jeff McPherson

Jeff, 

Yes I think you are right. However, another user pointed out on another forum. "the word clock pulse is half a clock different from the datasheet - wondering if that's relevant.". And this has me wondering. If you notice, my word clock is rising on the falling edge of the bitclock, as opposed to the rising edge.  Just a thought. 

There are a few more tests I'm going to run when I get at my desk and I will report back as well. Thank you. 

Hi Jay,

They make a good point, and I agree. The edge misalignment can result in unintended bit shifts, resulting in the distortions you heard. It may or may not also explain the extra delay you're seeing on the ADC output.

Looking forward to hearing from you,
Jeff McPherson