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 underrun error during playback

CPU : Davinci DM6467

DSP: BIOS 5.41

OS : Linux 2.6.32

DVSDK: 3.10.0.16

Hi,

We are developing a set top box using Dm6467. The settop box can plays back DVB streams on a connected TV set.

The settop box supports both SD (Standard definition) and HD (Hi Definition streams). The SD streams are in H.262 video formats and HD streams are in H.264 video formats.

McASp is uses to transmit the audio data in I2S format.  We are playing back sound at 48 KHz sample rate.

While implementing the SD stream playback we observed that quite frequently the Sound_write routine would fail.  Upon investigation we observed that it was due to the fact that the XUNDRN bitwould get set in the the XSTAT register of the McASP.

Since we are using the EDMA to transfer data to the McASP it was clear that the EDMA was not transferring the data to the McASP within the time slot and hence the McASP would set the XUNDRN bit and would stop transferring data all together. Additionally since the McASP does'nt have the support to recover from the underrun condition the sound data transmission would fail.

Also it was observed that if only sound is playe but not video (which goes via the VPIF port) then there would be no glitches at all.

Upon investigation into the davinci_pcm driver we observed that EDMA Queue 0 was uses as transfer queue both  for McASP and also for other peripheral such as VDCE.

We changed the EDMA transfer queue for McASP to Event queue 1 after which the problem got solved and the we could see the SD video and audio playing quite well.

But now when we are implementing the HD stream playback we observe the same issue. The Sound_write fails due to XUNDRN condition bit getting set.

We are very sure that data is available to the McASP from the application side but some how the DMA fails

So the query is

1) Is it possible that the McASP DMA does not get hold of the system bus for transfer during the I2S time slot  and hence the underrun cindition occurs?

2) We also tried changing the bus priority of the Transfer queue related to McASP via the MSTPRI2 register but that dind help either.

3) For playing back HD streams the vpif clock was increased . Could this cause any problems?

4) Is it possible that the HDVICP peripherals occupy the system bus for such a long time that it causes underrun to occur in McASP.

 

Please let me know of any suggestions on the same

Thanks and Regards

