https://www.xmos.com/application-notes/
Firmware AN02019
Bridge AN02003
SRC AN02034
ADAT AN01004
But do you need a full developer rig or can firmware be tested "easily" by exporting firmware via USB on a Amanero "clone"
By easily I mean like a ADAU14xx. Or is it more difficult like a MCU
Firmware AN02019
Bridge AN02003
SRC AN02034
ADAT AN01004
But do you need a full developer rig or can firmware be tested "easily" by exporting firmware via USB on a Amanero "clone"
By easily I mean like a ADAU14xx. Or is it more difficult like a MCU
Thanks, yes the tiles.
I was thinking more of the amount of deployment hazle.
Are a development board mandatory to get anyway trying to code a xmos.
Or is the simulation so good that all can be done in software and pushed to hardware without much debugging and probing
I was thinking more of the amount of deployment hazle.
Are a development board mandatory to get anyway trying to code a xmos.
Or is the simulation so good that all can be done in software and pushed to hardware without much debugging and probing
XMOS chips can be locked. IIRC, diyinhk.com used to sell a USB board with an unlocked XMOS chip but no longer does. Maybe too many problems from users. So, you might need to make your own evaluation board or see if XMOS sells one.
Also, there is a site with some support information: https://www.xcore.com/index.php
Regarding the difficulty of coding, XMOS standard source code versions are available from XMOS for registered users. How much trouble they are to modify and get working depends on the particular change desired.
The biggest problem for me is that full featured XMOS drivers for Windows which are reliable all come from Thesycon, the company MS hired to design the Windows sound stack. Thesycon drivers for custom/optional features (anything more than basic stereo) require a paid license. Minimum number of seats last time I checked was 2,000. That's a lot of licenses to pay for if you are not making many thousands of USB boards.
However, in theory it is now possible to use WASAPI Exclusive Mode drivers without paying Thesycon although I am not aware of there being a well known, general purpose, open source way to do it that works. One of the problems is that WASAPI Exclusive Mode can carry DSD using DoP protocol but it requires twice the bandwidth and thus twice the clock frequencies in USB boards (as opposed to Native DSD over ASIO). For working ASIO drivers, its back to having pay Thesycon.
The above is based on the last time I looked into some of the issues myself, which was some time ago. Could be there are some newer developments I have not taken into account. If so, maybe someone else will chime in with an update, particularly on the Windows driver issues.
Also, there is a site with some support information: https://www.xcore.com/index.php
Regarding the difficulty of coding, XMOS standard source code versions are available from XMOS for registered users. How much trouble they are to modify and get working depends on the particular change desired.
The biggest problem for me is that full featured XMOS drivers for Windows which are reliable all come from Thesycon, the company MS hired to design the Windows sound stack. Thesycon drivers for custom/optional features (anything more than basic stereo) require a paid license. Minimum number of seats last time I checked was 2,000. That's a lot of licenses to pay for if you are not making many thousands of USB boards.
However, in theory it is now possible to use WASAPI Exclusive Mode drivers without paying Thesycon although I am not aware of there being a well known, general purpose, open source way to do it that works. One of the problems is that WASAPI Exclusive Mode can carry DSD using DoP protocol but it requires twice the bandwidth and thus twice the clock frequencies in USB boards (as opposed to Native DSD over ASIO). For working ASIO drivers, its back to having pay Thesycon.
The above is based on the last time I looked into some of the issues myself, which was some time ago. Could be there are some newer developments I have not taken into account. If so, maybe someone else will chime in with an update, particularly on the Windows driver issues.
As of the driver. They write:
Since version 10, release 1703, Windows natively supports USB Audio Class 2.0 – no driver install is required.
Earlier Window versions only provides support for USB Audio Class 1.0. To use a USB Audio Class 2.0 device under these Windows versions requires a third party driver.
Developers may also wish to use a third party driver for reasons including:
Since version 10, release 1703, Windows natively supports USB Audio Class 2.0 – no driver install is required.
Earlier Window versions only provides support for USB Audio Class 1.0. To use a USB Audio Class 2.0 device under these Windows versions requires a third party driver.
Developers may also wish to use a third party driver for reasons including:
Se the normal way of getting firmware/code into chip is via a xTAG. So kind of like other MCUs. So not that low developer learning threshold then. And looks like a development board are needed to get friendly with the platform
Yes, but IMHO there is a problem with that in the default case. You can't easily avoid processing by Windows Sound Engine. It can crappily resample your audio stream in real time without any warning, and even if you tell it not to it may do it anyway. Even if you think you have it set up correctly, if there is a Windows Update and or if you plug the sound card device into a different USB connector it will probably default to resampling by Windows Sound Engine.
The MS answer to those issues (the special case, as far as MS is concerned, where pristine sound is a priority), is to use WASAPI Exclusive Mode. Or else you can use ASIO (a sorta open source high performance audio interface designed by Steinberg to get around the MS issues: https://en.wikipedia.org/wiki/Audio_Stream_Input/Output ).
Regarding people building their own diy sound cards, I am not aware of any who have fully solved the problem of figuring out how to use WASAPI Exclusive Mode for general purpose use. However, there may have been some progress with the folks making "gadgets."
Again, maybe someone will chime in with some additional and or updated information.
Last edited:
There is no need to build WASAPI exclusive drivers for sound cards. WASAPI exlusive can be used if the application using the sound card supports it. E.g. Foobar2000 and HQPlayer support WASAPI exclusive. In Linux even native DSD does not require any drivers.
I've tried to do couple of things with XMOS and, well, it works. It is an UAC2 device so no need in drivers in Windows 10 indeed.
There were couple of issues with their source code but I assume that now situation should be better as they released newer versions.
I even used XMOS to debug couple of things while working on York (https://www.diyaudio.com/community/...tichannel-input-output-interface-york.413504/)
Coding for XMOS is a bit different from regular MCUs, there are things like streams between tiles and honestly I do not remember much of details as it was ~5 years ago.
I preferred PIC32MZ over XMOS mostly due to availability at a time.
@torgeirs what is your goal?
There were couple of issues with their source code but I assume that now situation should be better as they released newer versions.
I even used XMOS to debug couple of things while working on York (https://www.diyaudio.com/community/...tichannel-input-output-interface-york.413504/)
Coding for XMOS is a bit different from regular MCUs, there are things like streams between tiles and honestly I do not remember much of details as it was ~5 years ago.
I preferred PIC32MZ over XMOS mostly due to availability at a time.
@torgeirs what is your goal?
Given that HQ Player, etc., can do WASAPI Exclusive Mode, is anyone building their own USB boards now able to handle playback of DSD using WASAPI Exclusive Mode? It would be great if that's the case.
Being able to record DSD to a file would be fantastic!
Also, what does it take to send volume control commands to a dac over USB? Are diy USB boards currently supporting this too?
If yes, to all the above, it looks like diy USB interfaces are finally getting up to the professional level.
Regarding Linux and or MacOS, IIUC drivers (or else overlays) are included in the OS distributions. I seem to recall Allo getting its Katana driver added to linux distibutions.
Being able to record DSD to a file would be fantastic!
Also, what does it take to send volume control commands to a dac over USB? Are diy USB boards currently supporting this too?
If yes, to all the above, it looks like diy USB interfaces are finally getting up to the professional level.
Regarding Linux and or MacOS, IIUC drivers (or else overlays) are included in the OS distributions. I seem to recall Allo getting its Katana driver added to linux distibutions.
Last edited:
Excellent. What if it is desired to pre-attenuate the dac PCM input in the OS by 6dB in order to prevent intersample overs, and or in order to help avoid higher levels of HD observed near 0dBFS? Then the remaining volume control should be done later in the dac chip's internal volume control? Doing something like this might turn out to be rather handy.
My goal is multichannel syncronized bitstreams out.
And only 2 need to be high sample frequency, the others should be downsampled, but still in sync with high FS channels.
Then ADAT, TDM or synced I2Ss for downsampled streams. I2S 192k or higher for the other two.
Input from USB is typically from Camilla DSP and 1 sample frequency.
Maybe some superlow samplefrequency FIR filtering on some streams.
Like the ADAU line I like the deterministic nature of the XMOS line. Much easier to get sync between streams when using deterministic hardware.
And only 2 need to be high sample frequency, the others should be downsampled, but still in sync with high FS channels.
Then ADAT, TDM or synced I2Ss for downsampled streams. I2S 192k or higher for the other two.
Input from USB is typically from Camilla DSP and 1 sample frequency.
Maybe some superlow samplefrequency FIR filtering on some streams.
Like the ADAU line I like the deterministic nature of the XMOS line. Much easier to get sync between streams when using deterministic hardware.
For me the high sample frequency part is only to preserve analog source noise captured with high bandwith ADC.
Think 'distorting old guitar amp - DSP - old amp' chain. The HF distortion is important because it can be folded back in normal hearing spectrum in amp.
Think 'distorting old guitar amp - DSP - old amp' chain. The HF distortion is important because it can be folded back in normal hearing spectrum in amp.
There are several ways to do this. If the USB board provides UAC2 volume controls Windows volume slider just sends volume control requests but does not actually do anything to the sample stream. USB board can then either do the volume control itself if input stream is PCM or send volume control commands to DAC chip. It is rather amusing to see the volume number spin on my DAC display when Windows volume slider is used. Another option is to use other USB interfaces for this (e.g. HID) and implement a custom control panel for Windows. I have implemented both options to my STM32 based USB boards.
There are actually 5 different ways to control the volume of my DAC: source (player) volume control, OS volume control (e.g. Windows volume slider), HID, volume knob on DAC, IR remote.
Last edited:
All it takes is just correct support in the application, no work on the device side.
The windows UAC2 driver works fine, just the device UAC2 stack must be tested as the driver is quite strict/unforgiving and some UAC2 specifications are rather loose.
Also there are some limitations in the Windows UAC2 driver. Those are listed here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers
One of the limitations is the lack of support for raw data format which greatly complicates native DSD support.
Does the windows mixer send the requests when an app uses wasapi exclusive too? A rather nice description at https://learn.microsoft.com/en-us/windows/win32/coreaudio/volume-controls suggests it does, via the Device slider which should be using IAudioEndpointVolume API.
While the UAC1/2/3 formats specify Type I/II Raw Data (bmFormats D31), DSD is officially specified only in UAC3 (bmFormats D5 for Type I and IV).
Also, even if the MS UAC2 driver supported the raw data for DSD, there is no raw nor DSD-specific format available to use in WASAPI calls https://github.com/tpn/winsdk-10/blob/master/Include/10.0.14393.0/shared/mmreg.h#L2107 .
Since DSD is not standardized in UAC1/2, the linux driver has to code support for each DSD device specifically https://github.com/torvalds/linux/b...f55e33be5bca5c/sound/usb/quirks.c#L1975-L1982 , e.g. this commit https://github.com/torvalds/linux/commit/c84bd6c810d1880194fea2229c7086e4b73fddc1 submitted 2 months ago.
IMO we will have to wait for UAC3 for standardized DSD. But while linux has had support for UAC3 for a few years, there is no UAC3 DSD format defined yet either https://github.com/torvalds/linux/blob/master/include/uapi/linux/usb/audio.h .
Last edited: