-
#25 Reply
Posted by
jeremy
on 13 Dec, 2014 15:59
-
will the data be sent via a switch/router?
-
-
will the data be sent via a switch/router?
Switch, yes.
Router, no.
-
#27 Reply
Posted by
jeremy
on 13 Dec, 2014 16:54
-
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 ?)
-
#28 Reply
Posted by
Rigby
on 13 Dec, 2014 16:58
-
Its not TCP, geez. Read.
-
#29 Reply
Posted by
jeremy
on 13 Dec, 2014 17:00
-
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.
-
#30 Reply
Posted by
Rigby
on 13 Dec, 2014 17:24
-
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.
-
#31 Reply
Posted by
jeremy
on 13 Dec, 2014 17:26
-
"UDP" is not written anywhere in this thread? So while the protocol described could be UDP, it could be something else as well.
-
#32 Reply
Posted by
edavid
on 13 Dec, 2014 17:44
-
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.
-
#33 Reply
Posted by
Rigby
on 13 Dec, 2014 17:47
-
Also, the audio stream contains no ordering information. Now that I read your post.
-
#34 Reply
Posted by
Rigby
on 13 Dec, 2014 18:15
-
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.
-
-
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.
-
#36 Reply
Posted by
IanB
on 13 Dec, 2014 19:13
-
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.
-
-
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.
-
-
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.
-
#39 Reply
Posted by
magetoo
on 13 Dec, 2014 19:32
-
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.)
-
-
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?
-
-
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.
-
-
...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.
-
#43 Reply
Posted by
miguelvp
on 13 Dec, 2014 20:07
-
-
#44 Reply
Posted by
Jeroen3
on 13 Dec, 2014 20:25
-
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?
-
-
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?
-
#46 Reply
Posted by
Jeroen3
on 13 Dec, 2014 23:59
-
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.
-
#47 Reply
Posted by
magetoo
on 14 Dec, 2014 00:16
-
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.
-
#48 Reply
Posted by
Jeroen3
on 14 Dec, 2014 00:42
-
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.
-
#49 Reply
Posted by
magetoo
on 14 Dec, 2014 00:50
-
I thought someone had mentioned it, apparently I failed at searching.
Only one M0 coprocessor though. Or is there a new one with two?