ADAU1462: loud pop/click when audio starts

Just completed a board that uses the ADAU1462to read audio through the S/PDIF optical input.  The design closely follows the ADAU1466 evaluation board, with a self-boot EEPROM  (which I successfully programmed from SigmaStudio).

I also followed the instructions to set up the SPDIF input, using an ASRC.

It mostly "works like a charm", except for the loud pop/click when audio starts.  By "when audio starts", I mean when I click PLAY for the first time on the audio player  (using audacious on Linux).   This seems to correspond to the moment when the SPDIF line becomes active.

And by "loud pop/click", I mean really loud  (as in, I-burned-one-tweeter loud!!!).

I tried the "mute when lock lost" setting of the ASRC, but it seems to make no difference.  Here's a screenshot:

The SPDIF tab seems to have a similar setting, but that control is disabled and does not allow me to even show the pull-down list:

Neither the top-left "SPDIF LOCK DET" nor the "SPDIF Loss of Lock" controls allow me to do anything  (they're both disabled).  I cannot even read the whole text that is selected in the "SPDIF Loss of Lock" pull-down list.

Do I have something incorrect in the settings?  Or am I missing something else?   How can I make the system entirely clickless?

Thanks,
Carlos
--

  • +1
    •  Analog Employees 
    on Jan 20, 2020 6:46 PM

    Hello Carlos,

    No, you are not exactly missing something. It is a sore spot you have hit upon. Yes, we have all the logic setup to automatically mute when SPDIF lock is lost and for when the ASRC lock is lost, however, the problem is that the memory used for the ASRCs are not cleared when the part powers up. To make matters worse the DSP core, or the serial ports, cannot clear out the dedicated ASRC memory. So the solution is to mute the ASRC output in the DSP core so that the random audio samples in ASRC memory is purged. ( this is for when you use the ASRC to go from an outside source into the core at the core rate). Then you use a slewed volume control so it slowly ramps up and then you do not get the pop. I will attach a project to show you how it is done. 

    This project has the concepts in it but the implementation can be adjusted to meet your needs. This was designed for an I2S signal source where it could disappear at any time so it will also mute upon loss of lock. To keep that quiet I had to use a delay cell so the loss of lock is detected "before" the audio is actually lost giving time for the volume control to skew down. 

    The output of the ASRC right after powering up is actually a DC level. There are no clocks going to it so the output does not change. This is also a reason for the pop. You could use a DC block but I think this muting circuit works the best. 

    In your case if you are using it for SPDIF then the SPDIF section should take care of that muting and you might not need the extra overhead of the look-ahead mute circuit. 

    Note, you will have to change the AND mask to match the actual ASRC channel you are using. 

    Give it a try.

    Dave T

    8204.ADAU1452 ASRC Lock Detect Example.zip

  • Hi Dave,

    I'm quite puzzled with this.  I tried your solution  (well, the relevant parts from your project), and it works.  Everything is clickless now  (including hot plugging or unplugging the optical cable).

    However, one detail puzzles me:  how can it work for both plugging and unplugging?  In fact: how can it work for the initial pop, if the delay is on the audio path?   After power-up, the "locked" signal is inactive (because there has not been any audio produced by the host system, so the SPDIF is at constant-zero).  As soon as there's audio, the pop comes from the ASRC.  I start the ramp-up immediately, but the pop will only show up 1 ms later, when the ramp-up has at least partly raised the volume.  So I should hear it.

    The only explanation would be that the ramp-up is much slower than 1 ms, so when the pop shows up after a millisecond, the ramp-up is barely starting, so the pop is still attenuated to the point of being inaudible  (a bit surprising ....  I would think it should be audible).

    But then, if that was the case, I would necessarily hear the pop when unplugging the input, right?

    Notice that in your comment next to the delay block, you talk about looking ahead so that the ramp-down starts ahead of the "loss of lock".

    Can you shed some light on this?

    Thanks,
    Carlos
    --

  • 0
    •  Analog Employees 
    on Jan 21, 2020 3:24 PM in reply to cmoreno_uw

    Hello Carlos,

    I will give this a try to explain only in writing without a whiteboard to draw pictures as I explain. 

    For the cold start. You are right the SPDIF is not active yet but this means the ASRC is also not active yet. So with no clocks the ASRC does not process data through its memory and so the output sits at some random number. This is the DC and once the clocks start then the following random data in memory starts coming out but also the FIR filter starts being calculated. So these random numbers start being multiplied by numbers that are usually close to zero so the high DC output goes away quickly. I am not sure the actual time but the group delay of the ASRC calculations are in the datasheet and it is in microseconds. I think a few hundred. So the ramp up slew time is set a little on the slow side to allow time for the random data to be purged. So the initial pop is not in the SPDIF, it is in the ASRC but I get your confusion because this pop also has to go through the delay line but I set the slew time to a linear slew setting of 9. This is around 43ms so the 3ms delay is not a factor. The slow slew if fine for initial power up and when first turning on a signal and that sort of thing. It will not usually be an issue or a noticeable problem for the user of the product. You certainly could adjust this for a faster time and still remove the pop. 

    Now the other situations long after power up when the device is operating and then you pull the SPDIF. Now this I need to further investigate after talking to the designer about a month ago. He said the SPDIF will not stop its clocks but it will free-run with no lock on the receiver PLL. I am not 100% certain of this. But, the SPDIF circuits do have the mute upon loss of lock so it should take care of that situation itself. If the clocks out of the SPDIF do indeed continue, then the ASRC will continue and not stop. The ASRC also has the loss of lock mute and should mute. I always like to be certain so I like having the extra mute in the DSP program.

    Now when the ASRC is being driven directly from a serial port and not the SPDIF, then the serial port will be a slave to an external clock and if those go away, like with a Bluetooth system, then the ASRC will stop in its tracks. It has no clocks to perform a ramp down mute. This is there the look-ahead is handy. The lock bit will go away, this will trigger the external control volume control to start ramping down. Note that it is set to 0 slew. This is around a 5ms slew time so by having a 3ms delay it gives it time to lower the volume a lot which makes the pop or click inaudible. It is not fully muted but it is most of the way down. In 3ms it would be at least 60dB is my first guess. Let me do some rough calculations: It is linear slew so it will go from 0dBFS to -144 dBFS in ~5ms so that would be ~28dB/ms so that would be -84dB which is often down into the noise floor.  So the delay gives time for the volume control to react after lock has been lost before the actual audio hits the volume control.

     The plugging in case is easy. The SPDIF will not unmute until it has locked to the signal and has good audio. So this circuit is not needed for that case. If you are not using SPDIF and are using I2C inputs from the serial ports then the ramp up is handy. The audio is not always clean for the first few sample periods after clocks appear. It all depends on the device driving the serial output and also things like signal integrity on the PCB layout. 

    Well, I hope this helps. It is a cool thing to be able to do easily with SigmaStudio, manipulate time.  

    FYI, KJBob had carefully measured the slew times and put up this great post about it. 

    https://ez.analog.com/dsp/sigmadsp/f/discussions/65746/sigma-300-adau145x-slew-volume-rates

    Dave T

  • 0
    •  Analog Employees 
    on Jan 21, 2020 3:32 PM in reply to DaveThib

    Hello Carlos,

    One more little comment. I did see your question about using an external uC to mute the amplifier. This is possible and may work if it is done fast enough. The key is the polling of the slave port is slow. How often would you poll the DSP to see if the lock bit went low? So what can be done is to read the lock bit like I did in the example project but then drive a GPIO line with the result. This would give you an external trigger that you could connect to a GPIO pin on your uC and set that to trigger an interrupt. Then quickly send out the command to the amplifier to mute. I think this may be fast enough. Then you can make the code smart in your uC and if it is the first time it unlocked since power up then wait a little longer to unmute the amp to give time for the pop to pass. After that it can be done faster.

    Dave T 

  • Once again, Dave, thank you so much — your replies are always most helpful and go the extra mile to explain the details!  I like the idea of outputting the bit and reading as IO.  For that matter, I'm considering replacing the uC with an FPGA  (e.g., the Lattice chip in the TinyFPGA, a fully standalone FPGA, in a 5mm x 5mm QFN-32 package).  The uC is not doing anything fancy, and with the FPGA I have the flexibility of even reading complete I2S samples to externally act on those.