XMOS USB Audio 2.0 Reference Design Build 3.xx

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
lilltroll
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

Post by lilltroll »

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.


Probably not the most confused programmer anymore on the XCORE forum.
Light
Member++
Posts: 21
Joined: Thu Jun 03, 2010 9:39 am

Post by Light »

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
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

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.
Probably not the most confused programmer anymore on the XCORE forum.
bearcat
Respected Member
Posts: 283
Joined: Fri Mar 19, 2010 4:49 am

Post by bearcat »

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.
bearcat
Respected Member
Posts: 283
Joined: Fri Mar 19, 2010 4:49 am

Post by bearcat »

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.
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

I will try and download the 3.02 and the 1.19!

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
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)
Probably not the most confused programmer anymore on the XCORE forum.
bearcat
Respected Member
Posts: 283
Joined: Fri Mar 19, 2010 4:49 am

Post by bearcat »

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.
Light
Member++
Posts: 21
Joined: Thu Jun 03, 2010 9:39 am

Post by Light »

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,
MaxFlashrom
Experienced Member
Posts: 82
Joined: Fri Nov 05, 2010 2:59 pm

Post by MaxFlashrom »

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.
It appears that Ross(?) has indeed made the usb library generic; there's nothing inherently audio-centric about it.
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
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

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.
Probably not the most confused programmer anymore on the XCORE forum.
Post Reply