TMS320C5515: C5000 Connected Audio Framework issue

Hi Mark, 

Thank you for your reply.

>Are Ping Pong buffers being used?

I should be using it.

I only modified app_usbac.c for imported projects.
I think that the project that I'm evaluating is supposed to be the flow of data as below, is it right?

Figure:C:\c55_lp\c55_caf_02.00.02.04\doc\connected-audio-documentation.pdf, page.12

Because we are currently performing the recording operation, according to c55_caf_release_notes.txt, using ASRC requires the definition of ENABLE_REC_ASRC, but it seems that it is not defined by default.

Can it be solved by clearing the ping-pong buffer or Codec Input Buffer?
If so, would you tell me the procedure?

Regards,

U-SK

Hi Mark,

Thank you for your contact.

I look forward to your investigating result.

Regards,

U-SK

Hi U-SK,

I worked on C55x CAF a while back and will try to assist in resolving this problem.

The diagram you've shared for the record data flow is correct. By default, CAF is compiled for asynchronous synchronization in the record path, meaning any rate matching (e.g. digital resampling using ASRC) are performed on the PC. I don't think adding the ASRC into the record path will resolve the issue.

The Record I2S ping/pong buffers are defined in i2c_sample.c:

Uint16 ping_pong_i2sRxLeftBuf[2*I2S_RXBUFF_SZ]; /* 2x for ping/pong */
Uint16 ping_pong_i2sRxRightBuf[2*I2S_RXBUFF_SZ]; /* 2x for ping/pong */

Greping the code for these buffers:

$ grep -r -n --regexp="ping_pong_i2sRxLeftBuf" --include "*.c"
src/app_audio_alg.c:55: ptrRxLeft = &ping_pong_i2sRxLeftBuf[0];
src/csl_usb_iso_fullspeed_example.c:251: i2sInitPrms.pingPongI2sRxLeftBuf = (Int16 *)ping_pong_i2sRxLeftBuf;
src/csl_usb_iso_fullspeed_example.c:254: i2sInitPrms.pingPongI2sRxLeftBuf = (Int16 *)ping_pong_i2sRxLeftBuf;
src/i2s_sample.c:62:#pragma DATA_ALIGN(ping_pong_i2sRxLeftBuf, 2);
src/i2s_sample.c:63:Uint16 ping_pong_i2sRxLeftBuf[2*I2S_RXBUFF_SZ]; /* 2x for ping/pong */

From this, I observe there isn't any place in the code these buffers are cleared.

The SYSBIOS task for recording is named RecAudioAlgTsk(), and is defined in app_audio_alg.c. Looking through the code for this function, I observe:

/* Store data in circular buffer */
if (h_usb_int_tcount > 1) /* wait for IN tokens from Host */

The variable h_usb_int_tcount is the number of USB IN tokens received since recording was initiated.

Greping the code for this variable:

$ grep -r -n --regexp="h_usb_int_tcount" --include "*.c"
src/app_audio_alg.c:110: if (h_usb_int_tcount > 1) /* wait for IN tokens from Host */
src/app_usb.c:37:Uint16 h_usb_int_tcount = 0;
src/app_usb.c:250: if (h_usb_int_tcount < 2)
src/app_usb.c:252: h_usb_int_tcount++;
src/app_usbac.c:607: h_usb_int_tcount = 0;

Looking at Line 607 in app_usbac.c, I see h_usb_int_tcount is reset when recording is stopped. This occurs in the function appStopRecordAudio().
Is seems like this would be a good place to clear the Rx ping/pong buffers. This way they'll be cleared the next time recording is initiated.

Please let me know if this makes sense, and if it helps with the residual record audio you're observing.

Regards, Frank

Hi Frank,

Thank you for your reply.

I understand that I2C Ping Pong Buffer should be cleared to resolve issue.

I should add only reset_codec_output_buffer() in appStopRecordAudio() Function, right?

Do you need FLUSHFIFO process I added , too?

Regards,

U-SK

U-SK,

I noticed a previous thread that had a similar question on FLUSHFIFO.

e2e.ti.com/.../615996

If there are any data packets in the FIFO, indicated by the FIFONOTEMPTY bit (bit 1 of

PERI_TXCSR) being set, they should be flushed by setting the FLUSHFIFO bit (bit 3 of PERI_TXCSR).

Are you able to extract this information to see if indeed there are packets in the FIFO?

Lali

Hi U-SK,

You may want do the

    // reset codec input circular buffer
    memset(codec_input_buffer, 0, CODEC_INPUT_BUFFER_SIZE);

in appStopRecordAudio().

It seems the leftover of the previous recording in the codec_input_buffer was used for next recording.

The recording has to wait for a few frames (50% of the codec_input_buffer size) to start in order to avoid the racing condition.

Best regards,

Ming

Hi U-SK,

I mixed the actions of appRecordAudio() with that of the appPlayAudio(). It was the appPlayAudio which needs to wait for a few frames to prevent the underflow. I think the reset of the input circular buffer should fix the problem.

Let us know your test result.

Ming