• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 426 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SRC4184: Ready output is stuck high

dave breithaupt
Prodigy 40 points
Part Number: SRC4184

with 25 MHZ RCK reference clock,  LRCK input at 48K, LRCK output  at 44K and getting garbage data for converted output.   Slave Mode, all config pins grounded.

Hardware mode.   Shouldn't READY output go low once input/output clocks are at steady rate.

  • 0
    TI__Expert 5645 points

    Hi Dave,

    As you know, SRC4184 when configured in Slave mode, the port LRCK and BCK clocks are configured as inputs, and receive their clocks from an external audio device. The rate estimator compares the input and output sampling frequencies by comparing LRCKI, LRCKO, and a reference clock. The results of the
    rate estimation are utilized to configure the re-sampler coefficients and data pointers.

    The ready output is provided from the rate estimator block to indicate that the input-to-output sampling frequency ratio has been determined and that the coefficients and address pointers for the re-sampling block have been updated.

    Can you please confirm if we had all required clock inputs to the input and output serial port of the device to enable RDYA/B pin to indicate READY output? 

    Thanks and Best regards,

    Ravi

  • 0
    Prodigy 40 points
    The LRCKO is derived from a VCXO 24.576 MHz divided down by 512 to 48K. LRCKI is derived from a 125Mhz clock oversampling an AES3 input to create an effictive LR clock. That LRCK will inherently have at least the 8ns of jitter from the 125Mhz oversampler. Does that create a problem?
  • 0 in reply to dave breithaupt
    TI__Genius 14280 points

    Resolved...

    Turned out my test generator had some jitter being added to the test signal and it drove the SRC control loop nuts.   Once I backed that off,  it locked up and started working.

     

    But wasn't obvious from spec that jitter would break it so easily.