Audio player test demo problem

Hi,

I'm using the DK-S7G2 demo board.
I have a problem with the audio demo program "s7_dk_guix_audio_player.zip" provided with the doc r30an0248eu0120-synergy-guix-audio-player.pdf

Description of the problem :

  • 1st TEST OK with a music from a USB key:
    - I'm doing START -> OK
    then
    - I make PAUSE and I do RESUME (repeated a hundred times very quickly) : it still works.

 

  • 2nd BAD TEST with music from a USB key:
    - I do START then I do STOP (instead of RESUME) (repeated a hundred times very quickly) : that freezes.

The program blocks on a "bufferAcquire" function with the following error:
"SSP_ERR_NO_MORE_BUFFER = 2000, /// <No more buffer found in the memory block pool"

I did the test with SSP 1.2.0-b1 and also in 1.5.3, the problem is still present.

I do not understand what's going on.

Regards,

Phil

  • Hi Phil-
    Which version of SSP and e2 studio are you using?

    Warren
  • In reply to WarrenM:

    Hi Warren,

    SSP = 1.5.3
    e2studio = 6.3.0

    Phil
  • Hi Phil,

    I created a support ticket for you. Your ticket number is 194091.
    Our engineer will get back to you soon.

    Thanks,
    RenesasRulz Forum Moderator
    Jennifer,
  • In reply to Phil:

    Hi Phil,

    Admittedly, this application example seems to have some issues, one of which you have outlined. You're not doing anything wrong on your end - the problem is with the code. audio_thread_entry waits for a message for about 10ms before checking if there's a space to allocate another audio packet. If there's a lot of things happening in the application this wait time will effectively be increased. If the rate at which you're sending audio playback requests exceeds the rate at which they're being processed, the queue will eventually be depleted and you will see this error message. This can be fixed relatively easily by replacing posting semaphore with posting a message from sf_audio_playback_callback. The "pend" function can then wait indefinitely (TX_WAIT_FOREVER) to get a message and respond to it with appropriate action.

    I recommend looking into simpler approach demonstrated in Simple Audio Playback example for DK-S1: www.renesas.com/.../D6002335.html

    Regards
  • In reply to Renesas Karol:

    Hi Karol,

    I do not think it's a timing problem.

    I bring you a clarification:

    It is not the audio buffer that crashes, but the command buffer.

    And only the post of the STOP command will crash the buffer.

    Here is the place in the "audio_thread_entry.c" file where the crash code:

     

    case SF_MESSAGE_EVENT_APP_CLOSE:
    {
     if (g_player_status.state == SF_AUDIO_PLAYBACK_STATUS_STOPPED)
     {
      /* API error: file is already closed */
      break; 
     }

     status = g_sf_audio_playback.p_api->stop(g_sf_audio_playback.p_ctrl);
     if (status)
     {
      // post error callback: unable to stop playback

      break;
     }
     g_player_status.state = SF_AUDIO_PLAYBACK_STATUS_STOPPED;

     // clear buffers
     memset(&g_file_buffer, 0, sizeof(g_file_buffer));
     memset(&g_actual_size, 0, sizeof(g_actual_size));

     status = fx_file_close(&g_file);
     if (status)
     { 
      // post error callback: unable to close file
     }

     /* App callback: status changed */
     status = g_sf_message.p_api->bufferAcquire(g_sf_message.p_ctrl,
                 (sf_message_header_t **) &p_cb_message,
                 &cfg_acquire,
                 TX_NO_WAIT);


     APP_ERROR_TRAP(status);

     p_cb_message->header.event_b.class = SF_MESSAGE_EVENT_CLASS_APP_CB;
     p_cb_message->header.event_b.class_instance = 0;
     p_cb_message->header.event_b.code = SF_MESSAGE_EVENT_APP_CB_STATUS;

     status = g_sf_message.p_api->post(g_sf_message.p_ctrl,
                 &p_cb_message->header,
                 &cfg_post,
                 NULL,
                 TX_NO_WAIT);


     APP_ERROR_TRAP(status);

     break;
    }

     

    Could you provide me with the modification you propose in the demo code?

    I do not understand how to implement this.

    Regards,

    Phil

  • In reply to Phil:

    Hello Phil,

    You can replace TX_NO_WAIT above the highlighted line with finite delay (e.g. 100 for 1 second). Alternatively you can go to the Configurator to increase amount of work memory in properties for sf_message module.

    Regards
  • In reply to Renesas Karol:

    Hello Karol,
    The problem persist even after setting TX_NO_WAIT to 100.
    If I increase the work memory (2048 to 4096 for example) the problem occurs after 200 tries instead of 100.
    How can I send you my project ?
    So you can reproduce the problem.
    I play a sound of a few seconds.
    I stop it while it is playing.
    I replaced the "pause" button with the "STOP" command
    Regards,
    Phil