Open-source USB interface: Audio Widget - Page 4 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Source

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 30th April 2011, 06:52 AM   #31
diyAudio Member
 
Join Date: Apr 2011
Hi Mr Tsai,

Excellent news !!! You obviously has the expertise to develop the windows uac2 driver to support the audio-widget :-)

We have full control over the widget firmware so I am positive that we can get the uac2 driver and the widget working !!!

We did a similar thing working with the Linux uac2 driver kernel developers to sort out the bugs and interpretations of uac2 and so the widget works very well under Linux kernel 2.6.37 and later.

One key issue with Win driver is that the widget currently enumerates as a composite device, with UAC, hid, and a libusb interfaces. I understand that windows may not easily allow a uac2 interface to be part of a composite USB device. If it is too difficult, we can change the widget firmware image to a single audio device, if need be.

I am traveling right now and cannot do a descripter dump for u, but George or Roger or Liftur might be able to do so :-)

This is very exciting a development for us and it will be great fun testing out the driver during the development cycle - am anticipating many blue screen of death before we have it debugged :-)

Alex
  Reply With Quote
Old 30th April 2011, 11:15 AM   #32
tdtsai is offline tdtsai  Taiwan
diyAudio Member
 
Join Date: Feb 2011
Hi Alex:
I had check the descriptor, its seems mix UAC 1.0 and UAC 2.0. For example Feature Unit descriptor seems use UAC 1.0 format not UAC 2.0 format. And you had add 2 Clock source Unit and one Clock Selector Unit. I can't understand why you need Clock Selector Unit? And the stream format descriptor also is UAC 1.0 format. I think you have better to modify you firmware to make those descriptor more correct.
You can reference follow device's descriptor
Home Audio :: Digital to Analog Converters :: MHDT Labs USBridge USB to SPDIF converter - ALO Audio

BR,
Tzung-Dar Tsai

Quote:
Originally Posted by alexlee188 View Post
Hi Mr Tsai,

Excellent news !!! You obviously has the expertise to develop the windows uac2 driver to support the audio-widget :-)

We have full control over the widget firmware so I am positive that we can get the uac2 driver and the widget working !!!

We did a similar thing working with the Linux uac2 driver kernel developers to sort out the bugs and interpretations of uac2 and so the widget works very well under Linux kernel 2.6.37 and later.

One key issue with Win driver is that the widget currently enumerates as a composite device, with UAC, hid, and a libusb interfaces. I understand that windows may not easily allow a uac2 interface to be part of a composite USB device. If it is too difficult, we can change the widget firmware image to a single audio device, if need be.

I am traveling right now and cannot do a descripter dump for u, but George or Roger or Liftur might be able to do so :-)

This is very exciting a development for us and it will be great fun testing out the driver during the development cycle - am anticipating many blue screen of death before we have it debugged :-)

Alex
  Reply With Quote
Old 30th April 2011, 09:46 PM   #33
diyAudio Member
 
Join Date: Apr 2011
Hi Tsai,

The descripter dump was created with the wrong (old) version of lsusb which does not u derstand uac2. George has generated the correct uac2 dump which he will forward to u and it is also found here:

http://db.tt/SRBL4Ad

Best regards,

Alex
  Reply With Quote
Old 1st May 2011, 10:01 PM   #34
UnixMan is offline UnixMan  Europe
diyAudio Member
 
UnixMan's Avatar
 
Join Date: Apr 2005
Location: Perugia + L'Aquila, Italy
Send a message via ICQ to UnixMan
Quote:
Originally Posted by borges View Post
If there is source material which is properly recorded, I say let's do what it takes to get it out.
well, yes and no.

In principle DXD is supposed to become the new standard for digital masters and eventually for end users too (although of course nobody knows whether this is really going to happen..).

To date even 24/192 source material is scarce... for DXD I'd speak of just a few "samples". But they are indeed already available (including some free downloads).
__________________
Quote:
"We should no more let numbers define audio quality than we would let chemical analysis be the arbiter of fine wines." N.P.
  Reply With Quote
Old 2nd May 2011, 03:11 AM   #35
diyAudio Member
 
Join Date: Jul 2008
What is the purpose of the second CLOCK_SOURCE? It looks like CS4 and CS5 are supposed to correlate to 22.6MHz and 24.6MHz master clocks, but instead of using a CLOCK_MULTIPLIERs to derive the support sampling frequencies, it looks like the Clock Freq. Control and Clock Validity Control are expected to be used to configure the clock hierarchy. Is this correct?
  Reply With Quote
Old 2nd May 2011, 07:51 AM   #36
borges is offline borges  Norway
diyAudio Member
 
Join Date: Dec 2003
Location: Oslo, Norway
Hi Blushift,

Not sure what you are referring to just here....

But I'll let you know about the clocking scheme for the audio:

On AB-1 we use 22.5792 to play back 44.1, 88.2 and 176.4ksps. 24.576 is for 48ksps. The ratios are 2^n. Both clocks are available on AB-1 as good XOs, so nothing passes through a PLL or any digital dividers from XO to DAC.

But the MCU can't handle clocks about 16-ish MHz, so we divide the clocks down to 11.2896 and 12.288MHz, multiplex them into the MCU and repeat the same MUX function on AB-1 using analog switches.

