PCM5122: PCM5122 POP Solution

Hi Millark,

I will take a look at this and get back to you by Thursday. Thanks for the wait. 

Regards,

Arash

Thanks Arash. Just to follow up, we can also hear the pop even if the dac is in mute mode setting reg 0x03 to mute both channels.

Thanks . would you please send me the schematic (DAC board + anything that is connected to DAC output). 

Regards,

Arash

Here is the section from the schematic showing the DAC connections. This is connected back to an NXP IMX8 chip for I2S clocks, data and I2C

Thanks, Will review it as mentioned above.

Regards,

Arash

Hello, 

As far as I know muting the part (whether internal or using external circuity) has been the best option. If you need the use a software solution probably need to  make sure you mute the IC before  changing any clk status.  I noticed in your schematic you have connected a voltage divider to XSMT pin. May be in reality you populated only one of them on the board.  The un-mute takes 104 samples when XSMT pin is used. 

In Master Mode, the device generates BCK and LRCK continuously from SCK,  so as long as the SCK is provided it should not go to sleep. For more information on Master mode clks and programing please refer to  section 8.3.6.6 in datasheet.

Regards,

Arash

Thanks Arash

We have not missed any resistors on the xsmt pin and we do not get pop when the dac shuts down, which proves this part of the circuit is working. Powering down is not the issue.

As per my last message, the mute does not stop the pop when the clocks are provided, setting reg 0x03 for both channels and leaving it muted, then applying the clocks, the dac still produces a pop sound.

On a scope, we can see a slight increase in noise from the dac on the line outs when the clocks are applied, even in mute mode. This noise is inline with the pop and the noise tails off within less than 1ms.

[UPDATE]

On further investigation we see the following:

1) When the device boots, all clocks are at gnd.

2) Open an alsa device for playback, all clocks are high and correct

3) Stop alsa device, mclk goes to gnd, bclk and lrclk remain high with no clocks.

This is clearly stopping the dac from going into standby mode as the clock detection error handling as per datasheet requires the bclk and lrclk to go to ground before standby mode is entered.

If we manually put the dac in standby mode using reg 0x02, then take it out of standby mode after the clocks are up and running, there is no pop.

So somewhere in the driver chain there appears to be an issue with the way the clocks are being torn down as mclk is taken to gnd, but lrclk and blck are not. This is either in the sai core implementation or the pcm512x driver.

Ideally we would want a way without hacking at drivers to standby the dac if the mclk goes low. I don't see any such reg setting though.

Hi Millark, 

I don't have access to the internal schematic to confirm  the implementation of  MCLK  (or BCLK &LRCLK) driver  is done differently and I would be surprised if it is done that way.  I don't see a register to put the dac in standby mode  when/if  MCLK goes low. The only option that I know is to use XSMT pin; since  If it is moved from High to Low in 20 ns or less, then the device will interpret it as a request to mute. It will perform a soft mute, then move to standby.

In software mode if muting is not working , I don't see how else it can be done.

Pin XMST does not remove the pop sound when the clocks are provided. We have tested this extensively. It does indeed mute the DAC, however the pop sound can still be heard when the clocks start.

The only way we can remove the pop sound is to put the dac in standby mode before the clocks start, and exit standby after. This should really be done by the driver as part of the tear down process. I can see why it wouldn't have been done as it would be assumed that all clocks should be taken to ground and the auto standby should then kick in on the dac as part of the clock error checking, but in our case this is not true.

I think the only things left for us is to either to edit the pcm512x driver and add a standby feature, alternatively contact NXP and see if we can get some support regarding taking clocks to ground.

I prefer to have the clocks pulled down to ground but that option might be hard to get. Most probably you have to just add standby feature. I am going to close this post  as I think there is not much can be done in this post. Best of Luck.

Please do not close this as it is far from resolved and others are struggling with the same issues.

To be clear, the fault as far as we see it is with the DAC, not the software. The DAC pops when clocks are applied, even with DAC muted via registry or XMST pin as suggested, the pop can still be heard when clocks are applied. This to me is a fault not a software issue. In the world of streaming audio, it is very common the source audio changes in sample frequency and clocks would need to be stopped and started as Alsa will need to re prepare the hardware for the new stream format. Currently these DACs do not work in this scenario due to the pop sound. Arguably one has to have the volume on any connected amplification up quite high for this to become annoying, but when connected to a power amp and using the DAC volume control, this pop is very clear regardless of the volume setting in the DAC. This is a very common use case.

