Post Go back to editing

ADAU1701 -- Output a copy of the I2S audio input to an I2S output

The context is:

Custom board designed to be modular --- each particular board will use either L, or R, or possibly both, and may work with a particular audio band or with the full spectrum.

Thus, I want to output the entire audio input  ("entire" as in:  both channels, full bandwidth --- simply put: an exact copy of the input) so that the next modules (the next boards) can use any portions of the audio as they need.

EDIT:  Forgot to mention:  the reason why I don't simply have each board "tap" into a master/broadcast I2S set of signals is that one of the modules may actually get audio from the DACs;  then, that module would output the audio through I2S for the rest of the modules to work with it.

For the ADAU1701 in SigmaStudio, I understand that ports 2 and 3 of an Input control map to L and R (respectively) of the first I2S input --- correct?  (the documentation says "first channel in I2S or TDM stream" --- not 100% sure what "first channel" means).  And Dig0 and Dig1 map to L and R of the first I2S output (SDATA_OUT0).

Is it just a matter of connecting port 2 of the input to a Dig0 output control, and port 3 to Dig1 ?   (see example in the figure below, where the module would implement a 2-way crossover for the left channel, so that presumably a second module would do the same for the right channel)

SigmaStudio example of I2S in to I2S out

Any special configuration needed?


Clarification added
[edited by: cmoreno_uw at 8:57 PM (GMT 0) on 25 Jan 2019]
  • Hello Carlos,

    When you are setup for I2S then the first two channels are the only two channels so you are correct in your implementation. If you have a TDM4 or TDM 8 line then you have more channels. Then the language of the first channels makes more sense.

    If I read your description correctly this should work. You are simply bussing the signal down to the next DSP etc. There will be a small delay between the devices for the data transmission. I think it will be about two or three sample periods but I would have to research this. So you could implement a short delay on the first devices to maintain phase alignment.

    Dave T

  •     Dave,

         The delay from one ADAU1701 to another via I2S is exactly three samples, as measured in the six-DSP mixer I helped design a few years ago.

         Best regards,


  • Thanks Bob, I have trouble remembering all the small details between our entire family of parts so I try not to rely on only my memory!

    So what's my name??? Oh Yes!

    Dave T

  • The ADAU145x and ADAU146x parts are also three samples: one sample frame to shift in the serial audio data, one frame of calculation in the DSP core, and one frame to shift the data out. This is, of course, the minimum, and assumes that there is no latency through any of the processing blocks in the algorithm.


  • Hello Ken,

    Actually, the ADAU145x and ADAU146x are a little different. There is a resync circuit to synchronize all the different serial ports and that is a frame. I would have to look up the details but it is 6 to 7 frames for data to be shifted in, processed and then shifted out. The resync circuit to help handle jitter on the clock lines can vary and that is why it is 6 or 7 and not just a set number of sample periods.

    The 1701 is internally much simpler.

    I had researched this and detailed it in another post somewhere here on the forum. The ADAU144x also has the de-jitter resync circuits and the data farm which adds a delay. I guess it is a trade-off for all the serial ports and flexibility that these newer parts have.

    Dave T

  • There is another solution:  
    If the I2S bus you are connecting too is fully defined with all the clocks as master, and the ADAUxxxx parts are connecting to that input bus as slave devices.  As long as you are careful with trace capacitance and loading you could just parallel the devices onto the bus.  That would avoid the 3-7 sample delay period.   The better solution if doing that would be to retransmit the I2S connection over an interface that is better designed for unknown or more variable characteristics.  If the I2S bus was packaged over LVDS, it would double the number of "connections" needed but building a backplane with LVDS drivers/receivers for the audio data would allow a lot of flexibility. 

    If all you are ever going to work with was stereo channels, using TDM and slots for the audio samples may also give you some options.  But that would require the data to "daisy" through the system.