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.
It looks like it has 8 adat ins and 8 adat outs giving 64i/o of conversion from adat to madi.  Still, wouldn't mind bypassing the adat portion all together and just having a madi.

-Casey
 
I've been looking into this. MADI is the route I want to go, unless somebody comes up with a LAN solution before I'll start working on it (should be enough time even if you start now :D). I wouldn't be using ADAT, but I²S <-> MADI directly of course. There isn't that much to it, MADI is basically I²S packages of each channel packed together into one frame plus the protocol overhead. It's not overly complex and should be perfectly doable.

But, I haven't even started populating one ADC/DAC board and I don't see that happening anytime soon. Unfortunately there's just too much other stuff more pressing. So, for anybody waiting for a working solution this calendar year, don't hold your breath ;).

I'm still a bit reluctant to pull the trigger on a MADI interface for obvious reasons, but just looking at the options: is there anything else besides the SSL MadiXtreme and the RME HDSPe MADI?
 
What would really set this project off is a diy pcie madi interface . We need more software guys in here. people spend months developing hardware stuff, but with pirating being what it is, nobody wants to spend much time on software that's just going to be stolen unless is made proprietary to a piece of hardware/firmware.
 
I don't think this is bound to happen. Then we're back to programming a driver and might as well go the LAN way, which has the advantage of already available hardware. Also, designing a PCI(e) card isn't the most trivial task in the first place. That's why I was looking at MADI, because it eliminates these two things I can't (and don't want to) do myself.

Theft of software isn't really the problem here. Open source is doing pretty well, and that's what a DIY solution of this format should be in my opinion. There are just not the right people around here, or they don't speak up because they are busy elsewhere. That would be an enormous undertaking, which someone (possibly several people) has to start with both the expertise and the continued enthusiasm for the project. Software is in contrast to hardware a living matter that always needs maintenance and further development.
 
Sounds like FPGA solution is the best to meet everyone's needs for this project! I'm hearing PCIe, ethernet, adat, madi, i2s, spdif, usb, firewire... How about a 'modular' FPGA board where people can pick their own configuration. This is probably an insane amount of work to implement everything that everyone wants, but it could be somewhat modular and add stuff as you go. Just spitballing... it is PROGRAMMABLE logic, afterall. With the new ARM/FPGA solutions on the horizon, the opportunities are all the more exciting.

I know a few people on this thread have mentioned about working on FPGA stuff. Just thought I'd offer to help if anyone wants to look at this option. I do IP work for a particular FPGA vendor. I'm also familiar with the mentioned ADAT design and I've simulated it successfully (in the original VHDL and I converted it to verilog too, for those who prefer).
 
volker said:
I don't think this is bound to happen. Then we're back to programming a driver and might as well go the LAN way, which has the advantage of already available hardware. Also, designing a PCI(e) card isn't the most trivial task in the first place. That's why I was looking at MADI, because it eliminates these two things I can't (and don't want to) do myself.

I think PCIe using a Gennum part or perhaps one of the PLX bridges, and an FPGA for the special sauce, is not that difficult.

But driver development is a huge pain in the ass. Combine that with Microsoft's demand that a driver be blessed by the Mothership for use on Windows 7, and the barrier to entry gets pretty high.

-a
 
One good thing with this DIY MADI<->ADAT converter is that i don't need a MADI card for my notebook since i only need 24ch. I would use two of these converters, one for having a MADI output to drive a long cable from the stage to the DAW, then converting back to ADAT for using my RME Digiface (3x ADAT in). I could even split the ADAT outs for using my Mackie HDR as a backup medium. Nice and cheap.
Bypassing the ADAT portion would be a more elegant solution for having a MADI output, though.
signalflow said:
It looks like it has 8 adat ins and 8 adat outs giving 64i/o of conversion from adat to madi.  Still, wouldn't mind bypassing the adat portion all together and just having a madi.

-Casey
 
So is the Ethernet option on this project essentially dead now? That's the part I was most excited about. I was even willing to jump in and try to do the FPGA stuff (I have a Digilent board - not exactly a high-end setup but it works).

I'm interested in a 8 or 12 in and 8 out interface, since my Impact Twin's mains output section and monitor controller blew. I'm now monitoring via the spare outputs via the DAW. Not perfect, it gets the job done, but I've decided I want something more robust and versatile for the future.

I'm not terribly affluent (read: dead broke), so I was hoping to avoid spending $700 on an ADAT or AES card. Especially since I can buy a Delta 1010 for $600 and it would probably be good enough.

Any chance the Ethernet option can be brought back to life?
 
Well I think the Ethernet option is not completely dead but I think currently nobody has enough free time to develop it.
I still like the idea and I'm sure it can be done. Currently I don't have the time for it and I want to finish some stuff on my DIY desk before jumping into something new. I think that is the same situation like for many other members here, isn't it?

Raphael

P.S. Got an estimated delivery date for the prototype PCBs today: Wednesday next week. :)
 
I've already been doing a bit of research. One of the obvious problems is that I have yet to find an FPGA that can run faster than 400MHz or so, and that's not even taking propagation delays into account, so directly writing to a 1GBit line is out. I did find some shift registers and muxes that can operate at those speeds, so the obvious solution is for the FPGA to output data in parallel to that kind of device.

I'm still an EE student, so I'm sure I already look like a complete idiot to the other FPGA people around.

I'll try to find the hardware spec and timing information for the 1000BaseT spec and go from there.
 
Okay, I've been thinking about this some more.

Based upon what I remember from my sysadmin days and what I'm gathering from earlier in this thread, the hardware part of Ethernet is little more than a very fast serial port, right? Which means that we'd just be bit-banging the output and then reading it in at the input. The cables also have separate twisted pairs for transmitting and receiving, so I'm guessing it's probably asynchronous as well.

Since the packetizing we're used to with normal networking is not happening at this level, we seem to have two options: 1) use an existing audio protocol, of which I gather there are several, and 2) design our own audio protocol, which I honestly don't think would be as hard as it sounds. Then again, I said that about designing the text display mode for the teleprompter that was my final project in digital design class. It did work eventually, though.

Please hit me with any thoughts and corrections.
 
dmlandrum said:
I've already been doing a bit of research. One of the obvious problems is that I have yet to find an FPGA that can run faster than 400MHz or so, and that's not even taking propagation delays into account, so directly writing to a 1GBit line is out. I did find some shift registers and muxes that can operate at those speeds, so the obvious solution is for the FPGA to output data in parallel to that kind of device.

The SERDES in the IOB of some FPGA families are quite capable of serializing at Gbit rates. Look at Xilinx Virtex-4, V-5, V-6, Spartan 6.

The FPGA has a special clock multiplying circuit that can create a serializer clock at the required high frequencies; it's only for the I/O blocks and isn't distributed throughout the FPGA on standard clock-routing resources. It's a multiple of a word-rate clock, so you load the serializer on the slower clock and the hardware serializes the word and shifts it out.

That's the gist of it, anyways; the devil is necessarily in the details.

-a
 
Andy Peters said:
The FPGA has a special clock multiplying circuit that can create a serializer clock at the required high frequencies; it's only for the I/O blocks and isn't distributed throughout the FPGA on standard clock-routing resources. It's a multiple of a word-rate clock, so you load the serializer on the slower clock and the hardware serializes the word and shifts it out.

So I'd still be parallelizing the processing, but could shift to a gigabit serializer without any external hardware. That makes things a little easier.

Sadly, all I have to develop on is my Nexys2 board. I was quite serious when I said I'm dead broke. I'm still trying to find a way to finish my final year of uni.
 
You know, I wonder if the FPGA is the right approach here.

I just found some standalone 10/100/1000BaseT Ethernet controllers on Mouser for $5-$7 apiece. Someone mentioned earlier the idea of using a microcontroller (ARM is probably the singular choice here) combined with an Ethernet controller, and I can't help but think that that really might be the way to do it. I'd be more confident with embedded than FPGAs for something like this.

To me, FPGAs are best for 1) niche designs that can't justify mask costs and 2) lower-level designs that benefit from being highly customized, and 3) where field programmability is a must. (When I say "lower level", I'm referring to complexity, for lack of a better word.) None of that really fits here.

I'm sure other people have very differing opinions, but those are mine. I'm more than happy to have my mind changed, but I just think ARM (or other suitable choice) plus Ethernet chip would be easier and faster to pull off.
 
guitarguy12387 said:
There's lots of ethernet IP out there... why would you want to code your own? No sense reinventing the wheel. Especially for the hard stuff!

Well... I found this on OpenCores: http://opencores.org/project,ethernet_tri_mode

It would well fit into the Spartan 3E on my dev board (I paid extra to get the Nexus2 with the 1200 chip), and even has its own support forum. I'd really need to dive in and see what it's doing. I'm also still digesting what Andy said about newer FPGAs and their serializing capabilities.
 
Not just programming the ethernet chip in the breakout box, but you'd have to program custom ASIO (or something) drivers for computer OS to understand the audio box? For this reason, I still believe that the Audinate Dante is the best option for DIYer to dream of ethernet audio interface ;) Still, I don't know if even the dante is yet ok for DIY (high cost)... here's the card you'd need, no programming... http://www.audinate.com/index.php?option=com_content&view=article&id=276
 
Well, one fellow much earlier in this thread had a rudimentary driver already working, but he kinda dropped out of the whole thing, if I read it right. That's largely why I was asking if the Ethernet option was dead. I was kinda hoping I could rekindle that side of the project as well.

The fact of the matter is, I'll probably end up buying a Delta 1010. I am NOT going to spend $700 on a card with no converters which I will then have to DIY.

(But really, M-Audio? You're still charging $600 for a 15-year-old design? Sheesh.)
 
dmlandrum said:
Well, one fellow much earlier in this thread had a rudimentary driver already working, but he kinda dropped out of the whole thing, if I read it right. That's largely why I was asking if the Ethernet option was dead. I was kinda hoping I could rekindle that side of the project as well.

The fact of the matter is, I'll probably end up buying a Delta 1010. I am NOT going to spend $700 on a card with no converters which I will then have to DIY.

(But really, M-Audio? You're still charging $600 for a 15-year-old design? Sheesh.)

Sorry, forgot about the driver :) Did you get it working between two computers alright?
 

Latest posts

Back
Top