• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 428 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DM365 and TLV320AIC3254 codec channel switching problem

GEOFFREY CLARK
Prodigy 30 points
Other Parts Discussed in Thread: TLV320AIC3254

Hi All,

We have a custom board with a DM365 and a TLV320AIC3254 codec, the codec is connected to the DM365 using the McBSP port.

We are running a custom root filesystem using the 2.6.32 kernel from the PSP 03.01.01.39 with a patch to implement the Ping-Pong SRAM buffer technique.

There are two issues we face, the first being Overrun's while recording, debugging suggests that overloaded IO is the cause of this issue with our user space application failing to service the kernel space buffer enough.

While we can live with the occasional Overrun, it does cause our second issue which is channel swapping. Currently we use ALSA with an asynchronous callback and when it is determined that we have Overrun, we use the recover -> open to kick off the audio transfer again, we are finding that more often than not the channels are then been switched. I have printed out the first few frames that are captured after an Overrun, and found that more often than not the first channel sample is 0. I am assuming that this is caused due to the double buffering, and the fact that the peripheral was reset and it's assuming that the RBR has valid data???

Interestingly enough we do not see this when the peripheral is first started, the only difference being that potentially not as much DMA activity is occurring at the start of the recorder application.

As indicated in this (http://processors.wiki.ti.com/index.php/McBSP_Channel_Swapping) document, I have ensured that the master EDMA channel is the highest priority, and that the McBSP is the only peripheral utilising this queue.

I am wondering if anyone could offer some suggestions as to how to ensure that each time the peripheral is started that it aligns with the correct channel??

Should we be modifying the davinci-i2s.c file to suit our codec, or should it work fine with the TLV320AIC3254??

While we see most of our problems at our highest profile we wish to record at ( 48 kHz, 24 bit, Stereo ) we have noticed that starting/stopping can cause the channels to switch also from startup.

I have included our codec files, glue driver (davinci-board.c, our equivilent to davinci-evm.c) and a print out of the codec's registers at the prepare stage (after hw params etc.) in a zip file. I also included the davinci-i2s.c and davinci-pcm.c from our kernel.

Thanks!

Geoff

8831.board-specific.zip

  • 0
    Guru 31670 points

    Geoff,

    This problem looks the one described in this thread.

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/252177/979797.aspx#979797

    I have still the similar suggestions asked in the post.

  • 0 in reply to Renjith Thomas
    Prodigy 30 points

    Hi Renjith,

    Thank you for your quick reply!

    From what I read in this other post, it is most likely a similar problem. I will try some of the suggestions and see how we go over the weekend, but from the debugging results I have collected, I am unsure these will resolve the issue.

    What I am seeing is that when the device restarts the DMA transfer (restarts DMA and then pulls the McBSP out of reset) is that in the first buffer that is transferred that the first sample is zero. So my theory is that data exists in the RBR before the McBSP reset occurs, and when the McBSP is reset it actually zero's this register but the peripherial itself still believes that the data is valid. Thus when you start the transaction again, it actually DMA's this value out to SRAM along with the following sample (which is actually the first one from the codec after the reset).

    I will use the word "sample" to make reference to a single channel, and use the word "frame" to indicate both a left and right sample. I setup a test whereby the LEFT microphone is plugged in, and the RIGHT is left unconnected.

    I see something like this (LEFT should be the samples in bold):

    On startup I see:

    [ 7896.220000] DRR: 00000000 SPCR: 02000031 RCR: 01840180 SRGR: 102F1700 PCR: 00000000
    [ 7896.340000] BUFF:
    [ 7896.340000] 49733
    [ 7896.340000] 16733533
    [ 7896.340000] 215121
    [ 7896.350000] 16732388
    [ 7896.350000] 295126
    [ 7896.350000] 16732853
    [ 7896.350000] 246683
    [ 7896.350000] 16735350

    So all is OK!

    After an Overrun I see:

    [ 7955.330000] DRR: 00000000 SPCR: 02000031 RCR: 01840180 SRGR: 102F1700 PCR: 00000000
    [ 7955.440000] BUFF:
    [ 7955.440000] 0
    [ 7955.450000] 89464
    [ 7955.450000] 16734561
    [ 7955.450000] 110026
    [ 7955.450000] 16732889
    [ 7955.450000] 213111
    [ 7955.460000] 16732191
    [ 7955.460000] 365235

    So what I am doing here, is that in the davinci-pcm.c IRQ handler (davinci_pcm_dma_irq) I am printing out the first couple of frames, I achieve this by checking that the hwptr is equal to or less than the period_size, given that after an overrun the hwptr is reset to the beginning so it allows me to capture the start and an overrun. You can see that in the case of an overrun it begins with a zero where a left channel sample should be. Now when I first saw this I thought that I could compensate in our recording application and just ignore the zero and the next sample would always be the LEFT channel but unfortunately with subsequent tests this is not always the case.

    More often than not the codec will start OK and LEFT will be left etc. but there has been the odd case where it starts with the LEFT -> RIGHT swapped. When the Overrun occurs it re-initialises the Ping-Pong DMA, but obviously hw_params and the dai_fmt are not re-initialized, could re-initializing all registers of the McBSP fix our problems? Or when a RRST happens, is it ensured that it starts the same every time?

    Regards,

    Geoff

  • 0 in reply to GEOFFREY CLARK
    Prodigy 30 points

    Hi All,

    So it seems that this patch:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/252177/899064.aspx#899064

    Has solved our problems. Ran our device over the weekend and didn't experience any swapped channels from startup or on an overrun.

    So for the moment, until I see otherwise, it seems that this problem is solved.

    Thanks Renjith for your help!

    Regards,

    Geoff