At the other end: MS maximal 384kHz SR, if more you need (or DSD native) to use ASIO and related MS ASIO driver validated by
The MS WASAPI UAC2 driver runs bitperfect at any samplerate in exclusive mode.
512kHz/32bits: https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg-5.html#post6719353
768/32: https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg-5.html#post6725023
3.9MHz/16bits (limited by max isochronous bitrate for USB2 without multipackets): https://www.diyaudio.com/forums/pc-based/342070-linux-usb-audio-gadget-rpi4-otg-5.html#post6725714
Last edited:
I have STM32F427 in one of my design, running at 768 kHz.
Did not tried this with F7 or H7, but hope is also should work.
Last edited:
It depends about what we are talking - chip power consumption or total board.
Let say - from 5V USB.
XMOS problem is 1.0v power supply, if linear regulator used, input current is high. But most STM als has internal 1-1.3V LDO for Vcore.
If to see to the chip itself, F7 has comparable with XMOS power consumption, while H7 has up to twice higher(!) than XMOS (XS1 and X200).
YES (after MS learned), thank you, while did not had yet any real UAC2 setup! 384kHz may in shared mode only do the resampling load.
Yeah but F7 cpu should be doing almost nothing so it'll just be the current draw of peripherals, DMA, etc... should be quite low, if you use WFI sleep mode. Could also set CPU clock to a very low frequency...
Last edited:
USB stack?
Will be the problems with peripherals.
But for what in this case you need F7?
I can understand F723 (because it has internal HS USB PHY), but other F7 - why not to use F3 or F4, with it's lower power consumption, if you in any case wants to run F7 with a lower clock?
During isochronous transfer, USB stack doesn't do much... there's only endpoint I/O and the occasional feedback packet for asynchronous mode. STM32F7 doesn't seem to support scatter/gather DMA, but it has a FIFO, so all the CPU should do is one interrupt per microframe, setup DMA to transfer from USB FIFO to RAM and from RAM to I2S peripheral...
I got negligible cpu use on cortex-M4 even at 8ch 192k 32 bit.
If it has to use a lot of CPU, then either it has the wrong hardware architecture and the CPU has to copy all the data, or it has the wrong software architecture like a dumb HAL layer that needlessly copies all the data, but at least that can be fixed going bare metal.
However... DMA on the M7 seems to be... problematic...
Yes the wasapi shared mode must provide resampling, offer samplerate selection to the user (thus hard-coded set of rates), etc. But the exclusive mode behaves closer to linux alsa hw device than to the rather inflexible ASIO.
IMO most UAC2 devices could be configured to support the MS stock driver, it takes "just" setting parameters in the USB descriptor in line with the very strict requirements of the driver (mostly undocumented, learnt by trial/error). And using explicit feedback endpoint (not implicit feedback like e.g. RTX6001 does) but that one is documented by MS.
Yes, I know. At my primary job we had a lot of problems with H7 DMA, especially when the D/I cache enabled. Also the memory areas distribution is terrible.
You can find plenty of non-issues regarding STM32 MCUs. That is a good example of such (written while listening UAC2 with DMA enabled) 😀
It is an issue with async UAC1 where the FB is 3-bytes.
Actually the USB related HAL stack is quite thin. I would not expext huge performance benefits if it was left out.
There are some applications where this is not exactly possible. One is SPDIF TX where the application needs to align the data with MSB at bit23.
Sorry for hijacking this thread with STM32 stuff. I'll create a new thread if and when my STM32F7 USB-I2S bridge gets finished.
diyinhk sells an XMOS-based USB board that can support 4-I2S inputs and 6-I2S outputs.
XMOS Multichannel high-quality USB to/from I2S/DSD SPDIF PCB 3W - DIYINHK
There is also an ASIO driver available for it, although don't know if it supports other than playback.
DIYINHK USB Audio Driver V4.67 [Full Version and Signed] - DIYINHK
XMOS Multichannel high-quality USB to/from I2S/DSD SPDIF PCB 3W - DIYINHK
There is also an ASIO driver available for it, although don't know if it supports other than playback.
DIYINHK USB Audio Driver V4.67 [Full Version and Signed] - DIYINHK
I wonder if the driver is licensed, I know the JLSound is. There’s no problem to download an unlicensed driver from the Internet.
Otherwise, there’s not much problem to adapt the XMOS audio demo board software source code.
Otherwise, there’s not much problem to adapt the XMOS audio demo board software source code.
If the device source code is available, why not modifying it to support the stock wasapi driver and no third-party driver is required?
From the diyink USB board link:
"5) Extreme diyer can use the onboard full size XSYS connector to program the xmos with their customized firmware to add more feature and function. (Please notes the item price includes only the hardware. For programming support, please refer to the xmos official website and xcore.com for question about xmos programming, the PCB portmap is shown in the item image)"
Also:
"*The usb audio source code can be downloaded from xmos.com and xcore.com."
"5) Extreme diyer can use the onboard full size XSYS connector to program the xmos with their customized firmware to add more feature and function. (Please notes the item price includes only the hardware. For programming support, please refer to the xmos official website and xcore.com for question about xmos programming, the PCB portmap is shown in the item image)"
Also:
"*The usb audio source code can be downloaded from xmos.com and xcore.com."
Last edited:
It is not, on both ends. The windows end is Thesys licensed, the XMOS end is available as binary only, not sure if access to the source code can be licensed. As far as I know, the diyhk source code is also not available. The statement is pretty vague, things may not be that simple, through that connector.
Last edited: