Standard XMOS source code can be downloaded via their compiler program suite (xTIME Composer Studio). A simple to obtain NDA agreement is required for that.
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.
XMOS doesn't ask for NDA at all. Any code examples I downloaded from XMOS engineering forum i.e. 1min registration is required.
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
XMOS doesn't ask for NDA at all. Any code examples I downloaded from XMOS engineering forum i.e. 1min registration is required.
Do you have the source code for the USB driver, the XMOS side? The downloadable code has only the object code to be linked.
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.
Do you have the source code for the USB driver, the XMOS side? The downloadable code has only the object code to be linked.
Do you refer to the is driver for UAC2?
Tfive, probably he talking about the part of the code which handles USB physical interface, and probably yes it is added to the timecomposer project as a precompiled lib.
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
This USB Audio 2.0 class driver was developed by Thesycon and is supported by Microsoft.
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.
Regarding the "super regulator" I used recommended by ESS way, please take a look ESS 9038Q2M demoboard.pdf
Asking an unprotected opamp output to supply something unknown that has unknown lots of unknown local capacitance is a very bad idea.
ESS should stick to DACs/ADCs ;-)
Jan
One of the benefits of using STM32 MCUs is that no third-party driver is needed for UAC2 even in Windows.
One of the benefits of using STM32 MCUs is that no third-party driver is needed for UAC2 even in Windows.
Looking forward for nice xxxkHz to xMHz SR I/O device ... best, if isolated from the USB EMI/RF part 😀
Looking forward for nice xxxkHz to xMHz SR I/O device ... best, if isolated from the USB EMI/RF part 😀
I'll leave the xMHz stuff to you big boys. My needs do not go above 768kHz (or even 384kHz).
One of the benefits of using STM32 MCUs is that no third-party driver is needed for UAC2 even in Windows.
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.).
What is advantage of ASIO compared to exclusive wasapi, apart of apps support for historical reasons?
WASAPI Exclusive Mode is Microsoft's answer to ASIO (which was developed by Steinberg, the makers of Cubase, for DAW use). ASIO came first, so support for it is more widespread.
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?
How will REW talk to Ivan's separate DAC and ADC devices via ASIO, apart of using some ASIO-WASAPI bridges?
- Home
- Design & Build
- Equipment & Tools
- ADCs and DACs for audio instrumentation applications