Reducing latency of High Speed USB for an Audio 2.0 device

[dykwong]

We have been learning about various modules on the i.MX RT1020 processor, hopefully to gain sufficient knowledge to build commercially competitive products. Primarily we do it by studying the corresponding examples included in the MCUXpresso SDK.

We are initially developing USB audio peripheral devices (e.g. microphones and speakers). Like most modern peripheral audio devices, we are targeting USB Audio 2.0 with high speed isochronous transfers.

We use the example project "usb_device_composite_hid_audio_unified" as the starting point, and enabled USB Audio 2.0 by setting USB_DEVICE_CONFIG_AUDIO_CLASS_2_0 to 1 in usb_device_config.h. The project compiled and ran successfully.

Then we captured the USB device descriptor and compared it against commercial a brandname USB microphone. We found that a key difference in the polling interval of the isochronous endpoint (bInterval). In the commercial microphone, it is set to 1, i.e. every microframe contains an isochronous packet, whereas the SDK example is set to 4 (as defined by HS_ISO_IN_ENDP_INTERVAL in usb_device_descriptor.h) with 8 microframes per isochronous packet.

While the SDK example is functional, we understand that less frequent polling would mean a higher latency. We have attempted to change HS_ISO_IN_ENDP_INTERVAL to 1, but the audio samples delivered to the PC became corrupted.

We are curious to find out if there is any inherent limitation of the USB stack in the SDK to support polling every 125us.

Many thanks!

[jingpan]

Hi @dykwong ,

The interval will not have too much latency. Do you think 125us*4=0.5ms is important to your project?

The interval is related to data transfer rate. If you only set the bInterval from 4 to 1, it then need x4 data to be send. If there is enough data ready, that will have problem.

Regards,

Jing

[dykwong]

Thank you, @jingpan .

As other existing products in the market are already capable of low latency (bInterval=1), we aim to perform equally or better.

If the USB stack on the i.MX RT1020 platform is incapable of comparable performance, perhaps it is the wrong platform for us.

Regarding the need to "send x4 data", please clarify the meaning.

According to the USB standard, "bInterval" is the polling interval for interrupts on isochronous endpoints. For a High Speed device, it is expressed as the number of 125us microframes. When bInterval is 4, this equates to 2 ^ (4 - 1) = 8 microframes per interrupt, which is 1ms.

We don't see how that controls the quantity of data transfer.

Please forgive our lack of knowledge of the i.MX RT10x0 platform.

[jingpan]

Hi @dykwong ,

It's hard to believe that the USB descriptor in RT1021 SDK audio demo is same to your competitor's, just different in bInterval.

When we talk about audio, there is many critical parameters, like sample rate, channels, width, buffer depth, format and so on. For example, when bInterval is 1, it may because USB transfer 1/8 of data each time.

So I think you should make a further investigate of competitor's product and USB Audio protocol.

Regards,

Jing

[dykwong]

Thanks for the quick response, @jingpan .

Yes, you are correct that the "usb_device_composite_hid_audio_unified" example project in the SDK has many differences from other commercially competitive products. But, as an example project, it has done well in educating my team about the i.MX RT10x0 platform.

In fact we have already successfully upgraded the sample rates.

As for the sample bit width, two months ago we raised another question in the community forum and received helpful hints from @PabloAvalos , and now it's resolved.

We have now reached the stage to consider latency. We have already suffered a number of initial unsuccessful attempts detailed at the top. That is why we have raised our hand to seek expertise from the community about the capability of the USB stack to support polling every 125us.

Whether we can relax the specification on latency is not the question here.