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.

McAsp/I2S driver issue, AM335x. start/stop causing broken frames & unexpected changes in clock freq.

Other Parts Discussed in Thread: PCM1791A, AM3352

Hi,

Background: we found that when tearing down ALSA, this can in rare cases cause the DAC (PCM1791A) to output digital noise even though the frame-clock and pcm data isn't running.

The issue is a bit difficult to replicate, but what we do is to run 'aplay 1sec.wav' over an over in a shell-script loop, i.e. alsa / davinci / mcasp) setup and teardown. Sometimes this result in a short ~10-100msec zip-noise, but sometimes it causes the DAC to get in a bad state, outputting loud random noise until we reset.

At the same time we have another script taking the wifi up & down using ifconfig stressing the system a bit. (you might ask why we do this, reason is that you'll get a tiny audible click from the DAC when doing so even though no sound is running. this might be another issue but when chasing it we found that it's possible to put the system+dac in this broken state which is highly unwanted.)

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. 

Please find a logic capture of the I2S sequence attached below.

pcm1791a dac noise capture r1.pdf

system info:

  • am3352, Linux 3.12/.13 kernel, wl18x via sdio.
  • pcm1791 dac running in slave mode
    • lrck: mcasp0_fsx
    • bck: mcasp0_aclkx
    • data: mcasp0_axr0
    • sck: mcasp0_ahclkx
      external 24.576MHz clock tied to both cpu & dac

  • Hi,

    I suggest you post this also on the Audio Converters forum: https://e2e.ti.com/support/data_converters/audio_converters/f/64 The Codec experts there may better answer this question.

  • Hi Biser, I did a post there as well, more focused on the DAC issue itself. But as you can see in the logic-plots, it seems this is related to something wrong on the mcasp side as well.
  • I have asked the factory team to look into this.
  • Hi,

    Dav01 said:
    am3352, Linux 3.12/.13 kernel,

     

    Is this kernel 3.12 from TI SDK or some community release?

    Dav01 said:
    The issue is a bit difficult to replicate, but what we do is to run 'aplay 1sec.wav' over an over in a shell-script loop

     

    Is there anything special about this 1 sec file, or any wav file will do? How long do you run your tests?

    I tested this on my Am335x Starter Kit running official TI SDK 7.0 (which uses kernel 3.12.10).

    I used a 4 sec wav file in the following shell script: 

       #!/bin/sh

       while true

       do 

       aplay /home/root/1.wav

       done

    I ran the script for about 10 minutes and couldn't hear any noise in my headphones. Is it possible to compare the settings of your 3.12 kernel with the offical TI release (SDK7.0)? Perhaps you've missed something while porting your codec.

    Best Regards, 

    Yordan

  • Hi Yordan,

    It's based on the TI 3.12 (sound/soc/davinci/*)

    Different DAC's will behave differently to this I2S "glitch".
    As I said, to trigger this, you'll have to run for many many hours. We found that in combination with wifi/sdio/irq's/high cpu-load it's easier to trigger the issue. Not sure exactly what 'iw', 'wpa-supplicant', 'wlcore' is doing behind the scenes, i.e. causing a timing glitch on the mcasp-side, clock dividers, etc.

    I'm pretty sure you can visually find the same issue on the I2S bus, but to put the DAC in a bad state, you'll have to use the PCM1791A in slave mode (the starterkit has another codec and clocking scheme).


    Thanks David