XMOS-based Asynchronous USB to I2S interface

Attachments

  • DSC_07410001.JPG
    DSC_07410001.JPG
    312.7 KB · Views: 592
New Microsoft USB Audio Class 2 Drivers

With the Windows 10 Creators Update, Microsoft also released its new USB Audio Class 2 drivers. Finally!

I tested them with my WaveIO. The installation is automatic and the device manager shows the following drivers in the c:\windows\system32\drivers directory:

- dmk.sys
- kstunk.sys
- portcls.sys
- usbaudio2.sys

Via JRiver Media Center, I played FLAC-Files with 44.1/16, 48/24, 88.2/24, 96/24, 176.4/24 and 192/24. They all played fine without problems. Does it sound different than with the WaveIO driver? No idea, since I didnt make a direct comparison. Differerences, if any, would probably be minor. For some measurement comparisons, see

Archimago's Musings: MEASUREMENTS: Windows 10 Creators Update USB Audio Class 2 Driver. (And a request of Neil Young / XStream.)

Hopefully, the availability of these drivers will reduce the problem of illegal copying of Lucien's WaveIO drivers. It would be interesting if some other WaveIO users could test these new drivers and report about their experience.
 
... and I just wanted to let all of you know that I have latest Thesycon drivers v4.11 :p Tested today and fully working.
I'm glad MS decided to build up their own driver still I have a couple of reasons to stick with Thesycon for now. The most important one that Thesycon is responsive and they does help me in a reasonable time frame (I really doubt MS is doing likewise - I had my own poor experiences with them). Not to mention that Thesycon drivers does offer some settings that are now(?) unavailable on MS drivers.
Not to mention about DFU. I cannot rely on MS because there's not such thing implemented (that I'm aware off). Should I continue with max sample rates? I'm going to test MS driver as well but so far their latest major W10 update leaved a bad taste on my mouth because I have some problems with video drivers (?): after closing my laptop's lid and open it again there's no image rather than the mouse cursor. Never experienced such "pleasure" before. I had to reinstall the whole system just to be able to use my laptop!!!

Anyway, since the first impression counts on my side I'll have to pass their updates for now to allow their bugs number to shrink a bit. :rolleyes:

Thank you for reporting and feedbacks!

Kind regards,
L
 
Hopefully, the availability of these drivers will reduce the problem of illegal copying of Lucien's WaveIO drivers.
Oh, I forgot about that! It seems that starting with 4.xx version, this problem have a solution! I'll not get into boring details... to avoid giving free clues... I'm just glad that I finally found a way to solve my old driver issues yet to offer all of you who have a WaveIO free access to future drivers from Thesycon. It's all that matter to me right now.
 
I just sent a couple of PMs with the latest driver for WaveIO and BluWave v4.11.0.
Please use the contact form for nay other requests!
Thank you,
L

Hi Lorien,

I've been playing with WaveI/O power supplies' decoupling for a while. I'd like to point out to other DIY-ers, that supply to the I2S isolator chip is as crucial as the main +5V DC supply that powers most of the WaveI/O.

What I also noticed is a marked improvement in detail retrieval once I disconnected the LED's ribbon cable from the WaveI/O; I was expecting an improvement, but in reality, it was just beyond what I expected, really.

Nick
 
Thank you both for feedback!
What I also noticed is a marked improvement in detail retrieval once I disconnected the LED's ribbon cable from the WaveI/O; I was expecting an improvement, but in reality, it was just beyond what I expected, really.
:confused: I simply have no explanations... :cool:

Edit: there are many guys pressing me to go with the multichannel variant of WaveIO and now since my other small board is almost finished I just wanted to peek uncharted waters just to know if there's any interest for such a board? Obviously, I already have the driver support - which I must say I'm kinda proud off - so any of the new boards will benefit of the same stable Win driver.

Have fun,
L
 
Last edited:
Hi Lorien,

I've been playing with WaveI/O power supplies' decoupling for a while. I'd like to point out to other DIY-ers, that supply to the I2S isolator chip is as crucial as the main +5V DC supply that powers most of the WaveI/O.

What I also noticed is a marked improvement in detail retrieval once I disconnected the LED's ribbon cable from the WaveI/O; I was expecting an improvement, but in reality, it was just beyond what I expected, really.

Nick

The one thing I can think of is that the ribbon acts as an antenna. :eek:
 
.... increase a ground loop ?

