XMOS has released a new ver. Build 3.01 of the code to the XMOS USB Audio 2.0 Reference Design
The new adds are:
Added support to allow easy addition of custom audio requests
Optional "Host Active" function calls
Since I haven't found so much written info around that yet, I start this post so we can discuss our findings - of how we can use it in different ways.
XMOS USB Audio 2.0 Reference Design Build 3.xx
-
- XCore Expert
- Posts: 956
- Joined: Fri Dec 11, 2009 3:53 am
- Location: Sweden, Eskilstuna
XMOS USB Audio 2.0 Reference Design Build 3.xx
Probably not the most confused programmer anymore on the XCORE forum.
-
- Member++
- Posts: 21
- Joined: Thu Jun 03, 2010 9:39 am
They add a lot of software function, especially in L2 reference board.
Since I have spent q lot of time of L1/L2 reference code. I think I can quickly sort out the key difference and improvement.
Cheers,
:D
Since I have spent q lot of time of L1/L2 reference code. I think I can quickly sort out the key difference and improvement.
Cheers,
:D
-
- XCore Expert
- Posts: 956
- Joined: Fri Dec 11, 2009 3:53 am
- Location: Sweden, Eskilstuna
Has something happened on the PC-side?
Or have theSycon dll always supported the transfer, it was just not documented?
The answer many people want to know is:
Can you send non-Audio GP data to the host-driver/or other OS-driver from your application, and get it out in a endpoint on the XMOS side, without doing adhoc things as using the MIDI-driver for GP data transfer and reroute the MIDI-data on the XMOS side to SPI or I2C -> Giving more value to us developers compared to a standard ASIC Audio-USB solution.
As I sum it up from different users: The main criticism for the Build 2.X is - Where is the extra feature to build new products that isn't a ASIC copy of what's out there from a consumer perspective !!??
USB2.0 Audio HW-solution is not unique any-more.
Could we hope for a fast XTAG2 data transfer soon as well ?
Hmm, the XTAG2 has the dual L-Link, and that handles above 30 MB/s or something. We are just waiting for the host driver, and updated XDE.XTAG2 firmware.
Or have theSycon dll always supported the transfer, it was just not documented?
The answer many people want to know is:
Can you send non-Audio GP data to the host-driver/or other OS-driver from your application, and get it out in a endpoint on the XMOS side, without doing adhoc things as using the MIDI-driver for GP data transfer and reroute the MIDI-data on the XMOS side to SPI or I2C -> Giving more value to us developers compared to a standard ASIC Audio-USB solution.
As I sum it up from different users: The main criticism for the Build 2.X is - Where is the extra feature to build new products that isn't a ASIC copy of what's out there from a consumer perspective !!??
USB2.0 Audio HW-solution is not unique any-more.
Could we hope for a fast XTAG2 data transfer soon as well ?
Hmm, the XTAG2 has the dual L-Link, and that handles above 30 MB/s or something. We are just waiting for the host driver, and updated XDE.XTAG2 firmware.
Probably not the most confused programmer anymore on the XCORE forum.
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
Some help from XMOS on this would be great. Ross?
From what I see there is little additonal in the firmware, except a call to handle unhandled USB functions. I haven't had time to fully review the new code yet so I may well have missed the point. The real work would be in the drivers on the computer side to allow something else to be sent.
Is there changes coming to the drivers? Or are the functions to be left for custom driver development.
From what I see there is little additonal in the firmware, except a call to handle unhandled USB functions. I haven't had time to fully review the new code yet so I may well have missed the point. The real work would be in the drivers on the computer side to allow something else to be sent.
Is there changes coming to the drivers? Or are the functions to be left for custom driver development.
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
Downloaded version 3.02. Also saw there is a new version of the driver after all v1.19.
Have to wait to install to see any change log on the driver, I guess.
There are listed some USB improvements. I suspect these are in the XUD library update. I guess I will have to review the endpoint code also for changes.
I am a little perturbed XMOS changed the XUD library calls a little while ago from passing a channel argument, to now passing an integer of the channel resource. I will now have to recode (and figure out how to) my application for this change if I am to use the latest XUD library.
Have to wait to install to see any change log on the driver, I guess.
There are listed some USB improvements. I suspect these are in the XUD library update. I guess I will have to review the endpoint code also for changes.
I am a little perturbed XMOS changed the XUD library calls a little while ago from passing a channel argument, to now passing an integer of the channel resource. I will now have to recode (and figure out how to) my application for this change if I am to use the latest XUD library.
-
- XCore Expert
- Posts: 956
- Joined: Fri Dec 11, 2009 3:53 am
- Location: Sweden, Eskilstuna
I will try and download the 3.02 and the 1.19!
This is interesting, but I cannot read it:
Thesycon USB Audio 2.0 Driver for Windows User Manual ver 1.21d 22-12-2010
User guide for L1 and L2 Production Driver Parts.
Requires access to Thesycon USB Audio Class 2.0 Production Driver (L1 or L2)
Code: Select all
XMOS USB Audio 2.0 Reference Design (XS1-L1) Changelog
=====================================================
Firmware release version: 3v02 (build 0bf6d7c24097c5be2a534e3f0d3e78341aa96043)
Firmware
========
3v02:
- RESOLVED: Unable to build on windows platforms (#9681)
3v01:
- RESOLVED: Version number reported as 0x0200, not 0x0300 (#9676)
3v00:
- ADDED: Added support to allow easy addition of custom audio requests
- ADDED: Optional "Host Active" function calls
- RESOLVED: Single sample delay between ADC L/R channels resolved (#8783)
- RESOLVED: Use of MIDI cable numbers now compliant to specification (#8892)
- RESOLVED: Improved USB interoperabilty and device performance when connected through chained hubs
- RESOLVED: S/PDIF Tx channel status bits (32-41) added for improved compliance
- RESOLVED: Increased robustness of high-speed reset recovery
Code: Select all
-----------------------------------------------------
V1.19.0 (October 20, 2010)
----------------------------------------------------
* Fix: Driver crashes if device does not report a valid
sample rate, or initial set sample rate request fails
* Fix: Invalid return value (e.g. zero) from
GET CLOCK_SELECTOR_CONTROL caused control panel to crash.
* Fix: BSOD if ASIO host is closed after device was unplugged.
* Chg: API changed: currentIndex parameter removed from:
TUSBAUDIO_GetSupportedSampleRates
TUSBAUDIO_GetSupportedClockSources
TUSBAUDIO_GetSupportedStreamFormats
* Chg: API changed: TUsbAudioClockSource revised
* New: ASIO multi-client support can be disabled
via registry
* Fix: AsioReset not delivered to second ASIO client
on sample rate change
Thesycon USB Audio 2.0 Driver for Windows User Manual ver 1.21d 22-12-2010
User guide for L1 and L2 Production Driver Parts.
Requires access to Thesycon USB Audio Class 2.0 Production Driver (L1 or L2)
Probably not the most confused programmer anymore on the XCORE forum.
-
- Respected Member
- Posts: 283
- Joined: Fri Mar 19, 2010 4:49 am
I might offer a suggestion that keeping the developers up to date with the latest driver and features would be best, in general. Offering prior versions as the developer edition, seems counter productive. Sometimes waiting for an update either to the firmware or driver to be released may be needed as one may not work without the other.
One concern I have always had is the developers are out of the loop on enhancements and problems. I might suggest some means to discuss and learn about beta features, bugs, and future enhancements so we could plan accordingly, offer feedback, and not waste time debugging the same bug as already reported.
One concern I have always had is the developers are out of the loop on enhancements and problems. I might suggest some means to discuss and learn about beta features, bugs, and future enhancements so we could plan accordingly, offer feedback, and not waste time debugging the same bug as already reported.
-
- Member++
- Posts: 21
- Joined: Thu Jun 03, 2010 9:39 am
Well... just got sometime to review the V3.02 code... Several new things there (most of them are not new function)
1. Now they unify the L1 & L2 firmware code quite a lot... (but it generate a lot of useless code for L1 reference design like MIXER, PLL, 18 channel Inputs, Clock generation from SPDIF RX... etc)
2. Several bugs removed. (buffer mechanism changed slightly, USB description changed in one place)
3. Add a lot places for 3rd party (vendor) customize their own code.. (for CODEC, CLOCK... etc)
4. while in DFU mode, add a dummy deliver function in audio thread.
in summary, this is more like structural change. not functional.
But still, hope XMOS could provide the "HOST Active function" related explanation... (I still don't get it what is that)
Thanks,
1. Now they unify the L1 & L2 firmware code quite a lot... (but it generate a lot of useless code for L1 reference design like MIXER, PLL, 18 channel Inputs, Clock generation from SPDIF RX... etc)
2. Several bugs removed. (buffer mechanism changed slightly, USB description changed in one place)
3. Add a lot places for 3rd party (vendor) customize their own code.. (for CODEC, CLOCK... etc)
4. while in DFU mode, add a dummy deliver function in audio thread.
in summary, this is more like structural change. not functional.
But still, hope XMOS could provide the "HOST Active function" related explanation... (I still don't get it what is that)
Thanks,
-
- Experienced Member
- Posts: 82
- Joined: Fri Nov 05, 2010 2:59 pm
It appears that Ross(?) has indeed made the usb library generic; there's nothing inherently audio-centric about it.lilltroll wrote: The answer many people want to know is:
Can you send non-Audio GP data to the host-driver/or other OS-driver from your application, and get it out in a endpoint on the XMOS side, without doing adhoc things as using the MIDI-driver for GP data transfer and reroute the MIDI-data on the XMOS side to SPI or I2C -> Giving more value to us developers compared to a standard ASIC Audio-USB solution.
As I sum it up from different users: The main criticism for the Build 2.X is - Where is the extra feature to build new products that isn't a ASIC copy of what's out there from a consumer perspective !!??
USB2.0 Audio HW-solution is not unique any-more.
Could we hope for a fast XTAG2 data transfer soon as well ?
Hmm, the XTAG2 has the dual L-Link, and that handles above 30 MB/s or something. We are just waiting for the host driver, and updated XDE.XTAG2 firmware.
I suggest you read this:
http://www.xmos.com/published/xuddg
There's a HID example included.
Ross, is there a way to stall control IN endpoint 0 via the XUD library, as is required to indicate non-supported class requests?
What you need to do is provide an appropriate configuration and device USB descriptor for your device. This might say that it supports a USB bulk IN/OUT endpoint or perhaps an interrupt IN/OUT endpoint with a HID(descriptor). If one uses a descriptor for a commonly supported device class eg. CDC, MSC, HID then your Mac/PC will be able to talk to your device without any special client side drivers. You then need to provide XS1 code to handle requests for these classes you describe, in much the same way as the XMOS code handles audio class requests.
See documents on http://www.usb.org.
USB is a complicated business: it's difficult to get the complete picture without putting in a lot of work.
XMOS provides the XUD with their audio dev kits. I'm not sure about their position providing it for generic other usage. You could always ask!
Max
-
- XCore Expert
- Posts: 956
- Joined: Fri Dec 11, 2009 3:53 am
- Location: Sweden, Eskilstuna
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.
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.
Probably not the most confused programmer anymore on the XCORE forum.