The 52840 usbd audio example, while the processing data in the main loop takes time more than 1ms, will lead to noise

[OPQ]

Hi,

I try sdk 17.02 nRF52840 usb audio demo, I want to achieve 48KHz stereo music play by a I2S DAC.

Because I need to compress data in main while(1) loop, I found that when processing data in the main loop takes time more than 1ms, will lead to noise.   I think this may caused by the code while (app_usbd_event_queue_process()) in while(1) loop ,could you please give some suggestions to achieve my goal.

Thanks for your time.

[ovrebekk]

Hi 

Is there any way to could split up your audio compression into smaller chunks, in order to ensure that the USB stack can be serviced in time?
As an example, assuming the compression is looping over a certain number of audio samples it might be possible to compress a smaller number of samples in each call to the library, and run while (app_usbd_event_queue_process()) in between. 

I believe there might be a way to have the USB operations run in interrupt context also, which would make them run ahead of any main processing, but this might have other side effects if there is a lot of USB activity. I will have to double check this internally and get back to you. 

Best regards
Torbjørn

[ovrebekk]

Hi again

I found the configuration setting I referred to earlier:

If you set APP_USBD_CONFIG_EVENT_QUEUE_ENABLE to 0 in sdk_config.h and rebuild the example all the USB processing should happen in interrupt context. 

Please note that you have to remove any references to app_usbd_event_queue_process() in the code, as this function will no longer exist when APP_USBD_CONFIG_EVENT_QUEUE_ENABLE is disabled. 

Best regards
Torbjørn

[OPQ]

Hi Torbjørn,

Thanks for your reply.

I had try remove app_usbd_event_queue_process() and set APP_USBD_CONFIG_EVENT_QUEUE_ENABLE to 0 in sdk_config.h and rebuild , but its no usb event happen anymore.

BRs and Thanks

[ovrebekk]

Hi

I tried it out myself and see the same problem. I asked the developer about this, and he didn't have any immediate theories what is going wrong, so they would need some time to look into it. 

I will add a formal request so we can figure out what is happening, but in the mean time it might be useful if you can try to find a workaround that doesn't require setting APP_USBD_CONFIG_EVENT_QUEUE_ENABLE  to 0 as we discussed before. 

Best regards
Torbjørn

[ovrebekk]

Hi 

After looking into it the developer found a workaround that seems to solve the issue. 

All you have to do is add the following line to the handling of case APP_USBD_EVT_DRV_SOF: inside the usbd_user_ev_handler(..) function in main.c:

hp_sof_ev_handler(0);

The whole function should then look something like this:

static void usbd_user_ev_handler(app_usbd_event_type_t event)
{
    switch (event)
    {
        case APP_USBD_EVT_DRV_SOF:
            hp_sof_ev_handler(0);
            break;
        case APP_USBD_EVT_DRV_SUSPEND:
            bsp_board_leds_off();
            break;
        case APP_USBD_EVT_DRV_RESUME:
            bsp_board_led_on(LED_USB_RESUME);
            break;
        case APP_USBD_EVT_STARTED:
            bsp_board_led_on(LED_USB_START);
            break;
        case APP_USBD_EVT_STOPPED:
            app_usbd_disable();
            bsp_board_leds_off();
            break;
        case APP_USBD_EVT_POWER_DETECTED:
            NRF_LOG_INFO("USB power detected");

            if (!nrf_drv_usbd_is_enabled())
            {
                app_usbd_enable();
            }
            break;
        case APP_USBD_EVT_POWER_REMOVED:
            NRF_LOG_INFO("USB power removed");
            app_usbd_stop();
            break;
        case APP_USBD_EVT_POWER_READY:
            NRF_LOG_INFO("USB ready");
            app_usbd_start();
            break;
        default:
            break;
    }
}

I confirmed that with this fix the audio callbacks started running again. 

Please note that using the USBD audio class in this way has not been properly tested, and there could be various reliability issues. 

The developer strongly recommended trying to shorten the main processing in order not to have to run the USBD audio class in interrupt mode, as a more reliable option in the long term. 

Best regards
Torbjørn