I am going to refrain from comments here... but, I measured a current draw increase of 30mA with 3 green LED's being ON. That current needs to get back to a negative of a power supply connector... somehow...

I decided not to use the LED's anymore because the difference is quite obvious to everyone who I demoed it to.

Nick
 
@ kinku: You have PM with link to that driver pack.
@ Extreme_Boky: I can't remember well but at some point back, I read through XMOS messy datasheets that one particular XMOS GPIO pin ca source up to 8 mA of current (?). I know this value is not fixed since I ran a couple of tests on my own and in short circuit, one pin can go up to 24 mA for a short period of time (I didn't leave the XMOS IC in that state for a long period of time since I didn't want to damage it). Anyway, I guess that in certain cases, those mAmps will add to the overall power consumption of your WaveIO and can make a difference. For example, in case of shunt PSUs, where you have to be sure how much current your WaveIO needs. Same is applied to USB powered WaveIO boards (which I guess is not the case here):
it's stated that USB ports should source 0.5A but I have plenty examples where the current was less than expected because those PCs were poorly made.
My advice: please try to find LEDs with less current needed to lit accordingly. Or, you can add a simple CMOS buffer and put any type of low power LEDs you want there! :)
 
Last edited:
@ kinku: You have PM with link to that driver pack.
@ Extreme_Boky: I can't remember well but at some point back, I read through XMOS messy datasheets that one particular XMOS GPIO pin ca source up to 8 mA of current (?). I know this value is not fixed since I ran a couple of tests on my own and in short circuit, one pin can go up to 24 mA for a short period of time (I didn't leave the XMOS IC in that state for a long period of time since I didn't want to damage it). Anyway, I guess that in certain cases, those mAmps will add to the overall power consumption of your WaveIO and can make a difference. For example, in case of shunt PSUs, where you have to be sure how much current your WaveIO needs. Same is applied to USB powered WaveIO boards (which I guess is not the case here):
it's stated that USB ports should source 0.5A but I have plenty examples where the current was less than expected because those PCs were poorly made.
My advice: please try to find LEDs with less current needed to lit accordingly. Or, you can add a simple CMOS buffer and put any type of low power LEDs you want there! :)

Thank you Lorien for the info:)

Nick
 
Thank you both for feedback!
:confused: I simply have no explanations... :cool:

Hi Lorien,
it could depend on how the outputs are driven by firmware and underlying hardware. If the computing unit is checking hardware regularily for upating the LEDs the main programm for computing the audio bitstream maybe disturbed regularily. I'm using an Intona USB isolator and there is a big difference sonically between the version with blinking LEDs and without. Maybe the "bigger" versions of the XMOS chips with separate computing units are more tolerant in this field.
 
Hi Lorien,
it could depend on how the outputs are driven by firmware and underlying hardware. If the computing unit is checking hardware regularily for upating the LEDs the main programm for computing the audio bitstream maybe disturbed regularily. I'm using an Intona USB isolator and there is a big difference sonically between the version with blinking LEDs and without. Maybe the "bigger" versions of the XMOS chips with separate computing units are more tolerant in this field.

Well, I'm not Ross from XMOS to be 100% but I can be 98% sure that XMOS firmware is not picking the pins for logic changes. I know this because, at some point in time - and trying to fix that LED display issue on my WaveIO when running on Linux - I wished to build up a routine to scan the pins and drive them accordingly. Well, I gave up... exactly because of this reason! And, No, is not already implemented otherwise this LED display problem would be over (which isn't)!
What I can be 100% is that LEDs are changed when the sample rate is changed. In case when you're playing more tracks having the same sample rate the LEDs are NOT changed (because that routine is not "hit")! I still have to dig into the issue and see what's happen there.
On another hand, I swear I'll add drivers to control LED on future boards! :mad:

As for bigger XMOS chips with more cores... I'm highly convinced this is a market scam Why? In WaveIO's firmware two cores are doing nothing - this is based on the reports getting from xTime IDE compiler! The chip I'm using does have 8 cores from which only 6 are used. Now, what difference would have in this case a bigger chip with more cores when 6 are enough for what I really need? I'm assuming more power to drain but in my head it will not fix this LED issue.

Dear Lucian,

After the update of my card I am experiencing some random unlock of the signal on 192k. I did not have this before. I also changed the power supply with a shunt regulator. Did anyone have similar experience?

D.
I'm assuming you have update the firmware on your WaveIO? .. or you're speaking about drivers? I have my own idea but I want to be sure!

Kind regards,
L