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.

PCM5242: highest audio quality, external DAC-Clock in I2S slave mode

Part Number: PCM5242
Other Parts Discussed in Thread: SRC4392

Hello,

I would like to use the PCM5242 as follows:


- I2S slave mode, 3 wire interface without SCK,
- SCK via GPIO pin to DAC CLK Source Mux,
- SCK is powered by external oscillator with 45.1584 or 49.152 MHz,

The internal PLL is supposed to feed the DSP (I assume that jitter will not work here). A microcontroller selects the sampling frequency matching oscillator as DAC clock.

My questions:


- Does the DAC clock have to be synchon with the sampling rate (LRCK)?
- Does the DAC clock have to have a correct phase reference to other (external) signals?
- Or are deviations up to +/- 4 SCK allowed ("If the relationship between LRCK and system clock changes more than ± 5 SCK, internal operation is initialized within a sample period and analog outputs are forced to the bipolar zero level")?
- Is my assumption correct that the internal settings for the external DAC clock are made automatically ("The sampling frequency detector sets the clock for the digital filter, Delta Sigma Modulator (DSM) and the Negative Charge Pump (NCP) automatically.")?
- Are there already proven register settings for my project?

Thanks for your support!
Greetings from Berlin, Hans-Jürgen

  • Hi Hans-Jurgen,

    I'm glad to see the project is still moving forward :)

    Quick answers:
    -The DAC clock does not need to be in phase with the LRCK, but should be synchronized. It is best if the 3-wire I2S data is derived from the same clock. If they are not synchronized I think you will see the same clock error.
    -Once you change the clock tree muxes you will need to configure all the clock dividers from the table at the end of the datasheet. Table 32 shows the only combinations of clocks where the auto-detect will function.

    Other thoughts: If you already have the 45 and 49MHz clock, why not just use 4-wire mode? If you look at section 8.8.1 you will see that we describe that as the best case configuration for high performance.

    Thanks!
    Paul
  • Dear Paul,

    thank you for the quick reply!

    Well, I now understand the difference to the SABER DAC's. ESS works with a transport clock on the I2S and a do not force synchronous DAC clock. For this to work, the "Asynchronous Sample Rate Converter" is provided. And a comparable mechanism does not exist in the PCM5242.

    However, I do not understand then the statement "If the relationship between LRCK and system clock changes more ± 5 SCK, internal operation is initialized in a sample period and analog outputs are forced to the bipolar zero level".

    Unfortunately, the I2S signal comes from a well-used ARM Cortex Core that only generates bit clock and LRCK.
    My approach described at the beginning is probably unrealistic.

    Or do you see a way?

    Best regards, Hans-Jürgen

  • Hi Hans-Jurgen,

    Basically if the device detects that the SCK is shifting due to a frequency mismatch by more thank 5 clock periods in a sample period, it will automatically mute. So for example if you are operating at a 48k LRCK, SCK could be 256*48kHz, but if it was maybe 250*48kHz, the device would begin this error state.

    In you application, does the ~50MHz clock you were planning on using for the SCK feed though the ARM Cortex? Does the ARM CPU use it as a master clock? If so, I believe you would be safe using them as all the clocks would be synchronized. You application is still possible, you just need to verify the quality of the oscillators you are using. If you think they can precise enough, then you should be good. You will still need to configure the clock tree over I2C, though. You could also look at something like the SRC4392 to resample the I2S data with the oscillators.

    Thanks!
    Paul
  • Any updates?
  • Hello Paul,

    After the disappointment with the outdated USB / I2S interface and the limited use of the evaluation board, I am not entirely convinced that the PCM5242 is the unified chip for our application.

    We are currently testing an ESS Saber chip.

    Best regards, Hans-Jürgen