lilltroll wrote:What is the latest status on whis ?
It has been rather quiet about this, is there an open sorce or freeware solution that people uses to send non audio data to the card now from Windows. (Running it as a USB2.0 soundcard as well)
If so, I have missed it.
So is it that you want a communications channel which is completely divorced from audio operation? What would this be for? What sort of comms interface are you thinking of and what might it control on the card unrelated to audio function. Or is the audio thing a distraction and you're really just interested in running general custom control I/O over USB without an audio interface? Are you thinking of a virtual COM port perhaps? Usually if you have a physical control on a device that's related to audio function then this control modifies state in the virtual USB model and a notification is sent to the PC host via an audio interrupt endpoint to notify the host of the state change. In this way, one could have say a physical volume control knob that moves sliders in the PC UI when it is turned. One could change the audio input source automatically if a lead is plugged into your external hardware and the PC would be notified. This is how the audio2 functions is designed to work, rather than having an associated HID interface.
The dilemma is not on the XMOS side, it is on the Windows API side.
A big reason to use XMOS for a new USB Audio 2.0 product is to add something extra compared to be just a soundcard.
For an example you could be interested in sending filtercoefs to the XMOS chip or to communicate with the registers in a more Advanced CODEC. To do so you need some sort of API in windows. A workaround have been to send non-Audio data as a MIDI transmission and decode it on the XMOS side as something else.
As long as your toolchain/IDE on the Windows side has MIDI support, and you do not use MIDI for real, this is a little bit ugly but possible solution.
But, the XMOS code is since ver 3.0 implemented to receive non-Audio data to EP0, and theSycon driver has some pseudo support for that, meaning that the function is partly documented for the tusbaudioapi.dll but the parts needed for sending GP data with the definitions
in the DDL is undocumented.
The fee to get access to that was not “low priced”, and it (at least was not earlier) not included in the XMOS THX chip license.
For the extra fee of THX chips you got a driver that didn't beep every now and then, and you could place your own logotype in the installation etc.
Since I guess all modern Windows languages supports DLLs, it is a technical good solution, and as well it is nice to just have one driver. The use of VCOM can solve it, but that would be suboptimal for the enduser I guess, enumerating virtual COM ports that shouldn't interfere with virtual COM ports from Bluetooth etc. A smartphone may enumerate a lot of things connecting to windows.
So, the solution is already implemented, and it is even possible to extract a h-file needed to the ddl from the package, and the DLL will actual respond, but it will not enumerate the things needed for ..Set and ...Get with the standard license code.
Somehow it became a deadlock, since I didn't hear from anyone in the The USB Audio 2.0 Group that spent the money to get the license for the acess, or if they did, it was probably under NDA and they couldn't talk about it afterwards.
And suddenly everything vent quiet, and I do not know why.
1) People just gave up and skipped the plans.
2) People paid the fee but under a very strict NDA
3) An competitive driver manufacture came with a more attractive solution.
4) XMOS code-support for USB made it possible to access some type of abstraction in Windows and it is now possible to send non Audio data for free both ways in parallel with the Audio without glitches.
Myself I built a "modem" to be able to send digital data via an "acoustic channel", that Windows may be running both volume control and ugly interpolation on, but with ASIO you can skip several of Windows forced control stuff.
But I cannot send data and audio the same time of course.
So in the end I skipped USB and started to use Ethernet instead.