Unexpected audio artifact in dev_audio_speaker_freertos example

[anton_glukhov]

Hello,

I'm testing dev_audio_speaker_freertos example for RT1010 evk board and it seems there is one weird abnormal event that brings tiny artifact into the audio stream. If you add simple PRINTF or another _marker_ into txCallback function (audio_speaker.c) then you can see that the following condition occur regularly during the normal stream:

    if ((g_UsbDeviceAudioSpeaker.audioSendTimes >= g_UsbDeviceAudioSpeaker.usbRecvTimes) &&
        (g_UsbDeviceAudioSpeaker.startPlayHalfFull == 1))‍‍

So, there is a small drift or non-synchronization between usbRecvTimes counter and audioSendTimes. In my case, usbRecvTimes counter goes slightly faster and catching up the audioSendTimes counter, which leads to the condition when DMA switches to the audioPlayDAMTempBuffer.  Here is the full function with PRINTF marker that I added:

static void txCallback(I2S_Type *base, sai_edma_handle_t *handle, status_t status, void *userData)
{
    sai_transfer_t xfer = {0};
    if ((g_UsbDeviceAudioSpeaker.audioSendTimes >= g_UsbDeviceAudioSpeaker.usbRecvTimes) &&
        (g_UsbDeviceAudioSpeaker.startPlayHalfFull == 1))
    {
     PRINTF("r\r\n");
        g_UsbDeviceAudioSpeaker.startPlayHalfFull      = 0;
        g_UsbDeviceAudioSpeaker.speakerDetachOrNoInput = 1;
    }
    if (g_UsbDeviceAudioSpeaker.startPlayHalfFull)
    {
        xfer.dataSize = FS_ISO_OUT_ENDP_PACKET_SIZE;
        xfer.data     = audioPlayDataBuff + g_UsbDeviceAudioSpeaker.tdWriteNumberPlay;
        g_UsbDeviceAudioSpeaker.audioSendCount += FS_ISO_OUT_ENDP_PACKET_SIZE;
        g_UsbDeviceAudioSpeaker.audioSendTimes++;
        g_UsbDeviceAudioSpeaker.tdWriteNumberPlay += FS_ISO_OUT_ENDP_PACKET_SIZE;
        if (g_UsbDeviceAudioSpeaker.tdWriteNumberPlay >=
            AUDIO_SPEAKER_DATA_WHOLE_BUFFER_LENGTH * FS_ISO_OUT_ENDP_PACKET_SIZE)
        {
            g_UsbDeviceAudioSpeaker.tdWriteNumberPlay = 0;
        }
    }
    else
    {
        xfer.dataSize = FS_ISO_OUT_ENDP_PACKET_SIZE;
        xfer.data     = audioPlayDMATempBuff;
    }
    SAI_TransferSendEDMA(base, handle, &xfer);
}
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

And here is the output from the serial terminal (audio stream was active all the time from the beginning):

[2020-07-19 01:07:58] Set Cur Mute : 0
[2020-07-19 01:07:59] Set Cur Volume : 1f00
[2020-07-19 01:07:59] Set Cur Mute : 0
[2020-07-19 01:07:59] Set Cur Volume : 2bc7
[2020-07-19 01:08:06] Set Cur Volume : 2bb8
[2020-07-19 01:08:06] Set Cur Volume : 2ba9
[2020-07-19 01:08:06] Set Cur Volume : 2b9a
[2020-07-19 01:08:06] Set Cur Volume : 2b7c
[2020-07-19 01:08:07] Set Cur Volume : 2b6d
[2020-07-19 01:08:07] Set Cur Volume : 2b5e
[2020-07-19 01:08:07] Set Cur Volume : 2b4f
[2020-07-19 01:08:07] Set Cur Volume : 2b40
[2020-07-19 01:08:07] Set Cur Volume : 2b30
[2020-07-19 01:08:07] Set Cur Volume : 2b21
[2020-07-19 01:10:49] r
[2020-07-19 01:13:32] r
[2020-07-19 01:16:16] r
[2020-07-19 01:19:00] r
[2020-07-19 01:21:44] r
[2020-07-19 01:24:27] r‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The issue here, that every time this event occurs the buffer of frames (audioPlayDataBuff) switches to the _tmp_ buffer (audioPlayDMATempBuff) with zero-values and it hearable on synthetic data, e.g. sine wave.

I did these tests on the OSX OS with USB 3.0 connector and external USB 2.0 HUB. In both cases the same result. The audio stream was a single long-term sound from an audio player.

