16 Input / 16 Output Mixer with AD1939 + AD1974

Hi there,

I am designing a digital audio mixer with 16 audio input channels and 16 output channels. A combined DSP/ARM provides processing and Ethernet capabilities.

In order to speed up the process, I'm using a module that includes an OMAPL138. In the module interface I have got available up to 8 McASP channels. Using I2S I could not transmit all the 32 channels. Thus, I would need to use a TDM8 or TDM16 format. TDM 8 will reduce the emissions.   

I want to use the AD1939 codec but I would need 4 extra inputs. I was thinking on using a AD1974 to provide those extra inputs but I'm in doubt of what would be the best way of connecting the codecs.

Would it be possible/right to connect two AD1939 in parallel, each of them with their own auxiliary AD1974, like in the diagram? Is the diagram correct, using ASDATA1 and ASDATA2, in I2S mode or is there a better way?

Note: I have not connected the 12.288MHz as it seems that is not really necessary for the McASP ports.

Would it be necessary to use some kind of clock buffering/distribution?

  • 0
    •  Analog Employees 
    on Jan 10, 2014 11:56 PM

    Hello Jorpese,

    The way you have set up using two AD1939's in parallel to develop two TDM-8 streams looks good. I think that is the best way to do it and the way you are interfacing the AD1974 using the DSDATA2 and DSDATA3 of the AD1939 is correct. I like that you grounded the AUX inputs on the AD1974 and you should also ground the DSDATA4 input of the AD1939. It is always good to not have digital inputs floating around.

    Regarding clocking. I am wondering who is the master for the LRCLK and BCLK? My suggestion is to have one of the AD1939 parts be the master. Then it will take the MCLK input and derive the LRCLK and BCLK for the rest of the parts including the OMAPL138. I would strongly recommend to use the PLL on the AD1939. It is good to clock the AD1974 from the AD1939 as you show in the diagram. This will work well.

    If the OMAPL138 is to supply the LRCLK and BCLK signals then it will have to generate them based on the MCLK. If this is the case let me know and I will expand on why and how to do this. It is possible but it would have to be done a specific way to avoid clocking issues.

    Regarding your question about clock distribution/buffering. This is somewhat dependent on PCB layout but I don't think you will need it for LRCLK or BCLK as long as the lengths are kept reasonably short. MCLK distribution may be required depending on the drive strength of the clock source.  You will have to pay attention to signal integrity of these transmission lines. Feel free to contact us when you are working on the PCB layout and before you order the PCBs. We would be glad to review your layout.


    Dave T

  • Hi Dave,

    First of all, thank you very much for your answer,

    I can see how confusing that diagram can be. I left an arrow point pointing somewhere it shouldn't, sorry.

    I include a new diagram where I correct that and have done some changes to clarify it and include your suggestions.

    In the diagram, each AD1974 is slave to their respective AD1939 to the left. In turn, the bottom AD1939 is slave to the top one which is the master to everyone (in light blue), including the processor.

    There are two TDM8 streams, with a fixed sampling frequency of 48kHz. That makes the LRCLK=48kHz, BCLK 12.288MHz and MCLK=12.288MHz.

    [For some reason, I cannot insert images, sorry ->file "CODEC_AD_recommendation"]

    Comments on the diagram:

    MCLK is only needed for the master.

    The rest of the CODECs still need to generate a sampling clock, which they can obtain from scaling the LRCLK in their PLL (filter tuned to the LRCLK frequency).

    The OMAP needs at least BCLK and LRCLK to work. The receiving and transmitting sides are completely independent.

    The processor can derive RxBCLK from TxCLK but, for some reason I don't understand, it is derived as a negated version of the first. I guess that could pose a problem? I prefer to provide a copy of BCLK to both inputs, just in case.

    We have already eliminated one clock buffer and several lines. Let's call this design as A.

    FURTHER IMPROVEMENTS (2nd diagram)

    In order to reduce emissions, minimize the BOM and power and facilitate the routing by eliminating lines, I will try to simplify even further the connections.

    Please find it the corresponding diagram, called "Codec_connection_AD_simplified"


    It seems BCLK is redundant as can be generated internally with the PLL from LRCLK. So, no need of MCLK or BCLK for either the Slave TDM 1939 or the auxilliary 1974s.

    The OMAP is on a DIMM module, at a maximum distance of 10cm. I don't know the complete capacitance of pins, connector, tracks etc nor the driving capabilities of the AD1939 so, isn't it better to add a buffer and err on the safe side?


    LRCLK is sent to the TDM slave and the auxilliary ADCs. PLL filter for LRCLK.

    LRCLK is not sent to the OMAP as it can generate its frame clocks internally when provided with an external BCLK.

    As all the LRCLK connections are point to point connections and not loaded, no need of buffer.

    Are there any drawbacks in this design over the design A? Would you recommend me this simplified design?

    Thank you very much in advance,



  • 0
    •  Analog Employees 
    on Jan 15, 2014 7:49 PM

    Hello Jordi,

    I was not able to see the first attachment you sent. I was able to see the simplified drawing but your description is fine so I don't need the drawing.

    Regarding the BCLK polarity I don't think this is a problem. The AD1939 has a lot of flexibility so you can invert the polarity of BCLK or LRCLK in the register settings. It is actually an easy way to swap left and right channels.

    Running with only LRCLK will work and I have done it a lot in the lab. Technically, it may be a bit more stable if you supply all the clocks but I have not found this to be a problem. Then when you factor in the simplicity of the design and the reduced number of high speed lines it ends up being a good way to run the parts.

    I think it is a good idea to buffer the BCLK output. This part does not have a drive strength register setting. Most of our newer parts have this feature but this one does not.

    One thing that does not make sense to me is how the OMAP can function without LRCLK? How does it know where the MSB starts? Then if it somehow finds the proper BCLK cycle and one cycle gets missed due to noise then it cannot recover. I would plan to run LRCLK to the OMAP. I think you will need it.

    Everything else in your simplified drawing looks good. You have the correct PLL settings shown. Remember that you will need a different loop filter for the PLL using MCLK vs the PLL using LRCLK. Figure 30 in the datasheet shows this detail.


    Dave T

  • Hello Dave,

    Thank you for your fast response!

    It is strange you cannot see the attachment. I have tried and can see it. Anyway, I attach the final diagram in case is of any use to anyone else.

    About the LRCLK... you are right! I had a comment on my notes (written some time ago) about that section of the OMAP saying the option to generate a frame sync from the bit clock could only make sense if acting as a master... I happily ignored it yesterday during the simplifying frenzy.

    Thank you again,