On other threads you have suggested that people add there own hardware mute circuits to the line outs, meaning that you are aware of this issue and are suggesting that people solve it in hardware. If this is the case, you should really update your documentation and reference design to explain this.

I notice from the change log on the data sheet, item 2:

Deleted Internal Pop-Free Control For Sample-Rate Changes Or Clock Halts, .. With Popless Operation

Can you please explain what this was that was removed from rev A to rev B as it is clearly related to our issue?

We are in the middle of updating the PCM512X driver to add the standby function, however this is not easy as the DAC brings itself out of standby mode after 8 seconds due to some condition, we will hopefully figure this out.

Our approach is to try and have this workaround as a driver fix, as even with the clock lines starting from gnd, there is still a pop sound when they are applied, so resolving this will not remove the pop sound and will still require a driver change to support it.

Please can you let me know regarding the change-log from the data sheet or provide me with a link to the rev A document.

Let's leave this open while we try to resolve it so others can benefit from the solution as we find it.

Sure,  let me know if driver change can resolve it.

Regards,

Arash

Arash

Can you please answer the question asked above:

"I notice from the change log on the data sheet, item 2:

Deleted Internal Pop-Free Control For Sample-Rate Changes Or Clock Halts, .. With Popless Operation

Can you please explain what this was that was removed from rev A to rev B as it is clearly related to our issue?"

Update. Sadly this does not seem possible to solve with a driver update.

The DAC not only pops when clocks are supplied, but it also pops when toggling out of standby mode even when active clocks are present, even when muted.

You can test this without a driver update by downloading a wav of silence:

1)  Put the dac in standby mode

i2cset -y -r 1 0x4c 0x02 0x10 (or whatever tool used for the registty update)

2) Start a silence stream

aplay silence.wav -Dhw???

Notice there is no pop in standby mode when the clocks start

3) Take the dac out of standby mode with valid clocks

i2cset -y -r 1 0x4c 0x02 0x00

The pop can clearly be heard when standby is disabled. I guess thinking about this, it is probably unsurprising that this happens as standby mode likely shuts down the internel part of the dac that deals with the clocks, not being a dac designer, this is an assumption.

We have also tried these tests toggling mute in registry and xmst pins with the same result.

Please can this be escalated, it would seem that without an update to the hardware, it is impossible to remove the pops from this dac unless you open it with fixed clocks and the clocks never change. For streamers, this dac becomes obsolete and unusable.

This IC is a mature part, nevertheless I was able to find the DS's first revision  and  the following two items were modified in the new revision: 

Pop-Free Control For Sample-Rate Changes Or Clock Halts( is Removed)

Intelligent Muting System; Soft Up or Down Ramp and Analog Mute For 120dB Mute SNR With Popless Operation (  in the  new one  "Popless operation"  is removed in the latest revision)

The only info that might be of some help is to know that " the PCM5122 EVM avoids audible pop with an electrolytic decoupling capacitor. This capacitor provides enough time between data loss from USB or S/PDIF and power supply loss for the muting process to take place."

Oh dear, this is very un cool. So TI has been actively removing this from a number of data sheets for dacs, what was listed as a feature is now not, pretty poor. I see this has been removed from more than just the PCM512x range.

Whilst this doesn't resolve our issue, at least it confirms our fears that these dacs simply pop on sample rate changes or clock halt recovery and this is now a known issue to TI.

We have thousands of products in the field built since 2015 and we need to address this somehow. We will need someone at TI who can work with us to see if we can find a solution within the driver. A possible sequence of events that is known to TI within the registry that will enable us to remove or at least decrease this pop sound. Please can you provide a contact or escalate this internally as a matter of urgency.

Your comment regarding the "electrolytic decoupling capacitor" is not the issue for us. This is very specific to the eval board where you have USB and spdif.

Hi,

Apologies for the delay, please wait for our linux driver expert to continue the thread.

Regards,

Hi, Milark,

Would you please share me the driver code? we can have an analysis. 

Regards

The driver code we have in production is from kernel 5.15.5. We have also tested with the latest code code from mainline with no luck.

We have made various edits with no joy so we rolled back to the 5.15.5 code base.

As per the above in this thread, our driver updates to mute the dacs using xmst pins, digital mute etc and preventing the dac from standby mode, or forcing the dac into standby mode until clocks were applied all failed.

You can test this as above simply using registry changes without reviewing driver code, it seems impossible to stop the dac from poping when clocks are provided or when coming out of standby mode.

