Post Go back to editing

I2S input on ADAU1702

ADAU1702 I2S Slave configuration


When the ADAU1702 is used as an I2S slave, the stream is not read in as should. The audio data is however not clearly received.


This is a simplified design of our system:


Description of setup:

We have DSP1 (ADAU1701), generating an I2S bit stream, which is then sent via a TI CC8531 wireless audio link to DSP2 (ADAU1702).



The problem we experience is lots of pops and clicks on our analog outputs of DSP2.



  • We have modified DSP1 to send out on one of the 2 I2S channels only a “1” in 5.23 format. We can trace this value easily up till the input of DSP2, so it shows that the signal chain up till here is working ok.
  • We have a board with only an CC8531 receiver and a DAC, this works perfectly.
  • When DSP2 is configured to directly send the value of the I2S input stream to its digital I2S output, there is rubbish coming out on the I2S data line (clock lines seem OK).
  • DSP2 is configured to output a value of “-1” in 5.23 format on the other I2S slot and this is OK.
  • When an RMS level meter is placed in DSP2, and read out via SigmaStudio, this level meter shows a very nervous reading, indicating that the read-in value is also not OK.

This leads to believe that the I2S input of DSP2 is not working as supposed to.

(Attached: “LA Output.png”, logic analyser measurement of DSP2 in- and outputs)


Settings of DSP2:


What could be wrong here?

  • I have tried the same configuration on a second board and I get exactly the same result:

    I2S data input seems to be almost random, however when I send a stream of data with only zeroes I can see only zeroes coming in. When there is one bit set in the stream, the I2S input read 5 or five bits which are jumping around to random 1 or 0.

    It seems there is some correlation between input and output . With numerical data input (constant) the read data doesnt even look like what is sent.

    To rule out some different problems I Also performed the following measurements:

    - Clock stability: I connected the MCLK input pin to a phosphor scope and there is no occurrence of double or skipped clocks. There is also no significant jitter.

    - I verified the input data up to pin 11, MP0. Data is read in on audio input 2 and 3 inside SigmaStudio. (Also tried on other channels with the same result).

    - I double checked signal levels and integrity, these seem ok.

    - I double checked the connections and measured all I2S and clock pins up to the pins on the DSP itself.

    - Double check the pin connections:

    MCLK (12,288 MHz to pin32, MCLKI)

    LRCLK to MP4 = pin8

    BCLK to MP5 = pin9

    SDATA to MP0 = pin11

    I have no more options to investigate.

  • After more testing and trying, I configured the I2S input waveform so that it would exactly match the output waveform from the ADAU. I figured that it should at least take this input waveform.

    So I configured the BCLK, LRCLK and data lengths accordingly to what the ADAU outputs itself: this helped me to find what was wrong. I misinterpreted the statement that MCLK and BCLK should be synchronous. I interpreted that they should be in phase, but they should also have exactly the same frequency. After fixing this the system starts behaving as expected.

    Now there is one remaining issue: our I2S input stream does show some jitter. I measured up to 1nS jitter per 200uS secconds of MCLK. This leads to pops and clicks into the sound we recreate.

    Is there anything we can do to fix this apart from changing to an DSP with SRC? Or adding a separate SRC?

    (what is the tolerable clock jitter for the ADAU1702?)

  • Hello Elmar,

    Sorry for the delay. I have been overloaded and the company shuts down between Christmas and New Years day.

    So yes, your investigation about the MCLK is correct. The phase is not important, what is important is that there are the correct number of transitions for each clock cycle. In your case, 256. So the frequency relative to the BCLK and LRCLK is ciritical. Since you are not transmitting the MCLK then this is a significant issue. So I will try and think of some solutions.

    Try to set the PLL mode to be 64xfs instead of 256xfs. Then it will be looking for an MCLK that is 64 times the sampling frequency. This also happens to be the BCLK frequency which is also 64 x fs. So then run the received BCLK into the MCLKI and see how it performs. There is still the jitter issue. The PLL will filter out some of the jitter but it will still be present on the BCLK and LRCLK. I think the jitter will be OK, 1ns is well within the setup time for the BCLK.

    The other options I can think of is to use a PLL to reconstruct the MCLK at 256 x fs but I don't like that idea and I am rather sure you will not. So try setting the PLL mode pins to 0,0 and feeding the BCLK into the master clock input. Let me know how it goes.

    Dave T