TLV320ADC3101: Voice quality without MCLK is worse than the one using MCLK

JUN CAI said:

When use MLCK (with hardware rework), the voice quality is quite good; but if doesn't use BCLK the voice quality becomes worse noticeably.

should be :
When use MCLK (with hardware rework), the voice quality is quite good; but if doesn't use MCLK the voice quality becomes worse noticeably.

sorry for the typo.

Hi Jun Cai,

How does the recording with using BCLK sound? Does the quality sound distorted? Are you able to share a recording of both cases so we can compare?

What value of MCLK and BCLK are being used? Are they both the same frequency? I think it would be very helpful if you can share a schematic and full I2C register dump so I may see how the device is getting configured. If possible, please provide one I2C dump when using MCLK and one I2C dump when using BCLK. 

Regards,

Aaron Estrada

Hi Aaron Estrada

Thanks for the reply.

MCLK is 24.576MHz, while BCLK is 1.536MHz

I have attached the schematic, the captured wave file with MCLK or BCLK by the following command

arecord -D hw:0,0 -f S16_LE -r 48000 -c 2 -twav /tmp/a.wav

Also the i2c register dump value is attached in zip file.

debug_using_MCLK_or_BCLK.zip

Thanks,

Jun

Hi Jun Cai,

I looked through both register dumps and I am a bit confused. When using MCLK, I see that the PLL is configured and it is selected as the clock input. However, the PLL is disabled. Do you know why this is? Why is the PLL disabled even though you are configuring it?

There is a similar situation for the BCLK I2C register dump. I see that the PLL coefficients are configured but the PLL is disabled. In the BCLK case, I also see that in Page 0, Register 4, PLL clock isn't selected as the CLK_IN source. Additionally, for the BCLK register dump, AOSR is set to 1 and may cause some issues with the clocking. Some more clarification on why the register dumps look incomplete would be helpful. 

Regards,

Aaron Estrada

Hi Aaron Estrada,

For MCLK case, the register value of Register 4: Clock-Gen Multiplexing is 0x3, which means CODEC_CLKIN = PLL_CLK and PLL_CLKIN = MCLK, it's working well (BCLK is 1.536MHz).  “PLL is configured but PLL is disabled” -- I think the reason would be I reused the source from

https://git.ti.com/cgit/ti-analog-linux-kernel/dmurphy-analog/tree/sound/soc/codecs/tlv320adc310x.c?h=tlv320adc310x_318&id=9ade84cc7e746abbf6bd9c12051eba3b80f056a9 but left some default configuration untouched. What I think is the setting of PLL may NOT take effect if we don't use PLL, correct?

For BCLK case, the register value of above register is 0x1, which means CODEC_CLKIN = BCLK.

When we use BCLK of 1.536MHz, I remember I found an interesting thing is, configured CLKOUT 's source to BCLK and set CLKOUT M_VAL to 1, then the value measured on PIN3(DOUT) is 48KHz. while measured PIN1(BCLK) value is 1.536MHz. This means internal BCLK is not same as external BCLK. There must something wrong but I did not figure out why. However, to hack for 48KHz to working, need set NADC, MADC, AOSR all to 1. That might be reason the noise comes from. Please provide some suggestion on this.

Thanks.

Jun

Hi Jun,

What are the clock settings when NADC, MADC, and AOSR are not equal to 1? If using a 48kHz Fs, the PLL should be used. Can you try BCLK as an input with the following PLL settings:

P = 1

R = 2

J = 32

AOSR = 128

MADC = NADC = 4

Regards,

Aaron Estrada

Hi Aaron Estrada,

Thanks for the reply. I tried with your setting but the recorded sound is with much noise.

The output should not be as expected as 48KHz.  This is what I'm confused (See my last sentence in last reply).  Any further clue?

BTW, "If using a 48kHz Fs, the PLL should be used." is a mandatory requirement ?
What's the consequence if not use PLL for 48Khz?

Regards,

Jun

Hi Jun,

The PLL is not needed for 48kHz Fs. In your case, it is due to the PLL_CLKIN value being 1.536Mhz. Sorry for the confusion. 

I will attempt to use BCLK on an EVM to see if I run into any trouble. In the mean time, I am curious if there may be any software related issues. In the register dump you previously provided, was this register dump taken before, after, or during running the arecord command?

Regards,

Aaron Estrada

Hi Aaron Estrada,

Thanks for following up. The register dump is generated during running arecord command.

Regards,

Jun