TI are clearly aware of this internally as they are removing the references to "Pop-Free Control For Sample-Rate Changes Or Clock Halts( is Removed)" from data sheets from a number of dacs. Now I can understand that these are mature parts, however they are still current. Whilst you may not want to update the driver to over come such issues (if even possible) as they are matures dacs, We are hoping there is a ways around this using registry edits in a specific sequence.

Hi Millark,

Apologies for the delay, I've applied for an evaluation board, and will try to reproduce what you described. If the driver or sequence really need to be modified, we will propose a solution and solve the issue.

Regards

I assume you will be using the PCM5122EVM. Do you have a link to the schematic for this board. We want to ensure there are is no mute circuit on the line outputs as this would skew the test?

Yes, please check the EVM users guide through below link:

https://www.ti.com/lit/ug/slau444a/slau444a.pdf?ts=1676365829881&ref_url=https%253A%252F%252Fwww.ti.com%252Ftool%252FPCM5122EVM-U

Please check the board when you receive the board as the data sheet for the PCM512x EVM you sent shows a PCM5141PW or a PCM5142PW as the DAC chip options and not the PCM5121 or PCM5122.

Hi Millark,

The EVMs you said is PCM514xEVM-U, PCM512xEVM-U is what I've applied, I've got it.

From the Linux driver, I saw standby mode has been enabled after muting, or disabled before unmuting, this part is written in 

BTW, could you check the register status when pop noise happens? use i2cdump command. we can find some clues if clock error or other errors happened.

Kevin

Thanks for investigating this. As per the above thread, we have tried many combinations of muting before and after applying clocks, before and after standby with no luck.

The mute you are referring to on reg 3, seems to refer to volume ramp down to mute. This does not help us and we have tested it:

i2cset -y 1 0x4c 0x03 0x11

aplay silence.wav -Dhw??

Pop can be heard even when muted.

We have also tried muting using the xsmt pin via a gpio that we have connected:

gpioset 1 6=0 (mute via xsmt)

aplay silence.wav -Dhw??

Pop can still be heard with xsmt mute

" I believe the problem maybe caused by bclk and lrclk remain high after stoping alsa device." If this were the case and there would be no pop sound if these clocks are taken to gnd, then there would be no pop when the dacs are first provided their clocks, which there is.

Fresh boot, all clocks at gnd:

aplay silence.wav -Dhw??

Pop sound happens. So even if we take the clocks to gnd, the next time they are applied, the dac will pop. I don't see how taking the bclk and lclk to gn is going to help here. I agree it is strange that they are left high, this must be a bug in the SAI driver on the tear down, however unlikely to remove the pop sound as per above test.

Hi, 

I wonder if you're willing to try a new Linux driver.

Actually, we have a new solution with regbin architecture, it can support DAC devices and operable register configuration. you can read the document and use tool for configuring steps. I hope it will help you to solve the problem. If there’s any further question, my email address is kevin-lu@ti.com, you can contact me. The code package is available at below link.

https://git.ti.com/cgit/lpaa-android-drivers/pcmdevice-linux-driver/

Thanks Kevin. Can you confirm that the issue we are facing can be overcome using this driver? We have spent a lot of time on this already and would like some confirmation from TI that this issue is known and resolved in the new driver before allocating resource to this. We have no issue in testing stuff if we are given the heads up that it is known to solve a problem, but after weeks of internal resource allocation to this a simple "please try this driver" without any confirmation of resolution is not ideal.

Hi Millark,

Sorry, but I didn't see more additional information, like register status when issues happened, it's hard for me to reproduce the issues unless you lend us your device.

Here is the registry state before playback and after clean start:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 11 31 00 00 00 00 00 01 7c 00 00 00    ....?1.....?|...
10: 00 00 00 10 00 00 00 00 00 00 80 00 00 00 00 04    ...?......?....?
20: 00 00 00 01 00 00 f3 04 02 00 11 01 00 00 00 00    ...?..???.??....
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 22    .............00"
40: 02 07 14 05 00 00 00 00 55 00 00 00 00 00 00 00    ????....U.......
50: 00 00 00 00 00 00 00 00 61 00 00 00 00 00 7f 15    ........a.....??
60: 01 10 00 00 00 01 0f 03 07 10 00 00 00 00 00 00    ??...?????......
70: 00 00 03 00 04 00 80 01 00 00 00 00 00 00 00 00    ..?.?.??........
80: 00 00 00 00 11 31 00 00 00 00 00 01 7c 00 00 00    ....?1.....?|...
90: 00 00 00 10 00 00 00 00 00 00 80 00 00 00 00 04    ...?......?....?
a0: 00 00 00 01 00 00 f3 04 02 00 11 01 00 00 00 00    ...?..???.??....
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 22    .............00"
c0: 02 07 14 05 00 00 00 00 55 00 00 00 00 00 00 00    ????....U.......
d0: 00 00 00 00 00 00 00 00 61 00 00 00 00 00 7f 15    ........a.....??
e0: 01 10 00 00 00 01 0f 03 07 10 00 00 00 00 00 00    ??...?????......
f0: 00 00 03 00 04 00 80 01 00 00 00 00 00 00 00 00    ..?.?.??........

