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.
Darren,

is it a solution for you to buy either a RME RayDAT or a Presonus Lightbridge and DIY the ADAT/Analog converter? Then you have more i/os then you need.

Raphael
 
Not at those prices, no. That's why I want the Ethernet option: the hardware is readily available and it's definitely fast enough. Of course, the downsides are needing custom hardware in the converter, and a driver for the computer side.

To be honest, I have little faith in my ability to pull this off. And even if I do, if the driver side doesn't get done, it's all for nothing anyway.

Now, back to the actual discussion at hand: FPGA, or micro with controller chip? I think I'm still leaning toward the latter.
 
dmlandrum said:
Now, back to the actual discussion at hand: FPGA, or micro with controller chip? I think I'm still leaning toward the latter.

Doing Ethernet requires a processor to handle the IP stack. Now, if you look at all of the examples of doing Ethernet on an FPGA, they all use a processor. In the Xilinx world, that's either a MicroBlaze soft core or one of the Virtex-4 or -5 parts with a hard PowerPC core.

Having been through the sheer hell of using the Xilinx EDK, and recognizing that the cores they provide are absolute crap, we (day job) no longer embed a processor in an FPGA. (Having said that, I just finished a camera that has an 8051 core in an Actel FPGA; long story ...) Since we need an FPGA to do the magic that we do, obviously it's there. But for processing, we use either a Silicon Labs 8051 or one of the Applied Micro PowerPC processors. And the bonus with those $20 PPC chips is that they have an onboard Tri-mode (including Gigabit) MAC that actually works. Plus you can use the free GNU toolchain to do your development.

None of the ARMs that we've looked at have Gigabit Ethernet, but if 100Base-T suffices, they're an option. Silicon Labs just introduced an ARM Cortex device that looks mighty mighty interesting (and we're going to use them in favor of the 8051s moving forward for most things) and they have a nifty add-on 100 Mbit Ethernet controller that works well.

So now you're faced with a serious question: how do you get your audio data to and from the processor? None of the PPC or ARM devices I've looked at has an I2C port for converters (forget about ADAT) but perhaps they have a general-purpose programmable serial port that can be configured to look like I2S? Otherwise, you're talking about a small FPGA or CPLD to do the I2S interface, which perhaps can be connected to a DMA interface on the microprocessor.

Notice that I have not said one word about firmware that runs on the microprocessor. As it says in the textbook, "That is an exercise left to the reader."

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

The price is based on the bill-of-materials cost, with a multiplier to accommodate the cost of keeping the lights on and the water running in the office and all of the other overhead involved in actually running a business.

I wouldn't expect the price to drop unless the cost of parts dropped.

-a
 
dmlandrum said:
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.

Please hit me with any thoughts and corrections.

The hardware is borderline trivial.

The software required to do whatever it is that Ethernet does is not.

-a
 
dmlandrum said:
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.

A better way to think of an FPGA design is like this: "I need to fit what used to be a rack full of TTL boards into a board the size of a credit card."

FPGAs are a design implementation mechanism. FPGA design uses the same rules as when we used to do the big VME boards full of MSI and LSI gates. It's still digital design. It's just that we can do more, and do it faster. So if that's "highly customized," so be it, but in the end, aren't most products customized?

And it's not that FPGA designs are "niche." It's just that unless you're making 100,000 of something, there's no way to justify mask costs and such. Everything I've read says that the market for structured ASICs and the "semi-custom" devices has dried up as FPGAs have gotten cheaper. So basically, if you're not a fabless semiconductor house, the pure-play fabs won't even take your phone calls.

Field programmability is actually pretty low on the list of end-user requirements.

-a
 
Do we really need to implement a full TCP/IP stack? Or can we just treat the Ethernet controller as a super-fast serial port?

Those APM chips look pretty good. Are they all BGA packages? A quick glance doesn't really say.

If you don't think this is worth the effort, then I'll stop and go back to my other projects.
 
dmlandrum said:
Do we really need to implement a full TCP/IP stack? Or can we just treat the Ethernet controller as a super-fast serial port?

I don't know what the protocol you're trying to implement involves. Things like the Aviom systems use the MAC and PHY but not the protocol, so it works for point-to-point links and in Aviom's case, specialized distribution hubs. But if you want to take advantage of off-the-shelf switches and routing kit, you have to implement a TCP/IP stack.

Those APM chips look pretty good. Are they all BGA packages? A quick glance doesn't really say.

I haven't looked; we use the BGA and to be honest, whether a part is available only in a leaded package hasn't been an issue in ages. I realize that BGA can be a show-stopper for the hobbyist trying to build a unit at home.

-a
 
I'm going to bow out of this for now. I won't be able to accomplish anything until I have some sort of income, anyway. So I'm going to stop talking about until I can actually make something.
 
Juhu, the prototype PCBs have arrived and I'm now going to make something with them.
Therefore, I'll open an extra thread in the Lab section. For those you have been asking to see a real thing it might be interesting to follow the build process.  8)
 
You do not need to implement the full tcp/ip stack to use normal network switches. A network switch live's at the second layer of osi model and only care about the MAC address and care nothing at the protocal layer. That being said most modern managed switches can route at layer 3 but you do not have to use that feature. And using Router for this would be darn right silly.

Eric
 
jollydowsen said:
dmlandrum said:
I'm going to bow out of this for now. I won't be able to accomplish anything until I have some sort of income, anyway. So I'm going to stop talking about until I can actually make something.

well said dmlandrum . until and unless you actually implement your project all talks have no significance.

I'm not sure I'm understanding your statement correctly. Are we to stop discussing circuits or audio solutions if we have no intent and/or means to pursue them to full realization?
 
gemini86 said:
jollydowsen said:
well said dmlandrum . until and unless you actually implement your project all talks have no significance.

I'm not sure I'm understanding your statement correctly. Are we to stop discussing circuits or audio solutions if we have no intent and/or means to pursue them to full realization?

Yeah, that's kinda what I was wondering. The only reason I was posting and asking questions was to see if it would be worth the time and money to pursue this project. I never really got my answer, and that's why I decided to bow out. Nevertheless, I finally have a new job that can pay for these projects, so I will be pursuing this sometime in the near future.
 
Has anyone built and tested these PCBs & circuits?

In every case, the performance of ADCs & DACs is dependent NOT on the Golden Pinnae bits or even the chipset.  It is critically down to the PCB layout, connections & housing.  OK, the surrounding circuitry too but the former are AT LEAST as important.

Here's a DAC example by a guru.  http://nwavguy.blogspot.com.au/2012/04/odac-released.html  Even he took 4 PCB iterations to approach the datasheet spec.

IMHO, an ADC is more difficult to get right.
 
ricardo said:
Has anyone built and tested these PCBs & circuits?

In every case, the performance of ADCs & DACs is dependent NOT on the Golden Pinnae bits or even the chipset.  It is critically down to the PCB layout, connections & housing.  OK, the surrounding circuitry too but the former are AT LEAST as important.

Here's a DAC example by a guru.  http://nwavguy.blogspot.com.au/2012/04/odac-released.html  Even he took 4 PCB iterations to approach the datasheet spec.

IMHO, an ADC is more difficult to get right.

While perhaps apples and pears, I remember back in the day when A/Ds were made with a good DAC and a SAR (successive approximations register).  Basically you determined the bits one at a time starting with the MSB and compared the DAC output to the input. Layout of the very analog comparator and PCB very much mattered and I've seen 16 Bit products there weren't really. because of the layout...  :eek:

JR.
 

Latest posts

Back
Top