To use externl control Slew Volume on ADAU1701 has POP noise

Hi JasonCS,

There could be several possible causes for the pop sound, so let's start with one that would be easy to fix. Often for whatever reason, the incoming audio from the ADC carries a small DC offset. When your micro changes the gain, this offset changes with it, causing a pop in subsequent stages. Try inserting a DC Blocking filter after your ADC as shown below:

The RealTime Display can show you if any DC exists in your audio. The graph below is my result when changing the integer gain setting from 10 to 20 and back, with no signal (except for some noise from my source), and no DC Blocking filter in the circuit:

We observe that my setup has a negative DC offset. After inserting the DC Blocking filter the offset disappeared, eliminating the disturbance when changing gain:

If adding the DC Blocking filter does not help, then the cause must be elsewhere and we'll need to analyze the problem further.

Best regards,

Bob

Hello Robert,

I have tried your method to add DC filter at input of whole software. It same situation.

Also it has been used Slew Mix and Single Slew Adjust volume control to test then the result

is same. Unfortunately, pop noise is still there. I have monitored I2C bus to avoid that MCU send wrong command.

There is no different. ADAU1701 accept those command and given react.

I have no idea current issue. I use SS 3.80 Build2 Rev1146.

Is it possible that pop noise is from incorrect hardware design? so far the design works well.

Hi,

Sorry the DC block didn't help, but at least we eliminated the DSP signal path as a possible problem source.

I assume your micro sets the volume by sending a four-byte word to the parameter RAM that controls the DC source. Also your I2C monitoring shows that no writing to other addresses is taking place. Thus there should be no unwanted changes in the DSP itself. Perhaps as you said, the issue may be hardware related.

When I tried the above tests on a -1701 eval board I used SigmaStudio to change the DC source and heard only a faint "thud" which went away when including the DC block. Perhaps the I2C write itself is somehow coupling into the audio, by a ground loop or other means. One way you could test for that is to have your I2C write to an entirely unused spot in parameter RAM -- if the pop persists, this shows that it's through the hardware.

Bob

Hello Bob,

Thx your reply. However, what should I write to unused parameter RAM? 0xFF? or read back then write into again?

If the problem is happened by this way, should I seperate Analog gnd and digital gnd then connect at power source spot to avoid this situation? or how do you think to add capacitor between I2C bus and gnd to avoid switching noise?

Hi JasonCS,

Are you using Safeload to update the parameters? Safeload is a mechanism that allows you to update parameters in between audio samples, to avoid having unknown or corrupt values in memory if the data is written during the middle of an audio frame. Sometimes, pop noises can be caused if safeload is not used.

Safeload is described on page 37 of the Revision B datasheet: https://www.analog.com/static/imported-files/data_sheets/ADAU1701.pdf

I also wrote an FAQ describing how to use Safeload here: https://ez.analog.com/docs/DOC-2632

JasonCS wrote:

Thx your reply. However, what should I write to unused parameter RAM? 0xFF? or read back then write into again?

No, you don't have to write anything to the unused parameter RAM.

JasonCS wrote:

If the problem is happened by this way, should I seperate Analog gnd and digital gnd then connect at power source spot to avoid this situation?

It's not necessary to have separate analog and digital ground planes. I doubt that this is related to the problem.

JasonCS wrote:

or how do you think to add capacitor between I2C bus and gnd to avoid switching noise?

No, this is not necessary. It is not likely that switching noise from the I2C bus is causing the pop sound.

Please try implementing Safeload, as described in my earlier post.

Thanks,

Brett

Hi JasonCS,

Actually, since you're just writing a single word to the DC Source, KJBob correctly pointed out that this probably isn't the source of the problem. Still, it's a good exercise to try using safeload each time you update a parameter when audio is passing through the system.

Would you mind sharing the contents of the lookup table? That might help with debugging.

Thanks,

Brett

Hello Gen,

I have used ur suggestion thru safeload. it words very well.

I am appreciate to get this experience.

Hi Brett,

As it turns out, you were right all along. So we find that safeload eliminates the unwanted noise when writing to any parameter, even when there's only one word to write. Good to know!

Bob