aplay silence.wav -Dhw:SAI3

We hear the pop sound

Registry during playback:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 01 11 00 00 00 00 00 01 7c 00 00 00    ....??.....?|...
10: 00 00 00 10 00 00 00 00 00 00 80 00 00 00 00 04    ...?......?....?
20: 00 00 00 01 00 00 f3 04 02 00 11 01 00 00 00 00    ...?..???.??....
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 22    .............00"
40: 02 07 14 05 00 00 00 00 55 00 00 00 00 00 00 00    ????....U.......
50: 00 00 00 00 00 00 00 00 61 11 00 36 00 40 00 10    ........a?.6.@.?
60: 01 10 00 00 00 01 0f 03 07 10 d9 d3 00 00 01 02    ??...???????..??
70: 03 84 03 00 04 00 85 01 11 00 00 00 00 00 00 00    ???.?.???.......
80: 00 00 00 00 01 11 00 00 00 00 00 01 7c 00 00 00    ....??.....?|...
90: 00 00 00 10 00 00 00 00 00 00 80 00 00 00 00 04    ...?......?....?
a0: 00 00 00 01 00 00 f3 04 02 00 11 01 00 00 00 00    ...?..???.??....
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 22    .............00"
c0: 02 07 14 05 00 00 00 00 55 00 00 00 00 00 00 00    ????....U.......
d0: 00 00 00 00 00 00 00 00 61 11 00 36 00 40 00 00    ........a?.6.@..
e0: 01 10 00 00 00 01 0f 03 07 10 d9 d3 00 00 01 02    ??...???????..??
f0: 03 84 03 00 04 00 85 01 11 00 00 00 00 00 00 00    ???.?.???.......

Registry state with playback stopped:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 11 21 00 00 00 00 00 01 7c 00 00 00    ....?!.....?|...
10: 00 00 00 10 00 00 00 00 00 00 80 00 00 00 00 04    ...?......?....?
20: 00 00 00 01 00 00 f3 04 02 00 11 01 00 00 00 00    ...?..???.??....
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 22    .............00"
40: 02 07 14 05 00 00 00 00 55 00 00 00 00 00 00 00    ????....U.......
50: 00 00 00 00 00 00 00 00 61 00 00 06 00 40 68 11    ........a..?.@h?
60: 01 10 00 00 00 01 0f 03 07 10 d0 10 00 00 01 02    ??...???????..??
70: 03 84 03 00 04 00 88 01 00 00 00 00 00 00 00 00    ???.?.??........
80: 00 00 00 00 11 21 00 00 00 00 00 01 7c 00 00 00    ....?!.....?|...
90: 00 00 00 10 00 00 00 00 00 00 80 00 00 00 00 04    ...?......?....?
a0: 00 00 00 01 00 00 f3 04 02 00 11 01 00 00 00 00    ...?..???.??....
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 30 30 22    .............00"
c0: 02 07 14 05 00 00 00 00 55 00 00 00 00 00 00 00    ????....U.......
d0: 00 00 00 00 00 00 00 00 61 00 00 06 00 40 68 11    ........a..?.@h?
e0: 01 10 00 00 00 01 0f 03 07 10 d0 10 00 00 01 02    ??...???????..??
f0: 03 84 03 00 04 00 88 01 00 00 00 00 00 00 00 00    ???.?.??....

We have also ordered the dev board and will perform the same tests with that.

What's the time sequence between i2c and i2s clk? Kindly check it with scope. I2S should be earlier than I2C clk.

Shenghao, I will check this, however the above test is being performed with the DAC in hardware mode without the driver connected via i2c in the dts, it performs the same way in hardware mode as it does with the i2c / pcm512x driver connected. Pops occur at the same time with or without the driver in use. When the driver is connected, we cannot use i2cdump as the driver blocks access to the device,