UAC2 Windows driver
Børge Strand-Bergesen
I hope you don't mind me moving this to a new thread. Please use this
thread to share your thoughts and ideas on how we may put together an
UAC2 Windows driver.
The ALSA project has Linux kernel support for USB audio including
UAC2. Could we reuse code from there, particularly on the protocol
side?
Libusb-win32 may is a candidate for lower-level USB programming on
Windows. Please read the intro at
http://sourceforge.net/apps/trac/libusb-win32/wiki
Driver signing needs not be a large issue. It is possible to set up
Win7's bootloader to open the doors wide and not require signed
drivers. That makes sense during development. Then for any released
driver there is the Reactos driver signing Nikolay found
http://www.reactos.org/wiki/Driver_Signing
Dean and George in a previous mail:
Its been a while since I did any serious systems programming, that is
why the virtual soundcard port to UAC2 is going to take some time (if
I can even make it), although a good sign is that I have the barebones
soudcard drivers working, now next step is to work out how to move
data between kernel mode (where the device driver runs) to user mode
UAC2 code.
I think if you take a stab and post your work on in the .git you will
gather a following. They may get in your way or they may be able to
help but you will generate interest either way.
Børge
dea...@hotmail.com
and I have no Linux experience (but have done Unix and a fair bit of
QNX). I don't even know what a git is, and I get annoyed with obscure
compression formats like tgz where the only Windows tools that open
these files are $50 utilities (why isn't the standard zip format
used???).
However I have looked into LibUSB as part of a Pic project from a year
back but it won't help much but the ALSA project source should help if
we can get it (with documentation preferably).
For the MSVAD driver I have to implement a shared circular buffer and
signalling system to the user-mode component that I will be writing
in .NET (basically a mixer / filter that hosts VST plugins). I plan to
use the excellent BASS audio library (www.un4seen.com) which I have an
extensive library of working audio code from another project (eg.
parametric equalizer), and it is from this .NET code that would be
easiest to make the USB UAC2 setup & calls (probably through a DLL
call). The .NET layer is specific to my project although still pretty
useful to be able to do mixing / processing generically. Is this
approach of interest?
I'm working on a SPDIF input AC3 decoder at the moment (using Bass)
which has priority for my limited dev time.
32 bit windows drivers won't enforce driver signing, its only really
needed for x64.
On Nov 8, 6:42 pm, Børge Strand-Bergesen <borge.str...@gmail.com>
wrote:
>
> I hope you don't mind me moving this to a new thread. Please use this
> thread to share your thoughts and ideas on how we may put together an
> UAC2 Windows driver.
>
> The ALSA project has Linux kernel support for USB audio including
> UAC2. Could we reuse code from there, particularly on the protocol
> side?
>
> Libusb-win32 may is a candidate for lower-level USB programming on
> Driver signing needs not be a large issue. It is possible to set up
> Win7's bootloader to open the doors wide and not require signed
> drivers. That makes sense during development. Then for any released
andrea montefusco
> compression formats like tgz where the only Windows tools that open these files are $50 utilities
Take a look at
*am*
--
Andrea Montefusco IW0HDV
Børge Strand-Bergesen
thanks for your response. The un4seen stuff is new to me. Interesting!
On Tue, Nov 8, 2011 at 10:45, dea...@hotmail.com <dea...@hotmail.com> wrote:
> I haven't done any open-source projects, I'm pretty much a Windows guy
> and I have no Linux experience (but have done Unix and a fair bit of
> QNX). I don't even know what a git is, and I get annoyed with obscure
> compression formats like tgz where the only Windows tools that open
> these files are $50 utilities (why isn't the standard zip format
> used???).
I'm pretty much a Windows guy with Linux experience. One thing I
always add to my Windows systems is Cygwin. Gives you a nice bash
shell so that I can grep for code lines. "tar xvzf stuff.tgz" will
Xtract, Verify and unZip the File stuff.tgz. "tar cvzf stuff.tgz *"
will Create, Verify and Zip * into the File stuff.tgz.
> However I have looked into LibUSB as part of a Pic project from a year
> back but it won't help much
OK. But have you tried the filter driver? I'll install it and toy with
it a bit.
> but the ALSA project source should help if
> we can get it (with documentation preferably).
The ALSA main page is here:
http://www.alsa-project.org/main/index.php/Main_Page I am not familiar
with ALSA work. Anybody on the group with alsa experience who could
elaborate and point to USB code?
> For the MSVAD driver I have to implement a shared circular buffer and..
So that is the stuff which says "Windows, I'm an audio device", rigth?
As in the opposite side of the driver compared to "Hello USB-thingy,
I'm your friend"? (Pardon me for sounding naïve here :)
> call). The .NET layer is specific to my project although still pretty
> useful to be able to do mixing / processing generically. Is this
> approach of interest?
Anything which brings us closer to an UAC2 driver is of interest! Will
the driver or the Windows OS be responsible for sample rate
conversion, should it be needed?
dea...@hotmail.com
the Linux compression formats at no cost.
MSVAD is the soundcard interface for the application. It installs as a
device driver (viewable in control panel) and can be enumerated in the
list of installed audio devices which your audio application can
select. The audio application sends its audio to the sound card device
driver (MSVAD) which is then diverted to a buffer. It is the code for
"Windows, I'm an audio device", which is about 1/3 of the needed code.
The hard bit is the UAC2 implementation, the spec has a lot of
features to support, there is no way I have the time to implement this
from scratch even a partial implementation (reusing code is the only
option). Looking at the UAC2 spec, it appears it is a full USB
implementation, so AFAIK it won't be possible to use the libUSB
filters (I could be wrong).
Regarding sample rate conversion and other niceties like automatic
installation when plugged in, that will take a lot more work unless
there is code readily handy to re-use.
Paolo 'UnixMan' Saggese
> compression formats like tgz where the only Windows tools that open
> these files are $50 utilities (why isn't the standard zip format
> used???).
I could say the other way 'round. Why dos/windows insist on using zip
when there were already tar, compress and gzip?
Unix and its tools were here long before DOS, let alone windoze. Yet
windoze pretend to reinvent the wheel (usually making it edgy if not
square) and call it "standard". No way. :@
BTW: I second Cygwin suggestion. It brings a (little) bit of Unix
power to that colorful useless mess.
You may also like this GUI supporting a lot of different archive
formats:
http://en.wikipedia.org/wiki/ZipGenius
P.S.: if you miss the power of DCL, you should try bash (on Unix/Linux,
of course. ;-)
Ciao,
Paolo.
--
http://borex.lngs.infn.it
You can still escape from the GATES of hell: Use Linux!
Save a tree:
please don't print this e-mail unless you really need to.
dea...@hotmail.com
running quickly on .NET if I want to do anything programmatic in
Windows. I must admit I have lost patience with complex command line
environments although that is where I started in IT.
On Nov 8, 9:13 pm, "Paolo 'UnixMan' Saggese" <pmsa4-goo...@yahoo.it>
wrote:
>
> > compression formats like tgz where the only Windows tools that open
> > these files are $50 utilities (why isn't the standard zip format
> > used???).
>
> I could say the other way 'round. Why dos/windows insist on using zip
> when there were already tar, compress and gzip?
>
> Unix and its tools were here long before DOS, let alone windoze. Yet
> windoze pretend to reinvent the wheel (usually making it edgy if not
> square) and call it "standard". No way. :@
>
> BTW: I second Cygwin suggestion. It brings a (little) bit of Unix
> power to that colorful useless mess.
>
> You may also like this GUI supporting a lot of different archive
> formats:
>
> http://en.wikipedia.org/wiki/ZipGenius
>
> http://www.zipgenius.com
>
> P.S.: if you miss the power of DCL, you should try bash (on Unix/Linux,
> of course. ;-)
>
> Ciao,
> Paolo.
>
Gregg Plummer
There might be some people there that will assist or join your efforts to
create a UAC2 Windows driver. I recommend at least subscribing to their
listserv, so you can monitor the discussions.
-Gregg
dea...@hotmail.com
info for Windows audio programming. Other useful resources are
http://www.osronline.com/index.cfm and
http://social.msdn.microsoft.com/Forums/en-US/windowspro-audiodevelopment/threads
I have the Windows audio programming side under control, its the USB
bits I'm not familiar enough with, I think I can work my way through
the Windows USB specifics but definitely need a hand with the UAC2
coding, ideally we want to copy an existing codebase rather than
coding from the spec, but also need to consider the licensing
implications.
Gregg, I have been following your work over a number of years for an
amplifier/receiver on a HTPC. How far did you get with that? You may
be interested in my latest project, which is a SPDIF input AC3 decoder
"receiver" for a HTPC, specifically to allow game machines to be
connected to a HTPC system and get AC3 surround without needing a
receiver. It seems no one ever solved this problem, which shouldn't be
too hard as long as the hardware passes the AC3 bitstream through. I
also recall you looking into an integrated amplifier / HTPC box, I
believe that is definitely do-able and the Hypex Class-D modules would
be very suitable. Unfortunately the market seems to moving to
standalone boxes like the Popcorn Hour for HTPC style functions.
George/Borg, I see on DIYAudio that several folks earlier this year
volunteered to help with coding up a Windows driver (Nikolay, Tdtsia).
What happened to them?
On Nov 9, 12:32 am, "Gregg Plummer" <gregg.plum...@gmail.com> wrote:
> Here's a resource you may want to look at:http://www.wdmaudiodev.com/
>
> There might be some people there that will assist or join your efforts to
> create a UAC2 Windows driver. I recommend at least subscribing to their
> listserv, so you can monitor the discussions.
>
> -Gregg
>
>
>
> -----Original Message-----
> From: audio-...@googlegroups.com [mailto:audio-...@googlegroups.com]
>
Børge Strand-Bergesen
> bits I'm not familiar enough with, I think I can work my way through
> the Windows USB specifics but definitely need a hand with the UAC2
> coding, ideally we want to copy an existing codebase
It'll be interested to see if any part of the ALSA implementation can
be recycled.
> George/Borge, I see on DIYAudio that several folks earlier this year
> volunteered to help with coding up a Windows driver (Nikolay, Tdtsia).
> What happened to them?
A lot of the people I have spoken to feel the tast at hand is too
large. I don't know about the guys you name, though. The more code
exists in a project, the easier it is to recruit.
Starting out with a virtual device which talks to players is good.
Then people with other skills can try bridge the gap towards the USB
side of things. Still a long way to go but must certainly shorter than
it was to begin with.
Børge
Gregg Plummer
connecting your PC via S/PDIF to a A/V receiver, you can connect your PC to
my device via FireWire. Now people are using HDMI to connect to their A/V
Receivers and are able to play high resolution audio (TrueHD and DTSHD-MA).
With my device you can play Blu-rays, but you have to rip to MKV and convert
the high resolution to FLAC. Basically the same result, just a little more
effort.
I ran out of money before I could develop a product that would be popular
with the HTPC niche.
There were a few other things I wanted to do.
First, I wanted to use an interface that was included on any motherboard, so
I needed to switch from FireWire to USB2. With USB2, you could still have
the same 8 channel, 24 bit/192 KHz performance. However, I couldn't afford
the cost of developing a proprietary multichannel driver. I was really
hoping Microsoft would provide a native USB Audio Class 2.0 driver with
their OS. I also wanted the scalability of FireWire in case someone wanted
to use more than 8 channels for digital crossovers in a
multi-driver/multi-speaker setup. I think you can still do this with USB2.
With the FireWire drive we are using, you can daisy chain the DACs and it
will just multiply the number of available channels by however many you
have.
Second, If I was going to offer an integrated DAC/amp, I wanted to reduce
the footprint and weight by replacing the monstrous toroid/linear supply
with SMPS. However, I wanted an SMPS that didn't sacrifice sound quality. I
haven't been able to determine if this is the case. Manufacturers like Hypex
don't really say much about the SQ of their SMPS.
Third, I wanted to upgrade the SQ of my device by using the ESS Sabre ES9018
DAC and the upcoming Hypex NCore amp modules.
Fourth, I'd like to create a modular system that allows users to snap in
components to either build or upgrade their audio system. So we'd need to
standardize things like the chassis, the main board, power supplies, DAC
modules, amp modules and interconnects. So you'd have capability similar to
what a PC enthusiast has when s/he purchases components from Newegg to build
or upgrade a PC.
I was also probably going to offer separate components, so you could just
buy an external DAC, without the amps.
As you know, some of the pieces are/were coming together. Now there's the
exaU2I USB to I2S interface and 8 channel DAC kits like the Buffalo III or
the AckoDAC ES9018 system. However. I'm not sure exa's drivers are ready for
a commercial product. There's just too many hoops to jump through to play
full resolution audio from a Blu-ray (or Blu-ray rip) running Windows 7 and
Windows Media Center. It probably works pretty well for JRiver Media Center
and Foobar or other products for enthusiasts. However, I really wanted to
create a product that my less-than-computer-fanatic friends and family could
simply plug in and use.
If I ever come across a chunk of money and the driver situation improves,
someday... Hopefully this project will make a lot of headway. I'd be happy
to license open source components.
Nikolay
Some things about driver:
Samples code:
Apple sources usb audio: https://github.com/nixxcode/AppleUSBAudio-273.4.1
USB audio driver source for EMU CA0188- and CA0189-Based external
audio devices (I don't know it's working or not)
for windows http://sourceforge.net/projects/zaudiodriverwin/ (may be
used as start point)
for apple https://github.com/indeyets/zaudiodrivermac/
DDK & driver debug related:
http://visualddk.sysprogs.org/
http://virtualkd.sysprogs.org/
And possible variant driver: use ASIO in user mode + usblib in kernel
Nikolay
Børge Strand-Bergesen
The ZAudio pages at Sourceforge look empty. I take it that is a
project with no USB but with plenty nuts and bolts and Windows OS
interface.
As I see it, we need (at least!) two fundamental things here. The
first is to present an audio interface to Windows. This is where
Dean's work can come in handy, and where existing Windows Drivers are
very usefull.
The second fundamental thing is where we talk to an USB interface over
the UAC2 protocol. This is where I'm hoping ALSA code and libusb-win32
can play a role. Unfortunately, I don't know how much hassle is
involved in making Linux USB code happy on a Windows system.
Installing a libusb-win32 shadow driver for the UAC2 option in the
audio-widget-nik branch went smooth. (Before this I removed any UAC2
driver which recognizes our VID/PID.) Now the question is what can be
done using their driver to talk to the widget.
Two AB-1.1 kits go out free of charge as a bonus to the first guy who
can put together some code to make it go beep over UAC2 :-)
Perhaps this is easier with firmware which doesn't give rate feedback?
Børge
Nikolay
On Nov 9, 7:25 pm, Børge Strand-Bergesen <borge.str...@gmail.com>
wrote:
>
> The ZAudio pages at Sourceforge look empty.
> This is where I'm hoping ALSA code and libusb-win32 can play a role.
applications
> Perhaps this is easier with firmware which doesn't give rate feedback?
Nikolay
Børge Strand-Bergesen
> Driver over libusb can't be used for standart windows multimedia
> applications
Why? And what could be possible alternatives?
Børge
Nikolay
windows without realization of specific functions directly in the
driver and register this driver in system as audio device driver.
At the initial stage, probably, it is possible to use winusb for
algorithm debugging, but the normal driver is all the same necessary.
Still it is possible to realize ASIO the interface with libusb. Some
programs, for example foobar, are able to use ASIO. ASIO is COM-object
working in user mode and may interact through libusb with widget
Nikolay
On Nov 9, 8:07 pm, Børge Strand-Bergesen <borge.str...@gmail.com>
wrote:
Børge Strand-Bergesen
Dean may be able to create a virtual device which appears to Windows
as an audio device. Libusb won't be involved there.
But libusb may be a good tool to talk low-level to the USB device. My
promised rerward is for libusb (or similar) + Audio Widget = annoying
beep through DAC :-)
Then, somewhere between Dean's code and libusb is my hope to reuse as
much existing (ASIO / ALSA / other drivers) code as possible.
Børge
dea...@hotmail.com
just had to compile the Win DDK MSVAD (simple) sample. I have to write
an installer for it as install currently is manually thru registry &
utilities. It uses a ring buffer that a user-mode application can pull
data from.
I'm not clear on the USB bits, AFAIK libUSB can't be used unless you
can implement UAC2 protocols over libUSB. If we can get the libUSB or
ALSA driver working on Windows it would be easy to bridge the the two
drivers using some user mode code (sounds clunky but actually a great
place to insert a mixer/filter). I looked at the UAC2 spec on the
weekend and no way do I want to implement it from scratch, even a
partial implementation, ideally you want to reuse code that runs
successfully elsewhere. I'm not sure how far I would get on my
workbench as I don't have any audio-widget hardware (need to decide if
George or Borg's implementation is better for tweaking & purchase a
kit!)
On Nov 10, 1:01 am, Børge Strand-Bergesen <borge.str...@gmail.com>
wrote:
Børge Strand-Bergesen
good to know the virtial device came up that fast!
> I'm not clear on the USB bits, AFAIK libUSB can't be used unless you
> can implement UAC2 protocols over libUSB. If we can get the libUSB or
> ALSA driver working on Windows it would be easy to bridge the the two
> drivers using some user mode code
I share that opinion. I was hoping libusb could be the library by
which a Windows UAC2 driver talks with the audio widget. We will need
isochronous support. That rules out quite a few USB libraries for
Windows. In an ideal world there is a way to replace ALSA's USB kernel
calls with wrapper code + libusb.
> as I don't have any audio-widget hardware (need to decide if
> George or Borg's implementation is better for tweaking & purchase a
> kit!)
With mine you won't have to solder :-)
Cheers,
Børge
George Boudreau
The 'no solder' option is attractive and you will have a unit that runs out of the box. With mine you can kill a day or so looking for that solder joint :) I still have inventory for 3 kits so I can supply you with one if you love the smell of solder in the morning.
Cheers,
Børge
George
"If you build it... it will run"
dea...@hotmail.com
need to take a closer look at both your & Georges schematics to see
which better suits my needs & who has the better components (I don't
want to go chasing down too many new parts like clocks).
A question about UAC1 support for Windows - although the widget will
only run in 16bit/48K as a maximum bitrate, as it can run in true
asynchronous mode we should still be able to get bit perfect transfer
and low jitter, so apart from the support of higher sample rates there
is no other (audio quality) advantage of using UAC2?
I see a lot of traffic here & on DIYaudio for the I2S and USB
implementation, but almost nothing about optimizing the audio quality
of the analog sections.
My current goal is to replace my tweaked EMU 0404 on my main PC for a
better PC audio setup so looking for a great sounding DAC but doesn't
need to be super tweaked-out. But the main goal is to replace my DAC
in my home theater which needs the digital and analog section to be
top notch as well as supporting 6 HiRez channels - this is the reason
why I'm interested to help out with the UAC2 driver but just as you
would like support for writing the driver, in return I'd like support
for a multi-channel implementation & better analog.
Back on topic for the driver, it probably is worth exploring libUSB, I
have a little experience with it from a previous project. But does it
support Isochronous asynchronous data endpoints and sample rate
feedback? The driver will also need to support data throttling
commands from the DAC due to the difference in clocks, unless the
firmware includes large buffers, and this is why I think we will
struggle with finding code easy to reuse except from the Linux source
itself. More investigation needed.
On Nov 10, 6:24 am, Børge Strand-Bergesen <borge.str...@gmail.com>
wrote:
George Boudreau
Solder is OK as I worked out how to solder that 144 pin monster! I
need to take a closer look at both your & Georges schematics to see
which better suits my needs & who has the better components (I don't
want to go chasing down too many new parts like clocks).
Borge uses a 2 high quality clocks with a discreet component selector while I used a custom (Silabs Si532) dual frequency, .3ps jitter clock generator..
dea...@hotmail.com
George Boudreau
Alan Hill
73's
Alan - W6ARH
Børge Strand-Bergesen
did a lot of XO searches and ended with the Golledge parts. We based
our comparisons on SSB measurement charts from suppliers, not
listening tests. We chose the better XOs based on the info available.
Alan, I guess having a working UAC1 driver would be a tremendous help.
Then we can start with a UAC1 firmware and slowly introduce UAC2
features in firmware and driver alike.
Børge
dea...@hotmail.com
start, not sure if its going to help much in the UAC2 quest.
I didn't get an answer to one of my posts above - Does the audio
widget run in UAC1 asynchronous mode (ie. the only difference between
UAC1 and 2 is the higher sample rates?). If that is the case I'd be
willing to work on UAC1 code initially as the project I want to use
the audio-widget for is 44.1K sources, so higher bit/sample rates
don't help. However I am interested in this project evolving into a
multi-channel HiRez solution (similar to the AckoDAC kits but
hopefully at a cheaper price point!).
On Nov 10, 8:03 am, Børge Strand-Bergesen <borge.str...@gmail.com>
wrote:
> did a lot of XO searches and ended with the Golledge parts. We based
> our comparisons on SSB measurement charts from suppliers, not
> listening tests. We chose the better XOs based on the info available.
>
> Alan, I guess having a working UAC1 driver would be a tremendous help.
> Then we can start with a UAC1 firmware and slowly introduce UAC2
> features in firmware and driver alike.
>
> Børge
>
>
>
> On Wed, Nov 9, 2011 at 22:44, Alan Hill <alan.r.h...@gmail.com> wrote:
> > How hard would it be if you had the source of the existing UAC1 driver?
> > 73's
> > Alan - W6ARH
>
Børge Strand-Bergesen
the UAC1 is asynchronous. Nikolay has the details.
It's great that you wish to participate! Will you sneak a peak at ALSA
UAC1 code?
Assuming working UAC1 driver code is written, I believe UAC2 features
may slowly be introduced to UAC1 driver and firmware alike.
Børge
dea...@hotmail.com
another audio software project that takes priority but its almost
done. I have my dev machine loaded up with the DDK and the driver
running, now I have to look into the USB code which I'm not as
confident with. If there was another coder more familiar with USB
systems programming that would be better.
I also have to order & assemble the hardware before undertaking any
serious coding.
On Nov 10, 8:49 am, Børge Strand-Bergesen <borge.str...@gmail.com>
wrote:
> Dean,
>
dea...@hotmail.com
FYI - I am considering an alternative path at the moment, there are
new hi-speed USB module from FTDI that allows serial transfer from PC
to external USB hardware. Although this solution won't be standards
compliant (not that it matters too much), as I have the soundcard
driver working and I have a lot of experience with the FTDI serial
modules I can see the light at the end of this tunnel to produce a
multi-channel USB to Is2 solution without too much coding or hardware
implementation.
There is a new thread on DIY audio here:
http://www.diyaudio.com/forums/digital-line-level/200448-24-channels-usb-i2s-interface-source-codes-asio-vhdl-schematic.html
Børge Strand-Bergesen
I understand your choice of the path of least resistance... In the
meantime I am discussing USB techniques with colleagues. Outcome not
yet certain.
BUT: Are you able to share your virtual device driver code? The USB
guys I talk to have no idea how to make Windows aware of a soundcard
(and I guess vice versa, that those here who can talk Windows don't
necessarily talk USB.)
Thanks,
Borge
jkenny
dea...@hotmail.com
DDK is all that I have used so far with very little modifications.
Download the free latest Windows DDK and install it, then go to the
audio drivers and look at the samples called MSVAD (virtual audio
driver), There are a number of samples including multi-channel,
filters, etc. you want the one titled simple, and it contains the
entire driver framework. Run the build environment command line
interface, change directories to the Simple source then run the build
(build -cZ) batch file to compile & link the sample. Use the free
Visual studio C++ express to modify the code. You actually don't need
to touch the driver framework, there are CopyFrom and CopyTo routines
that you can modify to move data into and out of the driver, but be
aware that the driver is working in kernel mode so be careful if you
are putting extra (eg. USB) code inline with the driver as it can
cause the PC to crash. Better approach is to use CopyFrom/To to move
data between a shared ring buffer and write your extensions in a user
mode application. You need to run the devcon utility to install the
MSVAD driver as there is no installer code. Let me know if you need
any help with it, here is a helpful post & forum to use:
http://social.msdn.microsoft.com/Forums/en-US/windowspro-audiodevelopment/thread/68ac63f3-7bb1-45b0-9677-957d7aa9f2d9
Regarding FTDI serial driver, further investigations shows this is
definitely the path of least resistance for hi-speed and multi-
channel. Koon on the DIYAUDIO forum has got a basic implementation
working and shared the code, and there is literally only 10 extra
lines of code I need on the PC / MSVAD side for a multi-channel USB
driver, although I will have to learn how to program FPGA and build a
programmer. The FTDI hi-speed module is only $20 and it will save all
that work for writing UAC2 code, bargain! I am experienced with Pic
micros (which are too slow for this application) and the FPGA stuff
looks easier than I first thought, definitely easier than writing the
UAC2 code on the PC side. It is an asynchronous solution, as the PC
end writes to the FTDI driver through an API as if it was a serial
port, very easy (all the USB communication handling is done by the
FTDI hardware/drivers), and the receiving end makes the data available
in a 8 bit FIFO port that the FPGA can extract (via a larger FIFO
first for buffering).
George Boudreau
There is nothing wrong with the FT2232H or the Cypress FX2 series of devices and if you can write kernel level audio drivers then we can create a fork of the audio widgets that support that design. As Dean mentioned Koon has already created a system that will give you 8 or 24 channels with an ASIO driver. He has used a patchwork of commercial cards but there is nothing preventing us from distilling his design down to the bare bones and creating custom hardware.