Could you please try to reproduce this issue on your side and provide any feedback?

Best regards,

Anton

[danielchen]

Hi Anton:

Could you please let me know which SDK version you are using ? Did you modify the official demo?

I did a quick check on windows 10 and not found the artifact.

I will try to run this demo on Mac os.

Regards

Daniel

[anton_glukhov]

Hi Daniel,

I did a few more tests with OSX, Windows 10, and Raspberry Pi.

The version I used:

- MCUXpresso version 11.1.1 (Build 3241)

- The project I installed via main menu File->New->Import SDK Example

- The version of SDK: 2.6.0

Please see the screenshots with the details below.

The versions of OSs:

1. Windows home 10, version 1909, build 18363.959

2.  OSX Catalina 10.15.5

3. Raspberry pi. Raspbian: Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux

How I test:

1. Windows/OSX

   - Connect the board to the PC

   - Choose proper Audio device

   - Reset the board

   - Start stream (Spotify)

2. Raspberry pi

  speaker-test -t sin -r 48000 -c 2 -D hw:1,0

Here are logs from the serial port:

1. Windows:

Set Cur Volume : e06
Set Cur Volume : da7
Set Cur Volume : d49
Set Cur Volume : cee
Set Cur Volume : c95
Set Cur Volume : c3e
r
r
r‍‍‍‍‍‍‍‍‍

2. OSX

[2020-07-20 21:25:09] Init Audio SAI and CODEC
[2020-07-20 21:25:09] USB device audio speaker demo
[2020-07-20 21:25:09] Set Cur Volume : 1f00
[2020-07-20 21:25:09] Set Cur Mute : 0
[2020-07-20 21:25:10] Set Cur Volume : 1f00
[2020-07-20 21:25:10] Set Cur Mute : 0
[2020-07-20 21:25:10] Set Cur Volume : 2c17
[2020-07-20 21:27:57] r
[2020-07-20 21:30:41] r
[2020-07-20 21:33:24] r
[2020-07-20 21:36:08] r‍‍‍‍‍‍‍‍‍‍‍

3. Raspberry

[2020-07-20 21:57:28] Init Audio SAI and CODEC
[2020-07-20 21:57:28] USB device audio speaker demo
[2020-07-20 21:57:30] Set Cur Volume : 1f01
[2020-07-20 21:57:30] Set Cur Volume : 27e1
[2020-07-20 22:01:46] r
[2020-07-20 22:05:23] r
[2020-07-20 22:09:01] r
[2020-07-20 22:12:38] r
[2020-07-20 22:16:15] r‍‍‍‍‍‍‍‍‍

Additional notes. With all these tests I update MCUXpresso, install dev_audio_speaker_freertos example, and add one line with PRINTF call.

[danielchen]

Hi Anton:

Sorry I can't reproduce your issue on my side.   I added a PRINTF in the  txCallback.  Please see my picture.

My test SDK is :  SDK 2.8.    

IDE is MCUXpresso 11.2.0.

Could you please download the Latest SDK and test again?

If this issue still there, please send me your vedio files to me for reproduing?

Regards

Daniel

[anton_glukhov]

Hidanielchen@fsl,

I've installed the latest MCUXpresso and SDK 2.8. And tested on OSX and Windows machines. The same issue, which occurs every ~3-4 minutes. I also downloaded SDK as an archive and compiled it with gcc 8 and gcc 9. The same problem. Please find two links to the builds: one that was compiled with MCUXpresso 11.2.0 and SDK 2.8 and another one build from sources with SDK 2.8. Please, test it on your side and confirm that you have or have not this issue. Also, please share your build with me, I will try to test it on my laptop.

Dropbox - evkmimxrt1010_dev_audio_speaker_freertos.hex - Simplify your life 

Dropbox - dev_audio_speaker_freertos_compiled_from_sources.hex - Simplify your life 

Thank you!

Best regards,

Anton

[danielchen]

Hi Anton:

Yes, I can reproduce this issue which occurs every 3-4 minutes. I am analyzing this issue and will update you when I have some results.

Regards

Daniel

[anton_glukhov]

Hi danielchen@fsl‌,

do you have any update regarding this bug?

Best regards,

Anton

[danielchen]

I can see the PRINTF,  but I can not hear it. Do you have the error noise?

Regards

Daniel

[anton_glukhov]

It depends on the audio content, but yes I can hear it as pop noise. Please, run sine wave and you can easily hear this pop noise in the audio stream.

[danielchen]

Hi Anton:

Just an information that we will fix this issue in next release,  thank you very much for your feedback.

Daniel