USB Audio Class 2.0 host & device drivers

[raveslave]

I'd like to see USB-Audio Class 2.0 (UAC2) support

Advantages:

• Lower latency on MCU's with USB 2.0 High Speed support
• Increased channel count & higher sample-rates/bit-depths
• More flexible clock domains
• Better device descriptors to be able to present features

For instance the i.MX RT 1050 board has support for both USB HS, Host & Device.
Could perhaps be a good starting-board to add support for this? (NXP!?)

related: #12775

[MarkWangChinese]

@raveslave RT1050's USB device controller driver is in pull-request review The pull-request is: #12533

[raveslave]

@MarkWangChinese great to see this. Any plans to continue with Host support, as well as Audio Device 2.0?

[MarkWangChinese]

Hi @raveslave, there is no usb host support plan in Zephyr currently as I know, what do you think about putting NXP MCUXpresso SDK USB HOST stack to Zephyr? (it works as Zephyr's part in subsys directory or NXP's part in ext/hal directory).

[raveslave]

Even though I'd prefer if the host-support was a generic/native component in Zephyr, I'm totally fine with a NXP/i.MX RT specific host driver. As long as we can do "otg" device/host switching with dual usb-interfaces, we're good.

Would NXP be interested in doing this effort?

[benolayinka]

Hi @raveslave, there is no usb host support plan in Zephyr currently as I know, what do you think about putting NXP MCUXpresso SDK USB HOST stack to Zephyr? (it works as Zephyr's part in subsys directory or NXP's part in ext/hal directory).

Did anything come of this? This would be amazing

[carlescufi]

This requires #12386 first

[raveslave]

waking up this one, heard that nxp might be doing something around usb audio class, did it happen?

[MaureenHelm]

waking up this one, heard that nxp might be doing something around usb audio class, did it happen?

@dleach02

[dleach02]

NXP does not have any active development on this. The USB maintainer, @jfischer-no has a roadmap plan for USB which you can engage on to provide input: #42066

[raveslave]

thanks david, so until zephyr has native support, will NXP run the existing mcuxpresso USB stacks on the side?

[dleach02]

@raveslave,

First, I would still engage on the RFC ticket #42066 to provide input and feedback. This will help give the maintainer/collaborators some guidance.

The NXP mcuxpress USB stacks in the SDK are built on top of the FSL OS abstraction layer, used to enable porting to different OS’s. Today, the NXP SDK includes USB examples with this abstraction layer running baremetal (no OS) or with FreeRTOS.

There is a version of the OS abstraction to Zephyr in the NXP HAL but it is not complete (modules/hal/nxp/mcux/middleware/wireless/framework_5.3.3/OSAbstraction). You would need to expand this OSA to enable the OS abstractions needed by the MCUXpresso USB stacks in Zephyr. NXP’s focus with Zephyr is to enable Zephyr’s drivers, middleware and features on NXP’s broad portfolio, and that includes Zephyr’s native USB Device stack. Therefore, it is not currently a priority for NXP to port the MCUXpresso USB stacks to Zephyr.

As a reference, there is an old (closed) PR where I expanded the OSA to include features needed to enable the NXP BLE controller library for the KW41Z: #10384

This may need additional porting to enable the USB stacks.

[tmon-nordic]

Basic UAC2 device side implementation is pretty much there already. The #78262 adds High-Speed support which is the last major feature missing.

The things not implemented as of 2024-09-11 are:

• interrupt notifications
• Clock Selector
• Clock Multiplier
• Mixer Unit
• Selector Unit
• Feature Unit
• Sampling Rate Converter
• Effect Units (Parameter Equalizer, Reverberation, Modulation Delay, Dynamic Range Compressor)
• Processing Unit (Up/Down-mix, Dolby Prologic, Stereo Extender)
• Extension Unit
• non-PCM formats (MPEG, AC-3, WMA, DTS)

The missing features can be implemented later on a one-by-one basis in a (I hope) backwards compatible way due to the way UAC2 descriptors are generated from devicetree description. Each of the new features would need a new devicetree binding and corresponding child entry under zephyr,uac2 (UAC2 instance).