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.

DMAPingPongComplete on audio example only firing twice?

Hi,


I've modified the wifi_audio_app to play pcm samples instead of streaming mic input of another board (I only own one). My problem is that the DMAPingPongCompleteCb is called twice before my audio processing task is started and then never again. is this normal behavior if buffer is empty? If so, maybe someone can point me to the place in example, where dma part is delayed until data is available?


Regard

Markus

  • Hi Markus,


    For loopback please refer following post e2e.ti.com/.../1379803


    Regards,
    Aashish
  • Thanks Aashish,

    good to know there is a single board test solution.

    Unfortunately, I can't see how this answers my question. Would you be so kind and are a bit more specific on the synchronisation part?

    What I do in processing task right now is:

    if(0 > (bufResult = FillBuffer(pRxBuffer, (unsigned char*)PcmData, bytesWritten))) {
    
      Shell_PrintLogMessage(SHELL_WARNING_MSG, "Unable to fill buffer [%d]", bufResult);
    
    }
    
    if(false == WaterMark) {
    
      if(IsBufferSizeFilled(pRxBuffer, PLAY_WATERMARK) == TRUE) {
    
        WaterMark = true;
      }
    
    }
    
    

    Nothing special here. Everything else should be the same as in the example, if I didn't made any copy & paste errors.

  • Hi Markus,


    If there is not enough data in buffer than zero is played as we need to feed data continuously on I2S interface. Refer DMAPingPongCompleteAppCB_opt() function, below is code snippet:

    if((pAudOutBuf->pucReadPtr == pAudOutBuf->pucWritePtr) || \
    (g_uiPlayWaterMark == 0))
    {
    pucDMASrc = &gaucZeroBuffer[0];


    So, DMAPingPongCompleteAppCB_opt() always be called even if there is no enough data in pRxBuffer.


    Regards,
    Aashish
  • Hi Aashish,
    that's the way I thought it would work :-(
    Any idea what I'm doing wrong, as the callback is definitely only called twice (one call for primary and one for alternative)? I don't use breakepoints, just fprintf to stdout.
  • Hi Markus,


    It will be easy for us to debug if you list out all changes you have done wrt SDK wifi_audio_app.


    Regards,
    Aashish
  • Thanks again Aashish for your help, here you are:

    - #if 0 the if(uDMAIntStatus() & 0x00000010) part in DMAPingPongCompleteAppCB_opt

    - insert a fprintf(stdout, "int 0x%08x\n\r", uDMAIntStatus()); below if(uDMAIntStatus() & 0x00000020)

    - Audio_Init:

    void AudioDriver_Init(void) {
    	int lRetVal;
    
        if(0 > (lRetVal = I2C_IF_Open(I2C_MASTER_MODE_FST))) {
            Shell_PrintLogMessage(SHELL_ERROR_MSG, "error I2C peripheral %d", lRetVal);
        }
    
        //_InitDac();
        ConfigureAudioCodec(0x00);
    
        McASPInit();
    
        UDMAChannelSelect(UDMA_CH4_I2S_RX, NULL);
        UDMAChannelSelect(UDMA_CH5_I2S_TX, NULL);
    
        SetupPingPongDMATransferRx();
    
        if(0 > AudioCapturerSetupDMAMode(DMAPingPongCompleteAppCB_opt, CB_EVENT_CONFIG_SZ)) {
            Shell_PrintLogMessage(SHELL_ERROR_MSG, "AudioCapturerSetupDMAMode");
        }
    
        AudioCaptureRendererConfigure();
    
        Audio_Start();
    }

    -  UDMAInit(); is still in main before everything else is started

    Hopefully I don't miss something...

  • I have the strange feeling that this is a fprintf/console problem, not a dma problem?! I had a look at the counter used in the code and they indicate that the function is called more than two times. Can anyone reproduce this behavior?

    Preferences->Run/Debug->Console->"Limit console output" is not checked in my case.

  • Hi Markus,

    Removed log messages from ISR ( DMAPingPongCompleteAppCB_opt) as it slow down the ISR and it miss the interrupts. Also since you running in debugger mode, please try to have less system(PC) load as it further low down the code execution.

    Regards,

    Aashish