I think XMOS gives you one good thing - almost guaranteed compatibility with stock UAC 2.0 drivers, especially on Windows 10. The reason I say that is because Thesycon actually wrote the Windows 10 UAC2 driver and licensed it to Microsoft. Thesycon also seems to be the preferred driver vendor of XMOS and I would guess most of the testing occurred on XMOS based solutions.
If you roll your own, you'll find that almost every single existing USB Audio Class implementation available in example firmware is 1.0 and thus doesn't support above 24/96.
I've never used the OMAP-L137, but if I were to try to do this from scratch I'd probably use STM32H7 or instantiate a Nios II or Microblaze CPU inside an FPGA. The OMAP will have better DSP performance than the Cortex M7 I think but, if you aren't doing any DSP then I think you'll find the STM32 has good community support and libraries that get regular updates, both their own HAL and ARM CMSIS.
I can’t even find a way to program a new firmware, there is no DFU driver for Windows, requires the xmos Thesycon drivers (which in turn somehow overrides UAC2, and its trial only, time bombing after one hour), even if win 10 supports UAC2. I guess I’m not used with low level monolithic software written from ground up, without any layered structure, no OS services (at least a standard RTOS, not necessary Linux) no memory management services, in general no service that I have ever used exist, not a chance to reuse any code backward and forward. Try to find a well documented way to put the DFU bootloader on the chip. Writing Linux drivers for a piece of custom hardware is a piece of cake compared to this monstrosity, if nothing else, at least I have printk() to write log files.
Try to change the VID and PID and the UAC2 driver bombs, and this is expected behavior, nonetheless, the xmos thesycon driver works fine within the trial limitation. Read the description of a nightmare straight from an xmos engineer (mon2) USB Audio 2.0 Stereo Driver for Windows 10 Update - XCore Exchange
I wonder what are these xmos software guys writing in their resumes. Other than C language and knowledge of the USB and audio transport specs, it doesn’t seem they have much of transferable skills after spending some years at xmos. Even embedded programming is today much more flexible than this thing, and has a clear programming model.
Enough ranting for today, back to ruffling some high end audiophile feathers, it’s much more fun
.I have zero experience with the STM32, I’ll take a look. What I find exciting about the OMAP is that any eventually needed DSP functionality (filtering, FFT, etc) can be conveniently moved in, leaving the whole PC, Windows, UAC2, USB endpoints, etc... nightmares in the dust. Not sure if a rp4 has enough horsepower to do all the analyzer stuff that a PC can, but an OMAP certainly can, and in an elegant way.
Last edited:
Finally, after a week of reading the UAC2 specification and the XMOS code, some progress...
The XMOS mulitichannel board worked fine, out of the box with both the Windows 10, Ubuntu Linux, OS X, either with the native UAC2 drivers or with the Windows Thesycon evaluation drivers (with anything t Windows, the DFU works ok as well). However, as soon as the firmware was recompiled and loaded, UAC2 driver on windows will no longer play with the board. It worked fine, after recompiling, with the Thesycon evaluation driver, though.
It turned out that a compilation flag (or a #define) needs to be added in order to make the firmware compatible with the Window native UAC2. Works fine after, I'm in the process of testing the analog part. Next step will be to test with external ADC/DAC (easy to do, but the integration results are gating), then add SPI to I2S conversion in a tile (library is available), integrate with a SAR ADC, followed by fine tuning and finally testing. Nothing that can be done quickly, indeed an XMOS solution is 95% software.
Not sure if it's true that the Windows 10 UAC2 driver is actually Thesycon, but if true, they did a good job in protecting their core business (licensing the Thesycon driver, against obscene amounts of money). That compiler flag required for Windows 10 makes the firmware less than optimal for Apple devices with their default UAC2 support. Don't have a performance metric yet, but apparently some modes are not working properly.
Until I'm proven wrong, this once again proves the XMOS solution as anything but "open hardware". It's a disguised multichannel commercial solution, hopes are that the stereo only version (Thesycon drivers are still free, but require registration, fine print, NDA), needed for instrumentation, is good enough. I'll update here from time to time.
No, and I have to focus on what I have for now. Not a matter of money, but a matter of time. Can't afford more distractions, already other analog audio projects are on the backburner following this XMOS adventure.
I'll do some reading about when I have a chance.
Not surprised there are tradeoffs to push you in the direction of the commercial driver.
The note about Thesycon is at the bottom of this page:
USB Audio 2.0 Drivers - Windows drivers | Microsoft Docs
"This USB Audio 2.0 class driver was developed by Thesycon and is supported by Microsoft."
I do like AES67 / Dante, hopefully it catches on more in the consumer market.
I am not really in love with USB as an audio interface. The drivers and performance are still iffy overall. Even though the xHCI controller is supposed to do all the work for the CPU and enable DMA, it's yet another layer to go through in kernel space. I am not sure who is to blame - the peripheral driver writers or the host controller driver. When I monitor the DPC latency of my system when I have most USB Audio Class devices attached it is noticeably higher than when not. I have not seen the kind of performance I got out of the old EMU 1820m (native PCI) on any USB interface I have tried. I have a recent Intel USB 3.0 (XHCI) controller in this system, which is arguably the best hardware implementation and certainly the most common and well-supported USB host controller in existence. Is this a problem? Well, for most uses it probably isn't, but I don't like it. I also have had major problems with Focusrite's XMOS drivers which I think are written by a vendor other than Thesycon. They cause random BSOD on one of my Windows 10 PCs which is 100% stable otherwise.
RME seems to get better results out of USB, probably because they implemented their interface from scratch in an FPGA and wrote their own drivers for it.
WRT Dante, it has been widely adopted in live sound especially large concert
productions but it doesn't do 384k AFAIK. I think there is some limited adoption in home theatre.
TCD
Why to use a garbage? XMOS is only CPU and not only cheesiness use it.
Reference design source code is open.
The problem is only UAC2 driver, if you want ASIO and DFU, otherwise Win10 now consist of the Thesycon's driver (with some features limited).
Ohh, maybe I missed something! Will check.
Did not tried F7, but in F4 - I2S and SAI work fine at 384 (and with some limitation - at 768kHz). Hope F7 also should be.
A hell to program, almost everything has to be done from scratch. There are no open source libraries that would natively support the XMOS tiled architecture.
Maybe I’m not used yet with this this strange CPU, but anything that’s beyond small changes to the reference design code (like, for example, a SPI to I2S conversion) appears as very difficult to implement efficiently.
people have done some impressive stuff with the XMOS. Many of the Alexa and Google speaker use the XMOS platform for the microphone processing. Its virtue and downfall is the parallel processing, something that makes it really difficult to program. One company used it for a 3D spatial surround processing for a headphone. Unfortunately it was expensive and they crashed before it made it to market.
Its NOT a mobile friendly platform, that may be its doom. However it does enable MQA if everything else is in line. . . ESS has a new USB interface that does the same but only works with ESS stuff.
Its NOT a mobile friendly platform, that may be its doom. However it does enable MQA if everything else is in line. . . ESS has a new USB interface that does the same but only works with ESS stuff.
Somehow, I don’t think Google or Amazon would have any problem in finding programmers to fight the XMOS thing. Or to license the Thesycon drivers. Or to to implement whatever solution/product they please, using a chip of their choice.
My problem is with a product (XMOS) advertised as “open source hardware” which in fact is so only until you scratch the surface. There is practically no community and open source software available for this product, like for example for raspberry pi.
My problem is with a product (XMOS) advertised as “open source hardware” which in fact is so only until you scratch the surface. There is practically no community and open source software available for this product, like for example for raspberry pi.
Only USB stack is proprietary, but with open and well described API.
All othes source is open.
Reference Design - is only example for the Quick Start.
It even not use all their libraries! For example - I2S/TDM library not used, and it have much more features, that can be implemented in the Reference Design.
Why, oh why, is there no community to speak off around this “open source” product? XCore Exchange - Index page is pretty much a dead place. Can I make a wild guess
?Hi ... I am not a programmer so I may not entirely discern whether or not this may be of interest in this thread context. But are you aware of this interface:
MCHStreamer - USB Audio Swiss-Army knife - Multichannel PCM/DSD/PDM/ADAT/TDM/SPDIF interface
It does 8 channels of 24 bits/384 kHz in/out so if e.g. an FPGA/CPLD can (in a simple way, maybe?) be set up to handle the conversion of the LTC23** data output format to an I2S format - and maybe "multi-channel" data inputs can be separated inside the computer - then it should be capable of two channels of 1.536 MHz.
Cheers,
Jesper
MCHStreamer - USB Audio Swiss-Army knife - Multichannel PCM/DSD/PDM/ADAT/TDM/SPDIF interface
It does 8 channels of 24 bits/384 kHz in/out so if e.g. an FPGA/CPLD can (in a simple way, maybe?) be set up to handle the conversion of the LTC23** data output format to an I2S format - and maybe "multi-channel" data inputs can be separated inside the computer - then it should be capable of two channels of 1.536 MHz.
Cheers,
Jesper
I doubt the first party stuff uses XMOS, could be wrong though? I thought Amazon actually designed their own ASIC for this. There are dev kits now for several platforms.
Development Kits for Alexa Voice Service
Aside from being a bit different, I'm not sure what the chip really brings that you can't do on a more conventional MCU/DSP that is likely cheaper and easier to use.
I completely understand why it's popular in audio - because it has working UAC2 reference firmware. I'm just skeptical of their ability to compete with the TI, ST Micro, NXP, Cirruses of the world.
I was always hoping TI would do a UAC2 asynchronous chip. That's all most people really want, give us a chip that is compatible with UAC2, has I2S I/O up to 768 kHz, and lets you set your own USB PID/VID.
Why, oh why, is there no community to speak off around this “open source” product? XCore Exchange - Index page is pretty much a dead place. Can I make a wild guess
It could be worse, there is at least a forum with posts from this year on it
. I worked for a brief time on a product that used an Ingenic MIPS SoC. It was cheaper than the TI OMAP Cortex A8, and Broadcom would not sell us the RPi SoC no matter what volume we could promise, so our customer chose it. In the end everyone wanted to kill themselves. The English documentation was horrific. We had a developer that is a native Mandarin speaker but he said the Chinese documentation made no sense at all either. It was dependent on some hacked up version of U-boot and a bunch of blobs that were emailed to us directly from some guys in China.Continuous software support is always the very key to success of any SoC. That is why almost none of the many dirt-cheap RPi alternatives have gained wider use - outdated linux android kernel with half-working drivers make the attractive HW price irrelevant.
RPi has its load of bugs but they are being constantly fixed in new firmware versions, issued on a regular basis. IMO that is behind 95% of the RPi success.
RPi has its load of bugs but they are being constantly fixed in new firmware versions, issued on a regular basis. IMO that is behind 95% of the RPi success.
Completely agree. That's why we tried to buy the Broadcom SoC, because we knew the drivers were in decent shape.
The Ingenic SoC used the same USB controller (DWC2 or 3, I forget), but we ran into a lot of issues. The stock driver basically didn't work. Even HID devices could cause kernel panics. We noticed it worked fine on the RPi - mostly because the guys from the RPi Foundation seemed to refactor that driver significantly - but it could not be directly re-used because the updated driver was dependent on ARM FIQ feature (fast interrupt). We were able to get it somewhat stable by keeping the higher level parts of the refactored driver and changing the ARM FIQ dependent portions. Performance and stability were still not what they should have been.
I did read the errata PDF for that Synopsys USB controller and it was pretty bad! No wonder it was tough making the driver work. I know even the Intel USB controllers have a lot of quirks, but this seemed special in a bad way
.The unfortunate thing about the Raspberry Pi is that it ends up with great Linux support, but Broadcom is really not interested in the ARM SoC market. So all that development work ends up only usable for the Raspberry Pi or RPi Compute Module and not for any broader set of hardware.
Last edited: