Ethernet to digital audio conversion

[jeremy]

will the data be sent via a switch/router?

[gmichael225]

will the data be sent via a switch/router?

Switch, yes.
Router, no.

[jeremy]

Ok so then unfortunately, the chances of getting out-of-order packets are non-zero. Does it matter if you play some samples out of order? I imagine it would be quite rare. If no, then I think FPGA is probably the easiest option. If yes, you will probably need some sort of IP stack to perform buffering and reordering (but I am not familiar with ADAT so I'm not 100% sure) so I'd say that SoC would be the best option.

For FPGA, get a digilent dev board with a built in programmer and the ethernet PHY already done for you. It will make life a lot easier. They also have a high speed connector on some if you feel like that is what you need (what frequency does the ADAT bus run at ?)

[Rigby]

Its not TCP, geez.  Read.

[jeremy]

Its not TCP, geez.  Read.

Doesn't mean there is no ordering information in the packets. IP layer is not restricted to TCP or UDP.

[Rigby]

UDP isn't ordered, meaning that the IP protocol is not ordered.  But we're a layer below that at layer 2 with this.

No ordering, no guaranteed delivery.

[jeremy]

"UDP" is not written anywhere in this thread? So while the protocol described could be UDP, it could be something else as well.

[edavid]

Read the first post... the ProCo protocol is not IP based.  It's not documented either, but I guess the OP has figured it out.  It doesn't appear to have any sequencing.

However, why would a simple switch decide to reorder Ethernet packets?  It seems implausible.  And, it must not be too much of a problem in real life, or the ProCo products wouldn't work.

[Rigby]

Also, the audio stream contains no ordering information.  Now that I read your post.

[Rigby]

Switches can reorder packets, but on simple networks is it very unusual.  On complicated or misconfigured networks switches can really get in the way.

A good switch that is properly configured won't, though. 

[gmichael225]

Unfortunately there's no ordering in the Ethernet protocol AFAIK.
I've done a short writeup of the protocol at blog.gmichael225.com/post/48khz-adventures.

For FPGA, get a digilent dev board with a built in programmer and the ethernet PHY already done for you. It will make life a lot easier. They also have a high speed connector on some if you feel like that is what you need (what frequency does the ADAT bus run at ?)

I do already have a Xlinix Spartan-3AN dev kit which may be worth playing with, but I haven't got very far with it - a lot to learn there.
ADAT runs at ~13Mbps, not sure how best to answer your frequency question.

Switches can reorder packets, but on simple networks is it very unusual.

I haven't had any issues with this thus far. We run switches with a lot of overhead for this sort of stuff so queues don't get much chance to fill up. I mainly run ProCurves, VLAN'd, with the ProCo's on the highest QoS priority.

[IanB]

Doesn't mean there is no ordering information in the packets. IP layer is not restricted to TCP or UDP.

To clear up a bit of confusion about network protocols:

TCP/IP is TCP over IP, meaning that the TCP protocol (at layer 4 in the OSI model) sits on top of the IP protocol (layer 3).

Similarly, UDP/IP is UDP over IP, meaning that UDP (layer 4) sits on top of IP (layer 3).

From this it can be inferred that if UDP is not ordered, then IP is not ordered either--otherwise UDP would inherit packet ordering from IP.

This is all irrelevant to the subject of the OP, however, since the OP is dealing with layer 2 (data link), which sits under IP (layer 3).

As far as ordering is concerned, I believe the Red Book standard for audio CDs presents a real time data stream from the disk without a guarantee of reliability. It is up to the decoder to apply error correction and fill in any gaps in the data stream to provide smooth playback. So this doesn't sound too far removed from the problems of a live data stream over Ethernet.

[Richard Crowley]

This discussion has become horribly confused and nearly useless because of the unfortunate selection of title by the OP.
"Ethernet" means an almost infinite number of different things to different people.
Even though the OP stated explicitly that the ProCo protocol does not even use the second layer ("IP") of the "ethernet stack", people have flown off discussing the (de-)merits of sending real-time data over a routed network topology.

Alas, if the OP had simply and accurately stated that he was trying to design a ProCo to ADAT format converter, this discussion might have turned out to be useful.

[gmichael225]

This discussion has become horribly confused and nearly useless because of the unfortunate selection of title by the OP.

Apologies for that. I was trying to use the most correct terminology, but should've given more consideration to common usage of the terms. I figured "ProCo" and "ADAT" might cause the post to go unnoticed by people unfamiliar with the terms who could otherwise usefully contribute.

Anyway, let's not turn this into a discussion of how to best title threads...
Thanks for the advice! I'll bear it in mind for future posts.

[magetoo]

However, why would a simple switch decide to reorder Ethernet packets?  It seems implausible.

Yeah, reordering would seem to imply that the switch can buffer Ethernet frames and make decisions on which ones to send and which ones to hold back, which seems unlikely for most simple switches.

The obvious thing would be to have a simple FIFO, drop frames when it gets full, and let higher layers sort out the mess.  (No idea what enterprise gear gets up to.)

[gmichael225]

Let's not worry about the merits / limitations of the existing protocol.

The question is: someone is throwing Ethernet (not TCP, not UDP, not IP, Ethernet) packets at you with bytes in them. You need to throw away ones with an incorrect header, rearrange the remaining bits very slightly and then throw them out a GPIO with as low latency as possible. What hardware would you use?

[Richard Crowley]

To answer your original question, creating an ultra-low-latency (for real-time live systems) converter is a rather difficult task.
A RasPi or BeagleBone Black software solution may actually not be up to the task.
It might take some very significant development for FPGA or high-end microcontroller like Xmos, et.al.

I have at times considered such projects (like ADAT to USB input device for multi-track recording to computer).
But starting from scratch with little experience on high-end microcontroller solutions, this is an almost impossible project.
It might be slightly easier if you didn't require low-latency. But that makes it a very tough solution.

[gmichael225]

...ultra-low-latency...

To put some numbers on it, the ProCo system running analog->Ethernet->analog is spec'd at 0.630 ms delay end-to-end. I'd be aiming for something similar.

[miguelvp]

Get this:

http://parts.arrow.com/item/detail/arrow-development-tools/bemicromax10

and this:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,401,1003&Prod=PMOD-NIC100

Learn Verilog/VHDL/QuartusII

However might not be easy to do, I'm pretty sure they don't have sample VHDL/Verilog code.

However this dev kit:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830
And this board:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=71&No=355&PartNo=1
Will have examples but using a soft core NIOS II so not sure how that will pan out, but hardware wise it should be able to do anything, but expensive. At least you can download the sample code and documentation for that board and try to apply it to the first option. But the MAX 10 (first option) is very limited in Logic Elements so it barely will be able to fit a NIOSII soft core.

Also a 48MHz Pioneer kit with an ethernet shield might be worth exploring.
http://www.element14.com/community/thread/24880/l/psoc-4-pioneer-kit-community-project031-ethernet-shield
But I don't know how much access that will have to the Ethernet frames. Also I notice the ethernet shield is no longer manufactured

[Jeroen3]

Question is, do you really need HDL to solve the problem. Any software enabled chip with ethernet support will have a MAC driver with DMA.
Every received package will be written into memory for the network stack to process, by hardware. You don't have a stack, huge time saver. Only thing left is the CRC, run it with the dma, and you're on to re-assembling the bytes for your adat signal. Since you just drop faulty frames.
Then you'd need NRZI encoding output. This can be done using SPI and a few logic gates. Another piece of integrated hdl for you. And also this can be outsourced to the DMA.
You only need the processor core for reassembling the bits, do this with some well smart assembler routine and you'll be done in no time.

Why create a chip like this yourself if you can already buy it?

[gmichael225]

Question is, do you really need HDL to solve the problem. Any software enabled chip with ethernet support will have a MAC driver with DMA.
Every received package will be written into memory for the network stack to process, by hardware. You don't have a stack, huge time saver. Only thing left is the CRC, run it with the dma, and you're on to re-assembling the bytes for your adat signal. Since you just drop faulty frames.
Then you'd need NRZI encoding output. This can be done using SPI and a few logic gates. Another piece of integrated hdl for you. And also this can be outsourced to the DMA.
You only need the processor core for reassembling the bits, do this with some well smart assembler routine and you'll be done in no time.

Why create a chip like this yourself if you can already buy it?

This sounds like a promising approach. Any recommendations for such a chip / any resources for development along these lines?

[Jeroen3]

Try asking that question on the forum of an embedded rtos / network stack. More luck of people who written low level code on various platforms.
I only know a bit about the STM32F4 family, but the peripheral drivers make you lazy.

[magetoo]

On paper, NXPs LPC43xx (Cortex-M4 core) chips look like they could do it.  There's "serial GPIO" (shift registers on steroids that supposedly can do any serial protocol), some sort of dedicated timer/state-machine hardware, and an event system that, IIRC, can trigger on anything you could possibly want and then initiate DMA transfers between peripherals without going through the CPU core.  Plus I2S and a ton of other interfaces, if that is any help.

But trying to understand the documentation well enough to actually use all this is another matter.  Perhaps it has improved recently, but I couldn't even understand where to begin. (Then again, I was just reading casually.)

Might be an option, or I might be completely off.

[Jeroen3]

Earlier I already suggested that chip, since it has SGPIO. Of which you can create A LOT of SPI outputs. Especially if they are synchronously clocked.
I almost forgot it has that state-machine thingy. But that will require some exploring before you can use it.
NXP usually puts in "simple" peripherals, I do not recall the DMA being highly advanced. In contrast to STM32F4's.

The most significant bonus feature is the option to have TWO 200 MHz Cortex M0 co-processors. (see iPhone's sensor processor)
And it has lots of RAM on multiple banks making bus-waits a non-issue. Since you must run from ram to have best performance, I suggest you look for chips that serve multiple banks of ram that can be used simultaneously.

But then again, I do not know anything of chips with more than a Cortex M4. Maybe the chips used in an Raspberry pi's are even more powerful when programmed bare-metal.

[magetoo]

I thought someone had mentioned it, apparently I failed at searching.

Only one M0 coprocessor though.  Or is there a new one with two?