Win UAC2 driver supports any channel count https://learn.microsoft.com/en-us/w...ivers#additional-information-for-oem-and-ihvs
and any samplerate https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/post-6725714
ASIO was created in the 90s when native windows audio was basically none and it has not been extended much since. Apart of DSD, the much later designed wasapi exclusive offers a superset of ASIO features.
I am not saying wasapi exclusive is ideal, e.g. I hit a major and useless obstacle in format multichannel mask when working on the wasapi exclusive javasound plugin new REW uses https://github.com/pavhofman/csjsou...e9322609ce028740259d/src/formats.rs#L117-L139 . I do not think a channel mask checked by the driver exists in other audio APIs. But that issue seems to have been resolved by now.
Yes, I absolutely agree. The question is if it's time to start doing something about it - e.g. by not limiting a non-DSD UAC2 device to ASIO only in new designs. If most non-DSD devices on the market support the win UAC2 driver (intentionally, not by chance), maybe more applications will add wasapi exclusive support and non-DSD device developers will eventually not have to fuss with a custom ASIO driver.
If I have developed a major DAW with many channels and lots of features and I have them all working with ASIO I'm not too interested in opening a new can of worms to support a different audio system. Consumer playback and audio measurements are pretty simple well defined use cases. 48 channels from several different devices that all need to cooperate would be a different troubleshooting task. I think its safe to say ASIO support will continue. Tools like Virtual cable make this less critical since it lets you shift between as needed.
Nick, do you have access to the non-disclosed docs for the Synopsis dwc2 implementation in RPi? The linux USB gadget dwc2/3 implementation is actively supported by Synopsis specialists who have access to all docs/know-how needed. complete knowledge of the dwc2/3 internals. Look at the linux-usb mailing list, kernel devels approach them for consultations on a regular basis. I had to address their dwc2 specialist when debugging a problem in the RPi USB gadget and was lucky to be provided with just one or two pages from their extensive docs. I found some dwc2 implementation specs for an Intel ARM chip, and the registers in RPi were different in that area. So you really need specs for that particular IP-core implementation. The dwc2 driver has been in development for at least 8 years https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/usb/dwc2?ofs=600 .
On top of the dwc2 gadget driver you will have to implement the UAC2 device protocol. Again one of your few know-how options is the linux kernel - also being developed for 8 years https://git.kernel.org/pub/scm/linu....git/log/drivers/usb/gadget/function/f_uac2.c - that's just the UAC2 layer on top of the general gadget layer (on top of the hardware dwc2 layer).
Or you can drop the raw RPi requirement and use one of the existing UAC2 implementations (e.g. SDR-widget). Or you can talk to local UAC2 implementers. E.g. what @bohrok2610 has done in STM32 all by himself is a truly amazing endeavour. And I would tend to estimate that going from STM32 to raw RPi doubles the complexity due to the much more complex and far less/worse documented raw HW.
On top of the dwc2 gadget driver you will have to implement the UAC2 device protocol. Again one of your few know-how options is the linux kernel - also being developed for 8 years https://git.kernel.org/pub/scm/linu....git/log/drivers/usb/gadget/function/f_uac2.c - that's just the UAC2 layer on top of the general gadget layer (on top of the hardware dwc2 layer).
Or you can drop the raw RPi requirement and use one of the existing UAC2 implementations (e.g. SDR-widget). Or you can talk to local UAC2 implementers. E.g. what @bohrok2610 has done in STM32 all by himself is a truly amazing endeavour. And I would tend to estimate that going from STM32 to raw RPi doubles the complexity due to the much more complex and far less/worse documented raw HW.
Just to explain - the Synopsis guys do not participate in the linux mailinglists just out of interest, but dwc2/dwc3 is the predominant USB IP-core in ARM SoCs and Synopsis customers (ARM SoC vendors) need the linux kernel to work correctly for android - both host and gadget modes. RPi running non-android linux distributions is a minority customer of theirs 
Actually dwc3 is present in small Intel mobile Atoms too and the USB gadget works perfectly on them too, e.g. on cheap Z8350 Atom tablets from Aliexpress with USB-C or even USB-A (with a hacked USB-A - USB-A cable).
Actually dwc3 is present in small Intel mobile Atoms too and the USB gadget works perfectly on them too, e.g. on cheap Z8350 Atom tablets from Aliexpress with USB-C or even USB-A (with a hacked USB-A - USB-A cable).
Last edited:
A good explanation. I spent this morning going through the codebase of circle in further depth and have just come back to this thread. Tracing through the IRQ, DMA channels etc, and it has support for the Broadcom 2711 SoC using both the linux OTG driver, firmware blob and other components but stripped down. Things like the cpu scheduler have a GNU licence and authored by the circle author. Essentially the author has cross-linked the kernel Synopsis USB OTG implementation into his framework. The biggest concern is the scheduling (both CPU and USB such as the adaptive isochronous aspects) with circle. Yet it builds a kernel image that is fast without too much developer work. So I can see you point (a) use the man power of the kernel tree and not reinvent the wheel plus (b) leave the proprietary work of the vendors behind the apis.
The other option is to strip down the kernel thus replicating the circle minimalism but maintaining the linux code base support. The issue for me is that the linux kernel (such as RPI's distributions) have simply become too bloated - so perhaps an option here is to look at the minimalist distributions. This then falls foul of the RPi support but Tiny Core Linux seems to be proactive supporting RPi. Like all non-commercial (include RPi in this) distributions the end is that they fall behind when faced with the linux behemoth commit rate. There's a reason RedHat and others have made it a successful business..
Previously I had looked at the STM32 and ST have documented this in detail vs Broadcom's emptying the metaphorical silicon trash can out for RPi's consumption (the 2711 documentation has three instances of the word USB).
The other option is to strip down the kernel thus replicating the circle minimalism but maintaining the linux code base support. The issue for me is that the linux kernel (such as RPI's distributions) have simply become too bloated - so perhaps an option here is to look at the minimalist distributions. This then falls foul of the RPi support but Tiny Core Linux seems to be proactive supporting RPi. Like all non-commercial (include RPi in this) distributions the end is that they fall behind when faced with the linux behemoth commit rate. There's a reason RedHat and others have made it a successful business..
Previously I had looked at the STM32 and ST have documented this in detail vs Broadcom's emptying the metaphorical silicon trash can out for RPi's consumption (the 2711 documentation has three instances of the word USB).
Last edited: