Modular multi channel DIY AD/DA Box

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
The nice thing about a FPGA solution is definitely the freedom to choose your protocol (we wouldn't be limited to MADI, ADAT or AES51). Though, in reality, you still need a chip like Marvell 88E1116R to interface with Ethernet for example. Even if people wouldn't like to use routers, an additional gigabit ethernet card is way cheaper and more readily available than a dedicated MADI/ADAT card..
 
Yes and even 10 Gigabit interfaces are coming allowing even larger systems. Gosh I wish I had some experience in this field of programming, I would gladly help you baadc0de ;) How about harnesing Open source community to help with FPGA? This project will be huge hit and benefit everyone 8)
 
baadc0de,
you are definitely right. One might need a physical layer ethernet chip in the converters interface. But the interfacing on PC (or MAC) side is, where it gets interesting really, esp. from the financial POV...
It didn't let me sleep, I wanted to know how hard it would be to do a driver for, say Win XP...(hardest one first...)

Actually I investigated and came up with the following on my machine:

- I found a simple open source raw packet driver for xp. It has to be installed as a protocol for the physical ethernet port and accepts a (predefined) number of bytes raw data.
I installed it thru the network devices property page and disabled all other protocols.
After a reboot, I launched a test app that was able to identify the device that the protocol was applied to and sent some twenty bytes of raw data directly to the ethernet. Voila, it was way more easy as I ever expected to bypass all those nasty network layers, cool!
I found a similar driver for linux, even more easy I guess. Did not test it...

-Now, that I grew more confident, that the computer side is doable without aeons of development time, I got heroic and installed the latest WINDDK.
(I had no good feelings from my last try in developing a driver, has been a while ago...)
Starting the development environment I found they have a new virtual audio sample driver - WDM with full support for waveformatextensible !!
(Was a big issue in development once, noone ever shared sources on this kind of drivers really....remember the difficulties to obtain drivers from several companies for NT and upward some yesars ago?)
Exactly what is needed for developing a multi channel driver with more than 16 bit!
I instandly built that thing (yes it worked flawlessly from command line and compiled with just 2 warnings...) and got a driver file (sys).
I installed that one with the 'New Hardware Wizard', because it has no hardware relation. Guess what, an example .inf was included by MS and exactly worked like it should. Great.
Fired up my Sonar DAW: The WDM driver was tested working with the specs defined in the driver as an 8-channel device. OK, it actually does nothing right now, but it was flawlessly loaded, identified and exposed itself exactly like any other multichannel card driver would do.
Wow, much more than I expected from a few hours of investigation...

TODO's:
-expanding the virtual audio driver with I/O functions to communicate to the raw data NDIS driver.
-Decide on a lightweight audio data protocol and implement.
-setup another machine with the same drivers.
-Test 2 daws communicating to each other and measure roundtrip latency! BTW this would be a cool application even with no converters involved - each daw would see the other one as a soundcard thru their ethernet cards.
I really hope it works in the region of 'realtime'...
After tests with WDM/KS, I will try to test the same with Asio4All, so everyone will take a look at this point latest ;D.

Well, now I am more than surprised that the seemingly hard parts (bypassing network layers/functional multi channel wdm audio driver skeleton) actually are no rocket science anymore....like it seemed to be some years ago.

I hope someone will try his digital hardware skills on the converter side of things (something I am not nearly that deep into)....

Kind regards and feel free to drive this project further,
Martin

 
 
Wow, good finds Martin.

A few additional points to ponder on, if I may..
- people will be configuring these A/D D/A boxes in a plethora of configurations (12 out, 36 in... whatever) so there must be means to configure the driver, either through querying the other side over ethernet or a settings panel of some sort. Also there would need to be a mechanism for setting the default sample rate
- we can send/receive raw packet data through the good ol' WinPcap: (http://www.winpcap.org/)
- I would urge, however, that the audio protocol still use ethernet as the phy layer... this would be useful because you can use ethernet switches, repeaters, cable extenders, physical layer converters etc. that are on the market already to ease installation in the millions of configurations people would probably like to use this with

Some ideas:
- i'd create a sourceforge project (as a name, openaoedrv is available..) so that the code is available to everyone
- first idea is probably indeed to create a loopback/remote driver where two DAWs could exchange audio through a lightweight audio over ethernet protocol (what a mouthful!). This is a good idea because then the driver is tested thoroughly on the PC side and can aid HW debugging
- OC FPGA community might be interested in creating a FPGA core that would be compatible with this driver or at least helping with that, does anyone know how to make them interested?
 
Please don't make this too Windows-centric.
Oh, under Linux (and Mac, I think) there's Netjack, which allows audio streaming over Ethernet. Open Source, of course, so maybe someone proficient could have a look at their network code.
 
As far as I have seen Netjack is IP-based, thus it would be much harder to write FPGA code for it. As for supporting other OSs, the driver would be open source and someone proficient should have none too much problems converting it to Linux. As for CoreAudio and mac, i'm sure if nobody else, I'd be delighted to port it, but not before it works on windows.
 
Well, I said 'hardest first' when talking about windows wdm drivers...
I do not know enough about linux and mac driver architecture, really.

At this point, it is all at a very early stage - when the driver evolves (and my practice in driver programming, too), I hope it could be useful even without an additional converter stage, as am ethernet inter-pc soundcard. So I just started work without any confirmation someone would do an fpga design...
Right now, I am not sure about possible licensing issues with wdk and publishing the source - but it's not worth it anyway at this early stage. Nevertheless I will publish the source at a later point, when the driver is more than a skeleton.
I already figured out, how to set max number of channels and bit depth to show to the system. Nevertheless, the 'real' functionality is still missing and I have to dig much deeper now.

I am aware of my posts beeing maybe alot tooo MS related for the Mac people out there, I am sorry for that.
I would really be interested if a  Mac solution for raw data transfer over ethernet is possible as well...

Kind regards,
Martin
 
If a driver would use WinPCap for Ethernet information exchange, it would be much simpler to port to Mac and Linux because libpcap (UNIX equivalent lib) is available on those platforms.

I would suggest that the Ethernet communication part be abstracted away (and use *PCap) so that specific OS interfacing may be done separately for any of the OSs concerned. More or less there will be provisions in all of the OSs to: attach/detach client, query/set configuration, read/write data and possibly some sync commands.
 
Someone with experience in programming for osx out there, possibly?

Winpcap looks nice on paper, never worked with, will study...
Win-style driver models are really complicated, will try to document the relevant portions of code with portable functionality. Grr, i liked c-style programming so much more than c++, *sigh*. (Coming from pascal/delphi.)
Hope to get something usable worked out.

Thanks for the input.
Kind regards,
Martin
 
Hello everybody,

before talking about the driver you should think about the hardware. Who is willing to make a fpga program etc. Writing a driver is IMHO not so difficult at least not on *nix systems like Mac and Linux. Windows? Who is using that? We should talk about real operating systems not about toys...  ;D
However think about the hardware first.

Coming back to phase one of this project: The design of the AES receiver/transmitter is almost finished. I'm doing the last little tasks on it: Some voltage regulators and some pin headers have to be added. I hope I can finish that over the weekend because the next days I have to be away on business.
But some words already on the design:
There wil be only one board for all AES interface configuration. The same board can be used as a receiver or a transmitter or both full-duplex. You can either use it as a two mono channel receiver or two mono channel transmitter in the smallest configuration up to 12 mono channels in and 12 mono channels out. It depends what you put on the board and you can always upgrade later by stuffing the next group of parts. The size of the board is the standard euro pcb size (160mm x 100mm).
More details will follow later.

Raphael
 
Nice to hear you make so good progress on the AES board!
So there are AES and ADAT (dantimax) solutions available soon - enough for lots of people to get started, I guess!
Thanks for all effort you put into this.

Windows? Who is using that?
Ah, well, me and a few people I know. I quit using Mac at 8.5...
Well, we are freaks and just a small community of commandline hackers, but may grow soon and sometime in future we...eh... oops, STOP, I mixed up Win and Linux....
:p :) ;)

Kind regards,
Martin
 
I understand AES is superior in offering higher sample rates than ADAT, but how are we supposed to get AES into our computers? The only AES cards I've seen cost a fortune. Any cheap methods for many (ie. 24-36) channels? If not, what's the point, besides for the sake of it?

Ideally I think firewire connectivity would be best but then someone has to write and support drivers and seeing the trouble actual companies have doing this with stability I'd be nervous.

If not that, at least there exist cheap, large channel count ADAT > firewire converter boxes that will work well. But for that we need ADAT outs.
 
Moby said:
I would really be interested if a  Mac solution for raw data transfer over ethernet is possible as well...
Me too, please think about Mac users  ;D
Well,my idea wasn't so bad but it seems that developing such a driver isn't a piece of cake. I'm afraid that there is no much guys ready to do that , especially withouth "additional motivation" ;)
 
audiovisceral said:
I understand AES is superior in offering higher sample rates than ADAT, but how are we supposed to get AES into our computers? The only AES cards I've seen cost a fortune. Any cheap methods for many (ie. 24-36) channels? If not, what's the point, besides for the sake of it?

The Lynx AES16's provide 16 channels of AES I/O in a single PCI card for $600-$700. You get 24 channels of MOTU ADAT I/O for just under $1k. RME's HDSP(e) provides 24 channels of ADAT I/O for about $700...
The thing I like about the MOTU is that you can add additional I/O boxes to the 424 card to provide up to 72 channels of I/O and the CueMix software is very flexible for routing and preparing cue mix's.
And if you would be integrating this with a PTHD system, you have the option of either AES or ADAT with the digital 192's.

I am personally interested in both ADAT and AES options.

Cheers,
j
 
Reminder:
Ethernet based solution: use your existing network card = 0€ for what 72 I/O (with gigabit card that has been standard for years)... Of course ASIO drivers aren't available yet and lacks routing software (unless someone does one). Obviously the best choice over what ever commercial interfaces ;) Ethernet standards keep getting faster, firewire is propably going to be burried when USB 3 comes...

My point: Anyone who can help baadc0de and smallbutfine please chime in ;)
 
tmuikku said:
Reminder:
Ethernet based solution: use your existing network card = 0€ for what 72 I/O (with gigabit card that has been standard for years)... Of course ASIO drivers aren't available yet and lacks routing software (unless someone does one).

Exactly,

Ability to utilize an additional, significantly different interface to my existing RME ADAT ASIO Interface, Apogee AD16-X, Benchmark DAC-1 system in my DAW = ZERO (0).  :'(

Ability to seamlessly add another ADAT I/O converter into my existing setup = EASY.  8)

I suspect many are in the same position.

Mark
 
Biasrocks said:
tmuikku said:
Reminder:
Ethernet based solution: use your existing network card = 0€ for what 72 I/O (with gigabit card that has been standard for years)... Of course ASIO drivers aren't available yet and lacks routing software (unless someone does one).

Exactly,

Ability to utilize an additional (and significantly different) interface to my existing RME ADAT ASIO Interface, Apogee AD16-X, Benchmark DAC-1 system in my DAW = ZERO (0).

Mark

Oh well, obviously, But you could sell your stuff and spend it building rkn80 AD/DA :D Enough, ADAT/AES is readily available, ethernet stuff in far future. Nevertheless I'm excited 8)
 
tmuikku said:
Reminder:
Ethernet based solution: use your existing network card = 0€ for what 72 I/O (with gigabit card that has been standard for years)... Of course ASIO drivers aren't available yet and lacks routing software (unless someone does one). Obviously the best choice over what ever commercial interfaces ;) Ethernet standards keep getting faster, firewire is propably going to be burried when USB 3 comes...

My point: Anyone who can help baadc0de and smallbutfine please chime in ;)

Ethernet sounds awesome if it can be done.
 

Latest posts

Back
Top