• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 1507 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C5535: i2s sync

Marc48067
Expert 2000 points
Part Number: TMS320C5535
Other Parts Discussed in Thread: SRC4190

Hello,

we have the following system design and are wodering if i2s must be synchronized. The Dsps do signal processing of both input signals and output the processed signals. i2s is serviced by ping pong dma blocks. I think all i2s must be in sync in order not to loose frames or have duplicated frames. Is that right? How can we achieve syncronisation?

System.pdf

Thanks

Marc

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the sw team. They will post their feedback directly here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 2000 points

    I had a look at the sample rate converters from ti, for example the src4190. Can we use this ic to synchronize the remote (async) i2s signals to the local system clock (12 MHZ)? The input and output sample rate and data width should stay the same ( 16khz, 16 Bit). The output port of the src4190 should operate as master. Then the i2s clocks are generated synchronously to the input clock of the src4190 (12 MHZ). The i2s output signals of the src4190 could be fed into the local dsp. Can we use bypass mode?? In the datasheet it is mentioned that in bypass mode the clocks must be sync! Can we use normal mode without changing sample rate or data width?

    Thanks for your feedback

    Marc

  • 0 in reply to Marc48067
    TI__Mastermind 30110 points
    Hi Marc,

    I would assign one AIC3204 as master (drives BCLK and WCLK) and then slave the other AIC3204 and the 2 C55xx devices to that single I2S master.
    For going across the border, the AIC3204 is capable of deriving its MCLK from the BCLK pin.
    Assuming the BCLK and WCLK frequencies are all the same, then this clocking structure guarantees synchronization.

    If you cannot achieve this, then I would still slave the I2S on each C55xx device to the AIC3204s since they have better audio clocks. Internal to the C55xx, you can run an ASRC software routine to keep the sample rates from drifting apart, eventually losing samples.

    There is ASRC software included in the www.ti.com/.../c55x-audioframework
    And this E2E discusses it too: e2e.ti.com/.../521530

    Are the I2S frequencies all the same or do you need to do sample rate converison? Maybe you can use a faster BCLK than necessary to support multiple sampling rates, also.

    Hope this helps,
    Mark
  • 0 in reply to Mark M
    Expert 2000 points

    Hi Mark,


    thanks for your proposals, they were really helpfull to me. Your first suggestion where one AIC3204 is the system wide i2s master seems to be the simplest one. We have a system wide sample rate of 16khz and data width of 16 Bit, so no conversion is needed. We are doing echo cancellation with AEC/AER lib in the C55 dsps. After calling the algorithms, the processed data is output by the dsps. We use 3 different i2s interfaces on the c55 dsps. One for interfacing the AIC3204 and 2 other for sending and receiving data to and from the remote dsp. i2s interface for sending data out to the remote dsp acts as master. i2s interface for receiving data from remote dsp acts as slave. Is it better to use only 1 i2s interface for connection of the dsps?

    Is this your first proposal?

    SystemNew.pdf

    Why is it neccesary that AIC3204 slave derives its MCLK from BCLK? Isn't it possible that AIC3204 slave uses external 12MHZ MCLK, but operates as i2s slave?

    Thanks a lot

    Marc

  • 0 in reply to Marc48067
    TI__Mastermind 30110 points

    Yes, I recommend using one codec as the clock master. Derive the MCLK via BCLK on the other codec. This provides best synchronization.

    It will be even better to use the same crystal to clock the C55x and the codec. You may even be able to output the MCLK derived from BCLK from one of the pins on the codec when it is configured as Aux Clock Output. Check that BCLK meets the input frequency for the PLL.

    If you have a codec with separate MCLK that is slave to another codec, then it still can drift and cause skipped or repeated samples.

    Refer to Figure 3. ASI Slave Mode (Independent Master Clock) in Audio Serial Interface Configurations for Audio Codecs - SLAA469.

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    Expert 2000 points

    Hi Mark,

    I have one additional question on this issue. You mentioned that it will be even better to clock the C55x in sync to the codec. I don't understand that. The C55x (DMA, data processing) is done on a much faster clock than the i2s clocks. So it shouldn't harm if the C55x clocks are async to the i2s clocks?! Am I wrong here?!

    Thanks in advance

    Marc

  • 0 in reply to Marc48067
    TI__Mastermind 30110 points
    Hi Marc,

    I was referring to Figure 3 in www.ti.com/.../slaa469.pdf

    Figure 3 shows a configuration that should be avoided where the host processor has a separate clock input and drives the BCLK and WCLK to the codec. Because the codec's crystal and the frame clock are independent of each other, they will eventually drift and cause skipped and/or repeated samples.

    Figure 5. ASI Master Mode shows the improved version, where a single crystal clocks both the codec and the host processor. The codec provides the BCLK and WCLK to the host processor. This will prevent drift. Another valid approach is to source the MCLK via the BCLK from the host processor (or another codec). This way they stay synchronized.

    I think, however, if the codec provides the clocks to the host processor, then yes, the host processor is running so much faster than the codec's clocks, it will have several cycles to read the incoming data in real-time. The issue of clock drift (and skipped and/or repeated samples) occurs when the codec's MCLK is supplied by a different clock source that can drift away from the BCLK/WCLK that is provided by the host processor.

    Hope this helps,
    Mark