• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 460 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.

Potential Hardware bug in PCM1791A / Digital attenuation not working when DAC ouputting noise

Dav01
Expert 2300 points
Other Parts Discussed in Thread: PCM1791A

Hi TI,

We've found a strange behavior that can cause the PCM1791A to output digital noise (sound like an airplane), and in this "state", the Digital attenuation control is not not working.

We're running Linux (AM335x/McAsp master for I2S) and have done the following test.

  • aplay with /dev/urandom
    digital attenuation works

  • change to incorrect i2s format = "white noise"
    digital attenuation works

  • unknown even causing random "airplane cabin" like noise
    digital attenuation doesn't work..!?

Any clues why this might happen / what could cause this type of noise and the fact the attenuation is not helping to mute the audio output?

The issue is quite difficult to replicate, but what we do is to have a simple shell-script run 'aplay' over an over in a loop, i.e. alsa (davinci / mcasp) setup and teardown. Sometimes this result in a short ~10-200msec zip-noise, but every now and then the loud random noise continues until we reset.

We do have compared register settings before and after the noise and I can confirm it's correct, i.e. 1:1 with how it should be, so I'd say we can assume it's not related to glitches on the i2c-bus. 

See logic-analysis of the I2S sequence overlayed with the audio-output attached:

pcm1791a dac noise capture r1.pdf

  • 0
    TI__Mastermind 27880 points
    Hi Dav01,

    I see two clocks in your attachment, which I assume are the BCK and LRCK, what is your SCK frequency and source? Is it from a crystal or the McASP?

    What exactly are the register settings you are using for the digital attenuation state? There is also another register for a soft mute (register 18 bit0), this could be another option for muting the output in this situation. You stated that the I2C write for digital attenuation happens after the noise has started, can you get a scope capture of when the noise starts and when you try to enable digital attenuation?

    Another test to try is muting the output before the clocks stop.

    If this happens around 1 out of 1000 times, is it depending on what state the clocks are in when it stops them?

    Justin
  • 0 in reply to Justin Bohr
    Expert 2300 points

    Hi Justin,

    SCK is generated from an external PLL running at 45.1584 MHz and is tied to both the cpu & dac.
    Frame and bit-clock is then divided internally by mcasp.

    • PCM1791A dac running in slave mode
      • lrck: mcasp0_fsx      
      • bck: mcasp0_aclkx   
      • data: mcasp0_axr0
      • sck: mcasp0_ahclkx

    I can confirm digital attenuation works except when the dac is caught in the "noisy state". You can see on the logic-plots that the data-line is silent = 0.

    Agree muting is better, but we need to find the actual root cause here, i.e. what exactly that trigger the dac to end up in this bad-state.

    Still a bit surprised that a lost frame making the DAC sad, that said, as you can see, mcasp suddenly changes the bck clock-speed in the captured sequence so maybe this in combination triggers it. 

    /d

    ps. I believe I could speed up this by heating up the board a bit. This could be confusion though.