Any solution for XMOS (ASIO) drivers on Windows?
Can anyone share a more current driver version?
The only one available is this v3.34 from 2016? 😓
Anyway... I just want to be able to use my own projects, I have no commercial interest in it. Sad.
Can anyone share a more current driver version?
The only one available is this v3.34 from 2016? 😓
Anyway... I just want to be able to use my own projects, I have no commercial interest in it. Sad.
diyinihk has an XMOS based USB board with an optional paid driver for Windows that supports ASIO, and possibly supporting WASAPI Exclusive Mode.
Other people have been working on getting WASAPI Exclusive Mode to operate with RPi as a USB gadget.
Either ASIO or WASAPI Exclusive can be used for DSD and for bit-perfect PCM. However getting ASIO working as intended for PCM may require some other 'sound device' to serve as 'Default Sound Device' and or 'Default Communication Device.' Otherwise Windows may resample ASIO PCM streams without warning.
Other people have been working on getting WASAPI Exclusive Mode to operate with RPi as a USB gadget.
Either ASIO or WASAPI Exclusive can be used for DSD and for bit-perfect PCM. However getting ASIO working as intended for PCM may require some other 'sound device' to serve as 'Default Sound Device' and or 'Default Communication Device.' Otherwise Windows may resample ASIO PCM streams without warning.
hi, thanks for your reply.
well... I design my boards and it works very well on MacOS. *4 out / 2 in
Why should I buy from a manufacturer? Just to acquire the drivers?
1 - If I buy diyinhk drivers or from another manufacturer, can I use them on my boards?
2 - WASAPI in exclusive mode has low latency as ASIO?
3 - In Windows 11 the native UAC2 driver was updated? Or is it the same one present in current builds of Windows 10?
WASAPI Exclusive Mode is Microsoft's answer to ASIO, so far as I can tell. It can bypass all the MS Audio Engine stuff that resamples and thus degrades your PCM audio. Not sure how latency compares to ASIO.
As was pointed out to me, UAC2 is technically one layer of the Windows audio stack. Whether or not Windows messes with the digital audio stream has to do with some other layer or layers of the stack. IIUC UAC2 is still the same. Maybe @bohrok2610 and or others would be willing to chime in. IIRC @phofman may have some useful info on it too.
As was pointed out to me, UAC2 is technically one layer of the Windows audio stack. Whether or not Windows messes with the digital audio stream has to do with some other layer or layers of the stack. IIUC UAC2 is still the same. Maybe @bohrok2610 and or others would be willing to chime in. IIRC @phofman may have some useful info on it too.
Last edited:
What do you expect to get in the new driver that is not in the old one?
Hm, I'm still use 2.26 and 3.20
Yes, if you will use the same USB PID&VID (you can find it in drivers .ini file)
I've taken the decision to try to make a bare metal RPI no frills USB-i2S bridge supporting AC2. I have developed USB apps at a driver level and the firmware for cypress FX across linux and apple. I've also programmed Arm (and Blackfin) assembler/C/C++ on embedded bare metal before. So the idea is that the RPI zero will be dedicated to provide through buffering with an external master clock for the ADC using PCM/i2S and isochronous transfers.
My plan of action:
1. The RPI as a USB device.
2. The RPI as a USB AC2 device and support input streams at a fixed 192K 32bit.
3. The RPI to DMA data in from the PCM (ADC) at a fixed 192K 32bit.
4. The RPI to buffer and connect up
Probably later (much later)
5. Clock switching
6. DAC direction - if I ever need this direction.
My plan of action:
1. The RPI as a USB device.
2. The RPI as a USB AC2 device and support input streams at a fixed 192K 32bit.
3. The RPI to DMA data in from the PCM (ADC) at a fixed 192K 32bit.
4. The RPI to buffer and connect up
Probably later (much later)
5. Clock switching
6. DAC direction - if I ever need this direction.
The latest REW version already supports WASAPI exclusive https://www.avnirvana.com/threads/v5-20-12-v5-20-13-release.11029/ . I am surprised nobody asks/cares about how XMOS supports the stock UAC2 driver available in every windows installation. Stock ASIO e.g. does not support different playback/capture devices - either resulting in buffer misses with ASIO4ALL shim https://www.audiosciencereview.com/...ds/best-spec-adc-chip-currently.13469/page-16 or needs to be hacked around https://www.diyaudio.com/community/threads/diana-a-software-distortion-analyzer.315785/post-7121977
Do you surprised how XMOS supports built-in drivers in MacOS, Linux, Android ?🙂
BTW, regular XMOS driver - made by Thesycon.
Windows UAC2 driver is is the same Thesycon driver with limited features.
I do not see any problems with XMOS devices in the linux kernel (= android too). No experience with MacOS.
My point is - why XMOS users (= device implementers) do not strive for windows UAC2 compatibility of their devices and always look at ASIO only, if getting and maintaining the ASIO driver for their device is quite difficult/costly? I have not developed an XMOS firmware but from what I read there is some flexibility in the process. I do not see implementers asking "hey, how can I make may device compatible with the windows UAC2 driver?". But maybe I am just not looking at relevant sources (and the fact is I do not need to as my target device platform is not XMOS).
My point is - why XMOS users (= device implementers) do not strive for windows UAC2 compatibility of their devices and always look at ASIO only, if getting and maintaining the ASIO driver for their device is quite difficult/costly? I have not developed an XMOS firmware but from what I read there is some flexibility in the process. I do not see implementers asking "hey, how can I make may device compatible with the windows UAC2 driver?". But maybe I am just not looking at relevant sources (and the fact is I do not need to as my target device platform is not XMOS).
There is a free XMOS stereo UAC2 driver. It just doesn't support WASAPI Exclusive Mode, more than 2-channels, ADC input, DSD, hardware volume control, etc.
Maybe they want ASIO, Native DSD, multichannel?
Maybe I missed something? Where?
Because it is compatible with Win UAC2 driver. Driver is required for ASIO (see above) and it's features (including firmware update).
Apparently XMOS used to have a free one, but now its built into Windows.
"We no longer provide a Windows Stereo UAC 2.0 Driver for customers of our USB Audio 2.0 designs since Windows 10 supports USB Audio Class 2.0 natively."
https://www.xmos.ai/software/usb-audio/driver-support/
https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers
Yes, but that was in the past - XMOS provided the Thesycon driver with limited features (ASIO, but without multichannel and some other features) to those who bought their processors for $1000 .
Some are compatible, some not (e.g. RTX6001 is XMOS-based but cannot run under Win UAC2 driver properly because it uses implicit feedback, not supported by that driver).
For features - Win UAC2 supports standard UAC2 volume, mute, and AGC https://learn.microsoft.com/en-us/w...rs#class-requests-and-interrupt-data-messages .
No mention of volume or mute in ASIO SDK pdf.
For firmware update - it's not part of the audio functionality, could be provided by user-space libusb (as a joint open source project, e.g.)
For DSD - yes, that's not present in the Win UAC2 driver because there is no DSD in the UAC2 standard. Linux alsa has DSD "hacked" into its UAC1/2/3 driver and devices with DSD must be added to a whitelist https://elixir.bootlin.com/linux/latest/source/sound/usb/quirks.c#L1582
I am not saying to stop using the ASIO drivers, but if UAC2 device implementers started looking at the native method present in all windows installations and not be stuck with ASIO only, it may make their life easier in the long term.
It is ONE #define in the source code....
In any case, Native DSD is possible with ASIO only.
Linux kernel based systems, or MacOS = Full UAC2 support (Any implemented functionality will be detected by the OS).
Windows WASAPI = limited (only 2 channels, etc..)
That's why ASIO exists, to provide complete support on Windows.
It's not up to the device developer to implement native Windows functionality, that's up to Microsoft. 😀
Unfortunately dependent on ASIO.
The XMOS libraries are constantly updated, the driver needs to keep up with this development as well as support for current Windows builds and, of course, the ASIO SDK.
****See the revision history of the last 5 years in Attach files.
I need to test this, without much hope, but I'm going to do it today. thanks! 😊
Part of the problem is that the Windows native audio APIs were a mess for a while, so many existing applications rely on ASIO.
This just confirms what I am talking about. It may take little to be compatible, but that little needs to be done.
To avoid misunderstanding - RTX6001 was just an example, it's a legacy device, there was no windows UAC2 driver at that time, Jens was at a very different situation at that time.
Yes, that is the case. I.e. all non-DSD devices (e.g. all the measurement ones) have the option.