Since these clocks are switched, a separate always-on clock is used to drive the MCU.


BÝrge
  Reply With Quote
Old 2nd May 2011, 05:45 PM   #37
diyAudio Member
 
Join Date: Jul 2008
I'm referring to the contents of the descriptor dump; there are 2 CLOCK_SOURCE's and 1 CLOCK_SELECTOR, which from my interpretation of the UAC2 spec were supposed to control the sampling rate of a terminal.
  Reply With Quote
Old 2nd May 2011, 06:21 PM   #38
diyAudio Member
 
Join Date: Apr 2011
Hi Blushift,

U are correct in your interpretation of the uac2 descriptor :-)

Uac2 is so flexible that there are many ways to skin the cat. We have been tweaking the descriptor to work with the uac2 drivers. We have been trying to make the descriptor and UAC request processing to be compatible with Mac OSX and Linux. At that point in time the Linux driver did not support clock multiplier. Even today the Linux driver clock selector/clock source is not able to parse some corner cases and we have to put in workarounds in the firmware.

So the current clock sources, one for the 44.1x sampling freq and one for the 48x freq is a good representation of the underlying hardware of two ultra low jitter XO's, as Borge has explained. This will pave the way for FUTURE drivers which can intelligently select and configure the best clock for the particular playback situation in the fly - ie without any re-sampling for bit perfect reproduction.

However, it looks like the current windows uac2 driver we are trying to interface with does not support clock selector. So we are planning to have a branch of the firmware that had only a single clock source and no clock selector. We will have a workaround such that all the 6 freq: 44.1/48/88.2/96/176.4/192 will be available and the firmware will switch the correct XO internally depending on the sampling freq set by the driver.

The descriptor will evolve as the driver/
Firmware get more aophisticated.

Alex
  Reply With Quote
Old 2nd May 2011, 08:59 PM   #39
diyAudio Member
 
Join Date: Jul 2008
Interesting. I'm debating spending some time writing a driver as well, just to play around with. It seems like it shouldn't be incredibly awful; basically the MSVAD simple sample mixed with the usbsamp isochronous sample code and an intelligent DPC routine to efficiently transfer the data. Of course, the devil's in the details.

Windows-isms follow: it looks like the DPC just needs to pull from a WaveCyclic queue and transfer it appropriately--the "top" part of the driver that puts the bytes into the queue is basically the MSVAD driver. In fact, the MSVAD driver is overkill right now--it has volume control and other bits and pieces that are irrelevant, but it would be nice if the driver would configure the accessible parameters based on the available FEATURE_UNIT's, so it's nice to see how they're configured now.

The really unwritten part is the isochronous transfer to/from the endpoint that chooses the packet size based using feedback endpoint. I'm only looking at handling asynchronous UAC2, and am ignoring synchronous and adaptive transfers; they're probably simpler than asynchronous and might come for free if the rest of it works, but right now I don't really care. Or maybe I should start with synchronous and go from there? My own problems stem from not really having experience with USB that isn't on an embedded device (e.g. Cypress Semi's EZ-USB or AVR V-USB), and isn't a simple HID device. I've yet to read up on the isochronous feedback and synchronization mechanisms in the USB spec, and I know very very little about Windows WDF USB stack--I've used WinUSB, but it doesn't support isochronous transfers at all.

Really, we should all just be posting and asking MS on the wdmaudiodev listserv asking for a properly supported driver, because it seems like no one has talked about the absence of a UAC2 driver in Windows for a few years now. Maybe we all pitch in to spot them a device to experiment with, if they don't already have one? They're really great people over there; very smart, and they truly do care about the success of Windows. Open-source would be nice, closed-source free would be great too, but my personal preference would be MS-supported closed-source (MS-supported open-source being a pipe dream).
  Reply With Quote
Old 3rd May 2011, 01:40 PM   #40
diyAudio Member
 
Join Date: Apr 2011
Hi Blushift et al,

U are welcome to try writing a windows uac2 driver as well :-). The more alternatives we have the better.

As I mentioned before, it is technically possible to write a windows uac2 driver that works with a single audio device. There are several commercially available drivers around. However, AFAIK, no one has written a driver that can work with a composite USB device that has uac2 plus something else eg HiD.

Async out is the most desirable mode for bit perfect low jitter transfer, but u might like to start with simpler modes first in the driver development.

Native uac2 support is available with OSX and Linux now. I am waiting for support under Android, which should happen soon as the Linux kernel is used in Android.

I think we will have working windows uac2 from Tsai or u much sooner than M$. It is nit that they are not smart enough to do it - it is the motivation or lack of :-)

Alex
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Async 192Khz USB - the SDR-Widget collaborative project SunRa PC Based 5 26th April 2011 06:38 PM
usb audio interface david12 Equipment & Tools 14 10th October 2010 02:58 AM
Cheap Audio Interface (USB?) to PC agm2003 Instruments and Amps 11 16th September 2007 07:48 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 07:33 AM
USB Interface Perfect?- Computer Audio fmak Digital Source 3 4th December 2004 10:24 PM


New To Site? Need Help?

All times are GMT. The time now is 04:13 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2