I don't think I had to sign a NDA to download the xTimeComposer, but I don't remember 100%. In any case, if there was an NDA it was as simple as marking a checkbox, no written communication required at all.
Included with the xTimeComposer there's a 8 channel demo software which compiles and runs on the DIYINHK boards. I modified it to have 12 channels available instead of 8, no problem.
That's how I remember it as well. Thanks for confirming IVX.
Sadly my code cannot be distributed because of silly XMOS licence constraints. I wonder how they think that's beneficial for them. If I owned that company I would make API and example code freely available to further usage of my platform. Just my 2ct
Sadly my code cannot be distributed because of silly XMOS licence constraints. I wonder how they think that's beneficial for them. If I owned that company I would make API and example code freely available to further usage of my platform. Just my 2ct
To be honest I don't remember that precisely, I did play with that MCU 3 years ago and remember all things were easy because not bad documented. A couple of days and what I planned to implement were done. As I remember, XMOS referred to the third party company regarding the Windows driver.
The third party company is most likely Thesycon, even MS licensed their driver.
USB Audio 2.0 Drivers - Windows drivers | Microsoft Docs
USB Audio 2.0 Drivers - Windows drivers | Microsoft Docs
Each custom driver have to be validated by MS corporation. So you have to be a company for that matter/pain. Keep in mind if MS changed from 2004 or 20H1 some changes was required within the driver. Also Thesycon supports ASIO too!
The other option is the the MCHStreamer - USB Audio Swiss-Army knife - Multichannel PCM/DSD/PDM/ADAT/TDM/SPDIF interface
Some SW supports 2x..8x channel bundling to have 2x..8x of the base SR
. Did digital I/O test this with the former USBStreamer.
In the old days Jens started with an isolation module using this USBStreamer before he did his own XMOS implementation for the RTX.
ASIO has some better options with multi client host and channel selection or combine as RME ADI-2 pro as using 3 gear's to one ASIO device.
IMHO it is better to leave the MS driver stuff to someone how does it as business and pay a little money/license the Thesycon driver.
The other option is the the MCHStreamer - USB Audio Swiss-Army knife - Multichannel PCM/DSD/PDM/ADAT/TDM/SPDIF interface
Some SW supports 2x..8x channel bundling to have 2x..8x of the base SR
. Did digital I/O test this with the former USBStreamer. In the old days Jens started with an isolation module using this USBStreamer before he did his own XMOS implementation for the RTX.
ASIO has some better options with multi client host and channel selection or combine as RME ADI-2 pro as using 3 gear's to one ASIO device.
IMHO it is better to leave the MS driver stuff to someone how does it as business and pay a little money/license the Thesycon driver.
Looking forward for nice xxxkHz to xMHz SR I/O device ... best, if isolated from the USB EMI/RF part
But the same is about any other UAC2 devices - modern Win10 has internal UAC2 driver (which is the "light version" of the TheSycon driver).
3rd party driver will give just the additional features (like ASIO, etc.).
The historical development is known, but any advantage from the technical POW? IMO it's time to gently ask audio and measurement software vendors about support for WASAPI exclusive, to gradually phase out the historical ASIO. My project needs REW, so (with invaluable help from Henrik, the author of camilladsp with low-level wasapi support) I am preparing a simple wasapi-exclusive connector for java.
WASAPI Exclusive may be superior to ASIO. Sometimes Windows will arbitrarily assign a device with an ASIO driver as Default Sound Device and or as Default Communications Device. When that happens Windows may run PCM for the ASIO audio device through Windows Sound Engine, thus subjecting it resampling and or passing through a mixer/volume control. Not clear how that works, at least it isn't clear to me. Perhaps the PCM output of an application using the ASIO driver interface remains bit-perfect in that case. OTOH, there should not be any uncertainty if WASAPI Exclusive Mode is requested and granted.
Last edited:
I am talking about wasapi exclusive exclusively . What WASAPI exclusive allows is capturing from one device while playing to another device. I am not sure ASIO offers such basic feature, because it allows only one loaded driver at a time (a single COM object at a fixed address) and the API transports playback and capture samples in the same buffer_switch callback (i.e. preventing reliable communication from two independently-clocked devices).
How will REW talk to Ivan's separate DAC and ADC devices via ASIO, apart of using some ASIO-WASAPI bridges?
. What WASAPI exclusive allows is capturing from one device while playing to another device. I am not sure ASIO offers such basic feature, because it allows only one loaded driver at a time (a single COM object at a fixed address) and the API transports playback and capture samples in the same buffer_switch callback (i.e. preventing reliable communication from two independently-clocked devices).How will REW talk to Ivan's separate DAC and ADC devices via ASIO, apart of using some ASIO-WASAPI bridges?