Prevent poping-noise while programming

Hello Noel,

You are asking some very good questions but I have to talk about these parts separately because they are so different.

When you say "programming" are you talking about updating it through SigmaStudio or are you talking about a controller programming it during startup or reprogramming for some reason during operation?

The ADAU1701 has the DAC built in so the part does have some control over it. There is a mute bit in the DSP Core Control register. Address 0x081C or 0d2076. This register does default to the DAC muted but then once it is programmed I suspect that this register is setup early in the bootup process. If you have an external controller programming the DSP then you can set it up with the DACs muted and then once the program has begun to run then unmute it. If you need to reprogram then you can mute it first and wait a short time before resetting the part. This might help.

For both parts:

If you are using an external controller then I think it would be best for it to control the external mute and then look for a GPIO flag to see when the DSP is running and then unmute. The problem with using a GPIO is that you need advanced warning to start muting slowly and so the program has no way to know that a reset is coming.

The most of the GPIO pins will power up as an input with a high impedance. So it will want to float up. I usually let it float up or put in a weak pull-up and then have the DSP program pull it down once the program has begun execution. I suppose you could do the same with a pull-down resistor.

For the 1466.

This is a very different situation since all it is doing is sending serial data to a DAC. When you press reset the data will stop as will the clocks. Then it is up to the behavior of the DAC when it loses its clocks? Does it just hold the last value it had? A lot of them do it this way. So that means that it will output DC. So one work-around is to be certain that the serial output data is muted to be all zeros for a few frames. It is best to use a slewed mute so it is quiet but then you have to wait for it to fully mute. Then reset the part and the DAC should just continue to output zeros. Then setup your program to have the outputs muted when you compile it. Then when it is loaded the outputs will be muted. Then you can have the controller unmute the outputs and it will slew up nice and cleanly.

I should also point out that if the DAC is getting its master clock from the DSP then it will simply stop dead when it loses its clocks. If it had been sending out zeros for a while then it should not pop.

Now for powering up. That is a different discussion and this depends a lot on your design and the size of caps on the outputs.

If anyone else on the forum has thoughts on this topic please chime in.

Dave T

Hi Dave,

I'm not actively using the ADAU1701 anymore; just mentioned if for reference.

DaveThib said:
When you say "programming" are you talking about updating it through SigmaStudio or are you talking about a controller programming it during startup or reprogramming for some reason during operation?

Fortunately, I am only talking about updating through SigmaStudio. Everything else works fine, as I have better control over the sequence when programming via the MCU.

So the clarify; the end-product works just fine. But when im designing the crossover in SigmaStudio and hit "Link Compile Download" I get this pop.

In this particular case, the DSP is used in a servo-controlled speaker, so this pop is anything but subtle.

DaveThib said:
Then it is up to the behavior of the DAC when it loses its clocks? Does it just hold the last value it had? A lot of them do it this way.

Thanks for pointing that out. It didn't even cross my mind that the DACs would loose masterclocks in operation as the DSP shuts down.

DaveThib said:
So one work-around is to be certain that the serial output data is muted to be all zeros for a few frames. It is best to use a slewed mute so it is quiet but then you have to wait for it to fully mute. Then reset the part and the DAC should just continue to output zeros. Then setup your program to have the outputs muted when you compile it. Then when it is loaded the outputs will be muted. Then you can have the controller unmute the outputs and it will slew up nice and cleanly.

I just tried that; loading a configuration whereas the outputs are muted from the beginning.

That didn't change anything; so you are probably right that loss of MCLK on the DACs causes this behaviour.

If my thinking is correct; I could use a separate clock distribution buffer to feed the DACs directly from the oscillator - as well as the DSP of course.

Then, no popping would occur (even without prior muting); unless there is an audio signal present at the time of the shutdown.

Do you have any thoughts on that ?

Best regards,

Noel

Hello Noel,

Sorry I let this go this long with no answer. Things have been quite busy.

I am interested in this issue because you are not the only one who has to deal with this issue.

I mentioned that you can try to mute the signal and wait long enough to allow the audio to slew down to zero. You said you tried it and it did not help.

What about the other side of this, the starting up of the program? Have the outputs muted in SigmaStudio when you click on link/compile/download. This way the audio is muted when the program starts up. Then after 100ms or so turn them on. That would give time for the filters to stabilize.

Another thing to lookout for is DC from the converters. The ADAU1701 ADCs will always have a DC offset but with the 1466 you have to be sure that the ADCs that are feeding the DSP have the HPF turned on. If they do not have one then add a DC-Block filter into the design. There is one in the library. I have seen even a small offset become a problem after going through an EQ with a LF shelf set to boost. It will do a great job of boosting the DC as well!

After that then looking at the DACs. Are the DACs getting their master clock from the DSP MCLKOUT pin? Can you mute the DAC itself?

So what have you found in the time since you last posted?

Thanks,

Dave T

Hi Dave,

I found that this issue is caused by taking away MCLK from the DAC, which inevitably happens if the integrated clock-buffer is used.

In general, I have not found a way to solve this problem as an afterthought.

I have redesigned the entire DSP board since. Not because of this issue alone, but for improved system performance.

I have changed from Cirrus CS4398 DACs to the much newer AKM AK4439. The AKM immediately enters a shutdown state if MCLK is lost.
Before testing it, I wasn't sure if this would be fast enough, but it is.

Since switching to this DAC, there is no more popping. Programming the DSP while a signal is present may result in tiny pops, but that's a non-issue.

The CS4398 however exhibited a blow-the-woofer-and-your-ears kind of pop.

btw, that also happened with the AKMs predecessor AK4490, which didn't have this shutdown feature.

To summarise, my recommendation is to use an external clock-buffer that operates independently from the DSP or to choose a DAC with regards to its behaviour in a "loss of MCLK" scenario .

Best regards,
Noel

Hello Noel,

Well done. Some good investigation. You are correct in that if you shut down the DSP, reset it and reprogram it, it will stop the Master clock that is coming out of the CLKOUT pin.

I hope your suggestions will help others. Thanks for posting.

Dave T