Mohammed Anwar

 

 

 

  • Hello ,

     

    Update from Customer on the issue

     

     

    Please find the reply to the McASP queries

     

    Q) Does it recover? How long it plays well?

    A) With HD the audio plays only for a couple of seconds before the underrun occurs.

     

    Q) Does it work w/o Video being played back?

    A) Yes it works without video being played and is also mentioned in the query submitted on e2e

     

    Q) What is the priority of Video driver versus Audio?

    A) Which video driver and what component of video driver are you asking.

          If it is bus priority then the VPIF display driver is about the same priority as the McASP DMA channel

          Additionally we tried to increase the priority of the McASP DMA channel to the highest and yet the underrun occurs in 5 secs max.

     

    Q) What is the ARM loading, is it hitting 100%+ MIPS?

    A) The CPU utilization is certainly not 100%

     

    Q) Is there a conflict between the HD video driver ( or related changes) which will now conflict with McASP?

    A) There is no conflict that has been introduced for HD at least on the ARM side. I am not sure what is different on the DSP side though

     

    If you refer to the code in the davinci-pcm.c file it can be seen that when the DMA buffers are setup for McASP the DMA PaRAM set for McASP is linked to itself at the end of transfer.

    ie when the transfer ends and if the source start address of the PaRAM set is not updated the same buffer may play back again.

    So even if the application delays in sending the buffer, the McASP will not set the underrun bit since it could go ahead and playback the same buffer.

    On a DMA completion interrupt for McASP only the source start address is updated as can be seen in the davinci_pcm.c .

     

    Hence It can be safely concluded that delay in sending data from application can not be the cause of underrun in McASP peripheral.

     

    Hence it is necessary to look into the reason as to why the DMA does not start on McASP AXEVT even when the DMA buffers are properly setup

     

     Best Regards

    Feroz

  • From our past experiments int the McASP issue we observe that when decoding SD or HD video the DSP uses the EDMA extensively for its operation.

    We do know that there are four transfer controllers on the EDMA that can be used.
    Multiple EDMA channels could map to a same DMA transfer controller. In that case the transfer controller queues up the requests.

    What we have observed here is that during SD playback when the McASP operations are asigned to the EDMA transfer controller #1 the sound playback works quite well whereas the same fails for HD playback.

    Whereas when the McASP operation are assigned to EDMA transfer controller#2 then HD sound playback works fine but the same fails for SD video playback.

    Hence we suspect that the DSP uses different transfer controllers for HD and SD video decoding. Due to which they conflict with the McASP DMA requests and hence the McASP goes into underrun when its DMA request does not get fulfilled.


    Additionally we are not initiating any DMA operation explicitly from our application.
    What also we observe is that we never face a problem with analog playback since the DSP is idle in that case.

    Hence it would be good if we could know how the DSP is using the EDMA transfer controllers for its operation and if it is possible to keep one transfer controller out of the 4 controllers exclusively for McASP operation without causing any regression.

    Changing the frame rates didnt help.

  •  

    The configurable TC has been supported in the following release version,

     

    Version: 01.10.05.05

    Label : REL.200.V.H264AVC.D.HP.DM6467.01.10.05.05

     

    The release package is also available on the external downloadable web page with following link,

     

    http://software-dl.ti.com/dsps/dsps_public_sw/codecs/DM6467/index_FDS.html

     

    Note: In this release we have also supported reverse HD (1080x1920) resolution for one of the customer requirement. Due to this there is increase in external memory requirement for H264 decoder from 14MB to 24BM.


  • Hi,

    I added the codec 1.10.5.5 to the dvsdk folder under

    dvsdk_3_10_00_16/cs2dm6467_1_00_00_08/packages/ti/sdo/codecs.

    After building the codec server when I try to play the hd stream the codec fails to open.

    I havent made any changes to the DMA channels as yet.

    Please find attached the ce debug logs. Could you please tell me from the logs what could be the possible solution to the same0285.cedebug1.txt

    Thanks and Regards

    Mohammed Anwar

  • Mohammed,

    Your trace log shows this message:

    [DSP] @230,292,957tk: [+7 T:0x8e7005f4] ti.sdo.ce.alg.Algorithm - Algorithm_create> Algorithm creation FAILED; make sure that 1) alg params are correct/appropriate, 2) there is enough internal and external algorithm memory available -- check DSKT2 settings for heap assignments and scratch allocation

    But there is not enough information to indicate the problem.  I think we need to see DSKT2 trace to see what's going on.  Could you please add the following lines to your server's .cfg file to turn on framework components trace?

    • Set up GT
    var GT = xdc.useModule("ti.sdo.utils.trace.GT");
    var GTINFRA = xdc.useModule("ti.sdo.fc.utils.gtinfra.GTINFRA");
    GTINFRA.runtimeEnv = GTINFRA.NONE;
    GT.MALLOCFXN = "myMalloc";
    GT.PRINTFXN = "printfCaller";
    • Enable trace/debug for individual or all FC modules
    //Switch to debug + trace profile for all FC modules
    xdc.useModule('ti.sdo.fc.global.Settings').profile = "debug_trace";
     
    //Alternatively, to use debug profile for all FC modules, use this:
    //xdc.useModule('ti.sdo.fc.global.Settings').profile = "debug";
     
    //Switch on trace for some modules specifically.
    xdc.loadPackage('ti.sdo.fc.rman').profile = "debug_trace";
    xdc.loadPackage('ti.sdo.fc.edma3').profile = "debug_trace";

    You can find more on enabling trace in framework components here:

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

    Best regards,

    Janet

  • Hi Mohammed ,

    We now have almost the same issue of McASP underrun as yours: when there is no video running, audio works fine, when video is playing, McASP gets underrun about every 2 to 3 minutes.  So far,  there is only McASP uses EDMA on system. Our platform is a little different than yours, we use EZSDK on DM8168, but I think McASP architecture will be the same. How did you fix your problem ? We'll greatly appreciate your any reply, thanks!


  • Hi Yu,

    I think you should ensure there is no EDMA TC conflict between the McASP audio driver and the video H.264 decoder.  H.264 EDMA can be changed in latest versions...

    Please find the default TC EDMA used and change it to some non conflicting EDMA channel...

    Hope this helps!

    Best Regards

    Feroz

  • Hi Feroz,

    Thanks for your reply. If I don't run video decoder, just feed PCM samples to McASP, I don't get underrun, but if I run audio decoder which is on DSP C6747 using TI's Rpe architeture,  McASP still gets underrun.  It seems there is some EDMA or access memory conflict between DSP and A8. How can I know default TC EDMA used on DSP side ? 

    Best Regards!

    Yu

  • Hi YU,

    Unfortunately I am not aware of the audio decoder you are using? Who has provided you this code? Do you have source code? Please check with the provider and search in code for the EDMA TCs and CCs used and ensure these are not conflicting...

    There is no way to find it out run time where the settings are in the code. So you will have to check off line and check each module for its EDMA usage...

    Hope ths helps!

    Best Regards

    Feroz

  • Hi, can you fix the problem?

    can you share the resolution, thanks very much