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.

Jitter Present on TAS1020B I2S clocks



Hello,

I am using TLV320AIC3254EVM-U.

The I2S clocks (Master clock, Bit Clock, WordSelect clock) have jitter in them.

The jitter is degrading the audio quality.

Does anyone has a fix for this jitter ?

 

I am attaching the screenshot of the waveforms taken from the oscilloscope.

The Pink is AudioClock -12.288Mhz,

Blue is the WS clock 48Khz,

Green is the Bit Clock 3Mhz,

The screenshot has the time-period  Deviation details.

The waveforms dosent look smooth because of the probe-groud loop, but the jitter is present for sure.

 

  • Brontok,

    MCLK jitter can come from:

    - jitter on the XTALI (the TAS1020B was characterized with a crystal 6MHz input, not an oscillator) - jitter on XTALI would have a negative impact on the internal PLL.

    - jitter introduced by the host controller

    - closed-loop adjustment of the ACG in the TAS1020B by the application program

    In an application like this, the TAS1020B has to recreate the codec clock based on the rate that the isochronous data appears, so there's some closed-loop adjustment of the ACG going on. 

    To eliminate jitter, you could provide a high-quality clock to the TAS1020B's MCLKI and set up the isochronous transfer to be asynchronous (if your host supports that).

    Regards,

    Frank

     

  • OK,

     

    I have few question regarding the setting up of Isochronous transfer to asynchronous:

     

    Does providing a clock to MCLKI and setting up the ACG block registers (page 27 in datasheet) accordingly, will enable the asynchronous isochronous transfer ?

     

    OR are there some additional set of registers present, which are required to programed in oder to activate the asynchronous isochronous transfer ?

     

    Does a host machine running a WinXP or Win7 OS, supports the asynchronous isochronous transfer by default ?

     

    Regards,

    Brontok

  • Brontok,

    I have not tried this personally.

    I know that once upon a time Windows did not handle asynchronous correctly - that's why folks used synchronous mode.

    If you are going to use asynchronous isochronous, you will want to modify the endpoint descriptors to so-indicate, as well as defeating the SOF closed-loop adjustment of the algorithm;  some detailed modifications of the sample application will be necessary.

    The last paragraph in section 5.10.4.2 of the USB 1.1 specification may apply, in which case you would not need to provide a separate feedback endpoint.

    Good luck,

    Frank