Part Number: TLV320AIC3104
My team and I are currently observing something that we find strange. We are using the input LINE2L for our application and have verified that the input levels are in the mV range and should not be saturating the input. When we raise the PGA level, we can hear saturation in our recordings which so far is understandable. What we don't understand is when we analyze the digital data of our recordings, we observe rollovers on the digital values that exceed the peaks. We were expecting clipping instead and because of this rollover, the saturation sound more like distortion therefore sounding very bad.
Our application is running the CODEC at 32bit signed PCM with 16kHz sampling in I2S mode. Here is a figure showcasing our issue. It is a 1kHz tone captured by our microphone into LINE2L which is then digitalized. I have also attached a dump of the registers of the CODEC.
Please find attached another figure that illustrate the problematic more clearly. This is a 1kHz tone sampled at 16kHz with 16bit width data in I2S mode. We see that there is no clipping and in fact, we are losing a lot of the dynamic range.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Alex Huynh:
I'm sorry for the delay in responding to your query, we've had a bit of excitment here in Dallas due to an unsual cold spell which has knocked out power and water to much of the team. We will get back to you as soon as possible with answers to your questions.
In the meantime, can you verify page 0,register 10 is set properly? The screen capture looks like a formatting issue and you may have missed the 1-bit shift of the data in I2S mode (see section 10.3.2.3).
In reply to Tom Hendrick:
Hope everything is going better at Dallas.
This could be it... I will try this when I have the chance and let you know.
Yes - nearly back to normal here. Do let us know when you've had a chance to verify the bit shift.
It worked, we are finally getting the full data. However, we don't understand why is this register needed. We would like to comprehend fully if you don't mind.
Is the above the default formatting? Or is there no offset by default and we have to set it ourselves by 1. When we looked at the application notes, it never mentioned the need to use register 10. Our application takes into account the formatting of the above figure where data is valid on the second rising edge of the bit clock.
Register 10 is actually used to create offsets for TDM mode. If adding a 1-bit offset helps with the audio recording, I would double check that the host processor is set up to receive data in the I2S format above.
If you can also provide a register dump, I can take a look at the register configurations to ensure that nothing looks out of the ordinary.
In reply to Aaron Estrada51:
So you are saying that register 10 should not have solved this? By setting it to 1, are we essentially having the MSB of the valid data at the third rising edge of the bit clock?
You can find the register dump in my original post. The only difference is now I have register 10 set to 1. I can provide you with the new register dump tomorrow as I am not in the office currently but it should be what I just described.
We are using a LPC1788 from NXP as our microcontroller and even in its user manual it describes I2S protocol as so.
The data is automatically placed into 32 bits FIFO and no data processing is done.
The CODEC will output data in the I2S format specified in the data sheet. Because of this, I am thinking two things... The first being that the CODEC output does not have this 1 bit shift (possibility that the PLL may be causing this) and second, the NXP microcontroller is expecting an extra bit shift.
I am not familiar with the LPC1788 so I can't say for certain but is there any way to add offsets? I would double check on the microcontroller side just to be sure. On the CODEC side, I see you have the PLL configured and it looks like it is expecting an input clock of 3.072Mhz. Is this correct?
Moving forward, I would also recommend taking scope captures of the ASI bus. If you can get WCLK, BCLK and DOUT on the same capture, that would be great.
I can now see clearly that the CODEC outputs the data in the I2S format specified in the datasheet. I have attached some scope capture with different offset just to check its effect on the data and it is as you said. We will continue investigating our application. No the microcontroller doesn't seem to have any registers for playing with the offsets.
Thanks for the update. I look forward to your findings.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.