USB Audio Device/Host Class 2.0 Middleware support?

[Joyabb]

Hi,

I am using STM32H743 nucleo board. I am looking to configure the USB interface as Audio Class 2.0 device. Is there any middleware available to achieve this?

Does STM has any plan to support Audio Class 2.0 middleware? Current middleware only supports Audio Class 1.0.

Thanks,

Joyab

[Piranha]

otherwise we'd have to waste many hours trying to patch the driver into HAL

---

So your goal is to create a broken unreliable firmware? Because, if you care for reliability, then you shouldn't use a broken bloatware at all. 

The Azure RTOS USBX stack itself most likely is not a broken bloatware. But ST's implementations of drivers, examples and CubeMX generated code for it is still based on the HAL. So you can rest assured that the broken HAL lock, broken state management, missing barriers and other "features" are still there and ready to break your firmware.

[AScha.3]

well, i didnt use/test it , just want to share, what i found.

and i was searching for ide and libs for ox64 : 4 cpu (riscV) cores, 64bit 480MHz,...AI unit, 100Gops, Wifi, BT, USB, SDIO, .... at $ 8 !!  (but almost useless without IDE and libs and examples...)

https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/

so i found this cherry-usb , seem to have audio host also:

https://github.com/CherryUSB/cherryusb_bouffalolab/tree/master/components/usb/cherryusb/class/audio

[Robmar]

Come on, no need to be so extreme, most of HAL works well and saves developers time.

The concept of automated code generation for standard items makes sense in saving the thousands of developers time, but clearly there are bugs in the IDE and package files that need to be tested, detected and fixed.

CMSIS 5.8.0 is one, if its selected MX fails to add all the necessary includes.  How on earth did that get released without anyone at STM bothering to check it compiled in new projects!?

STM may be a 16 billion dollar company, but the MCU section is not running as it should be by far.

[Piranha]

In the last sentence you are more extreme than me... ;) In my opinion ST's hardware is pretty fine! Not perfect, but has a good set of features, robust pin protection and physical quality, the parts conform to the datasheet specifications and have very long production longevity guarantee. The reference manual and application notes have some errors and could be improved, but they are by far not the worst ones of the industry in general. But on the software side ST is probably the absolute champion... at the worst end of the scale. 

CMSIS... The v5.9.0 was released more than a year ago, v5.8.0 more than a two years ago and, for example, for F7 ST is still shipping a v5.4.0 from a year 2018 even when it has a critical flaws in cache management functions and a fixed version was released with v5.5.0 in a year 2019. On the contrary I have been using the newest CMSIS code as soon as it is released and haven't had any notable problems with it. So how exactly the "help" from ST saves time?

If the code is not functionally correct, it is broken. That is not an opinion - it's how the logic works. The non-arguments like "it mostly works", "it didn't fail in my test" etc. are useless. One can have such an attitude, but then it is not an engineering. If the code has obvious flaws, there is no point in testing it. Only when all of the obvious flaws are fixed, then a proper testing can help in finding some non-obvious bugs. The HAL has hundreds if not thousands of obvious flaws and, before fixing those, there is no point in wasting a time on testing that code.

Good libraries is what saves time, not the code generation. Theoretically the HAL should save time, but in reality it's API and design is so stupid and implementation is so broken and bloated, that not only it doesn't save time, but it actually wastes time tremendously. Read this post and you'll see how HAL actually wastes your time because of it's stupid design. The difference in our reasoning about this is because you are comparing the HAL against nothing, but I'm comparing the HAL against a decent driver/library code.

[Robmar]

I've stepped through HAL in our fully functions DSP product, which has over 200K lines of our own DSP code, and from what I have seen it is well written and as efficient as any "baremetal" register-level code I have seen.

As we all know, STM MCUs have standard ARM CPU cores with a large array of peripheral devices from UARTS to SPI, I2C and LTDC blocks bolted on by STM.  My problems have come about through the inadequacies of STMCubeIDE and the packs, like CMSIS, which can be dropped in but then won't compile, which STM acknowledges is a problem on the 1.13.1 IDE with at least the H7 pack, that they have only now escalated for resolution, some 4 years after the first complaints.

Many developers have been left during these years to patch in CMSIS as best they can, a real time waster for scores of people, not a nice way to work really. That's my bug bear; STM need to invest more time resources in fixing these issues in my opinion. 

[AScha.3]

ok, i installed Azure rtos and enabled audio/host , on new H563-nucleo 144 board.

fine, compile, no errors. no work also. there is nothing, than set up , no enumeration, no functions are called, the name "audio host " is all.

looking at MS original Azure examples, this seems like a copy. But i didnt find a working example.

so how to find out, which functions to call, without  an example ?

Is there any working example from STM ?  i didnt find it. i might giving up now, to do any audio host with STM. 

[Robmar]

I've been discussing USB support with STM support for over a month as I also found no useful examples, and the USB middleware installed for the H7 is very incomplete.

Yesterday I was informed that STM hope to have the USBX UAC 2 driver for AzRTOS H7 ready by the end of this year, 2023, but it might slip to next year.

What surprised me was that STM haven't had a USB UAC 2 driver available long ago, as UAC 3.0 is already available.

It seems that the USB support is outsourced and STM staff haven't pushed it.  There seems to be a minimal investment in support software for their MCUs, which is a shame because if they hang around too long, the Raspberry market is liable to take much of STM's MCU market share as it is now heavily focusing on embedded IoT, industrial and AI.

[AScha.3]

full consent.

what i found so far:

in STM audio host :

so (if i am right) this can only connect to a headset, as is a demo for the H7..dk board. thats it.

and in Azure audio host:

so this might connect to most "typical" audio devices...  if you get it running !

because the state machine (or however its called) is empty:

so maybe (!) with a lot of searching and try and error can find some useful things...like:

we will see. :)

+ about the market: i think, the Raspberry or Arduino market is big, but not for industrial applications .

BUT  sooner or later other companies will ( or already do ) make very similar cpu , even pin and function compatible :    see Nuvotron F4 series or GigaDevice H723 ...

https://www.gd32mcu.com/en/download/0?kw=GD32H7

https://direct.nuvoton.com/de/numaker-m463kg

STM is not world market leader by law . :)

[Robmar]

Interesting, the GDI H7 has up to 3MB of flash, not bad at all, just a pity they couldn't double the RAM to 2MB!

I agree with you about the competition, ST need to move fast or they risk losing market share.  Mouser have just taken on the new Raspberry PI boards, which are industrialized with a lot of IO and full USB UAC 2 support, and of course AI is fully supported for IoT given it runs linux on the quad core A53 processor.  All it lacks is the 16-bit ADCs.

[Robmar]

Imen.D, it's now 2023 and STM are still working in USB 2.0 now only for RTOS, what are we meant to think about this?