• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 604 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.

DM385 McASP driver issue on low frequency

Dmitry Bodnya
Expert 1140 points
Other Parts Discussed in Thread: TLV320AIC3100, DM385, TLV320AIC3104

Hi!

I have two different boards : DM385 IPNC and my own DM385 board. These boards has different sound codecs - tlv320aic3104 on IPNC and tlv320aic3100 on my board(with adapted driver). On both boards audio codec is a master and MCLK for audio codec is driver from McASP AHCLKX = 27MHz.

On both boards I have the same problem - when I am trying to playback or capture sound on frequencies lower or equal to 16000Hz I have constant periodical pops in it.

The problem doesn't exists on higher freqs: 22050,32000, 44100, 48000, 96000Hz. It is appears on 8000, 11025, 16000Hz.

Let me outline: the codec is a master for Bclk and Wclk.

To fix this, I was trying to play with PLL values, thought something wrong. But it didn't help.

It seems to me that it is something going from mcasp side.

To check this I forced PLL value in codec to always drive 16000 WCLK, and on Linux side I take wav file with 16kHz data, modified frequency inside to 32000Hz(to tell the driver that it plays 32kHz) and run it in aplay. So Codec drives 16000Hz WCLK, 512000Hz BCLK -> McASP put data to play buffer, thought that it plays 32kHz.

And in this case I got clear sound! It seems that mcASP driver make different configurations for 32 and 16 kHZ and the last is wrong...

Does anyone seen this behaviour?

Thanks.

  • 0
    TI__Guru**** 170625 points

    Dmitry,

    See if the below wiki pages will be in help:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_AUDIO_Driver_User_Guide

    http://processors.wiki.ti.com/index.php/TI81xx_PSP_Porting_Guide#Audio_driver_.28McASP.29

    http://processors.wiki.ti.com/index.php/Linux_Core_Audio_User%27s_Guide

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Expert 1140 points

    Hi Pavel.

    Thanks for the links.

    Through /proc/asound/card0/pcm0c/sub0/hw_params I observed that on frequencies <= 16000Hz internal playback/capture buffer is not "power of 2" alined. 

    And I remeber that when I tried to write capture application I heard such a problem when chunk size was not alined with power of 2 value.

    I don't know why it is a problem for kernel(ALSA/DMA?) to handle 1000 byte chunk instead of 1024.

    I will try to find buffer configuration in a kernel.

    Or perhaps it is a arecord part to configure buffer in a such way..

  • 0 in reply to Dmitry Bodnya
    Expert 1140 points

    Pavel, 

    on your third link is clearly written:

    ALSA period size must be aligned with the FIFO depth (tx/rx numevt)

    To decrease audio caused stress on the system the AFIFO is enabled and the depth is set to 32 for McASP.
    If the ALSA period size is not aligned with this FIFO setting constant 'trrrrr' can be heard on the output. This is caused by eDMA not able to handle fragment size not aligned with burst size (AFIFO depth).
    Application need to make sure that period_size / FIFO depth is even number.

    So it is arecord probably configuring buffer size not aligned to 32.

  • 0 in reply to Dmitry Bodnya
    Expert 1140 points

    Ok,

    If I start arecord with -B parameter I can control buffer size. Values are little bit strange but I can change default values and now I see the root of problem.

    The problem was not in driver, but in configuration of buffer size.

    Thanks.