EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: gmichael225 on December 10, 2014, 11:20:40 pm
-
Apologies if I'm posting this in the wrong place / format!
In the spirit of don't turn it on, take it apart don't buy it if you can build it for less, I'm trying to build a converter circuit for a live sound application.
The source is 24 raw Ethernet streams (of 24-bit 48kHz PCM) (no IP layer, it's just Ethernet data bytes sent to a broadcast MAC address), and I'm hoping to output three 8-channel ADAT Lightpipe lines. From memory (it's been a little while since I looked at it), they're integer-compatible with some slightly different bit arrangements.
I'm trying to decide what the best approach is to building this device - I've created a software implementation that will play the Ethernet stream to local speakers, but I really need latency as low as possible as it's for live sound. The software version ended up a couple seconds behind over time (but then it was a bit of a kludge - "cut" and "grep" really shouldn't be in an audio pipeline).
At the moment I'm tossing up between doing something software-based (with a less kludgey implementation) on something like a RasPi, or something FPGA-based. (Or are both overkill?)
Any and all comments welcome!
-
This can be a difficult topic but here are some things to think about:
Ethernet is not well suited for low latency, real time audio for sound performance/reproduction. You got a good start by staying at layer 2 but every attempt at using ethernet for sound reproduction in a live setting hasn't been optimal for this reason. There is no good way to encode the audio clock in the signal. Differences in playback rate are a pain to deal with and you cannot add buffer to solve it. Moving to a hardware solution such as an FPGA won't fundamental solve problem if you use ethernet.
Checkout Gibson "Magic". It was ultimately a market failure.
If you are trying to send gobs of audio channels over CAT6, consider some other transport. Why not just use the ADAT protocol over copper?
Also, There are other implementations of real time digital audio transport such as AES10.
http://en.wikipedia.org/wiki/MADI (http://en.wikipedia.org/wiki/MADI)
Not to say you can't do it, it is just that you have to match up the transport protocol to the data type. Ethernet simply cannot be low latency and there is no good way of transmitting data synchronously. Just for reference I define low latency as 1 to 2 audio samples for real time. The best I have seen is about 800uS to 1mS over Ethernet. The problem isn't the 1mS. The problem is that there are many other things in the chain that add latency!
Just some food for thought.
-
I think this is a bad idea. Ethernet is not fundamentally robust, and it does not care one bit if frames are delivered late or not at all. How will you deal with dropped Ethernet frames? You also can't guarantee the receive order or latency of frames. If you se TCP, then you have built-in robustness, but you will need to add buffering give the protocol time to deal with retransmission of late/dropped packets. Using raw Ethernet gains you basically nothing since you just shift that burden onto your software, instead of the TCP stack. You still need to buffer for some time to reassemble out-of-order frames and to handle dropped frames, both of which will happen.
If you just need to be able to send audio over Ethernet cable. then forget about Ethernet and put some other protocol over the cable. You have four high bandwidth differential pairs to utilize. If it is an existing cable that you can't just take over, then maybe you can live with 100Base-TX instead of gigabit, leaving two pair free to use. I like the idea of ADAT or even some other TDM protocol over the twisted pair. TI and others make ICs that can accept multiple serial streams, mux them up into a single higher rate TDM stream, and demux them at the other end into the separate streams again.
-
Thanks for your response!
Sorry, I should clarify - the source already exists in the form of three ProCo Momentum mi8's. (There are other systems out there, but this is what I have.) I'm not inventing the protocol - I need to decode & ADATify it...
-
For clarification:
I'm trying to build the pink box. The other components already exist and have existing, defined formats. I'm just trying to work out what the best hardware approach will be to building it.
(http://i.imgur.com/wo7ZqWi.png)
-
are you going to make it open source? and destroy every known cobranet, yamaha-net, etc whatever else xyznets in the known audio-verse lol ... please say yes ... it will make many small-mid sized PA outfit and installers very happy
I keep hearing that AVB will do that. At the moment things seem to be heading in the direction of Cobra + Dante.
-
The ethernet support on Raspberry Pi isn't native right? 25 Mbps might be pushing it, there's cheap SBCs with gigabit ethernet as well.
You will have to dick around with preempt_rt for linux to get <1 ms latency, still I'd definitely use a SBC ... just throwing a wildly overpowered CPU and a couple million LOC generic OS at it might not be elegant, but it's definitely easier than the alternative.
-
...cheap SBCs with gigabit ethernet ... preempt_rt...
Cheers, I'll investigate both! :)
-
The question then becomes - how to generate 3x 12.288 Mbit/s bitstreams from an SBC...
-
You guys seem to be confusing "Ethernet" with "TCP/IP" in a lot of ways. Some of the things said here are just plain wrong.
He's using "Ethernet" as a layer 2 transport only, there's not any guaranteed delivery to slow things down, there's not going to be much in the way of smarts between endpoints to interfere. You can definitely be within 1 audio sample and synchronous. Anyone familiar with VoIP will eviscerate many of the stuff said in this thread.
Besides, you're all attacking something that is already built; he has an audio over ethernet device and wants to get the audio out. So drop all of the "this shouldn't be done over ethernet" stances - it's well beyond that point already.
Hackaday.com (I think) recently featured someone doing what the thread starter is looking to do: tap into the digital audio stream that goes over CAT5 rather than analog audio cables. Yeah, here it is. (http://hackaday.com/2014/11/12/protocol-snooping-digital-audio/)
-
Hackaday.com (I think) recently featured someone doing what the thread starter is looking to do: tap into the digital audio stream that goes over CAT5 rather than analog audio cables. Yeah, here it is. (http://hackaday.com/2014/11/12/protocol-snooping-digital-audio/)
That's me. :P
I'm now trying to build a show-ready protocol converter based on what I learnt in that exercise.
-
I would employ the use of an FPGA if I were you. You can definitely keep latency pretty damned low if you can use an FPGA.
-
That was my thinking, but I'm still just getting started with FPGA's really. Always keen to learn new things though!
-
Beaglebone Black might be worth a look. I think it is only 100M ethernet, but it has on chip Real Time Units (RTU) which you can delegate tasks to. You could also use a real-time operating system/bare metal on a Cortex A series board.
Is this a one-off ?
-
I remember that there were some people posting on comp.arch.fpga about this sort of thing - using raw Ethernet to transfer data between an FPGA-based system and a workstation with low latency.
It might be useful to take a look there, probably something can be learned about both ends of the pipe (i.e. both the FPGA implementation and on the desktop). I think there is a searchable archive at fpgarelated.com if you aren't already set up to do newsgroups.
-
Beaglebone Black might be worth a look. I think it is only 100M ethernet, but it has on chip Real Time Units (RTU) which you can delegate tasks to. You could also use a real-time operating system/bare metal on a Cortex A series board.
I'll look into that. Bearing in mind though that it does need the ADAT out, which could be tricky on an SBC.
Is this a one-off ?
Yes, but I do want to build it to a high standard for production use.
mmm im definately getting too old for these and out of touch (too deep in the mountain) ... what is ... "AVB" ?
AVB: http://en.wikipedia.org/wiki/Audio_Video_Bridging (http://en.wikipedia.org/wiki/Audio_Video_Bridging)
and sorry i have to noob this ... what is "big-endian integers" ?
Endianness: http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html (http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html)
my guess is with some luck in hooking up with techs from rental companies, you could borrow their AD/DA gear for a few days and you could prolly figure out what all the protocols are. very likely they are all the same (i guess) ... because when it comes to specifications, all the cables specified are always in the same ballpark
I've borrowed some equipment, both the Ethernet transmit and the ADAT Lightpipe receive gear, and have details on the protocols for both. I'm just struggling to pick between SBC/SoC and FPGA, given the device has to have both Ethernet and high-speed (~13Mbit/s) GPIO.
It might be useful to take a look there, probably something can be learned about both ends of the pipe (i.e. both the FPGA implementation and on the desktop). I think there is a searchable archive at fpgarelated.com if you aren't already set up to do newsgroups.
Cool, I'll check that out! Cheers :)
-
Beaglebone Black might be worth a look. I think it is only 100M ethernet, but it has on chip Real Time Units (RTU) which you can delegate tasks to. You could also use a real-time operating system/bare metal on a Cortex A series board.
I'll look into that. Bearing in mind though that it does need the ADAT out, which could be tricky on an SBC.
Take a look at this: http://elinux.org/BeagleBone_PRU_Notes (http://elinux.org/BeagleBone_PRU_Notes)
With assembly, I believe you can get a GPIO to toggle at 200MHz.
-
With assembly, I believe you can get a GPIO to toggle at 200MHz.
No way 200 MHz is coming out of an non-clockout gpio.
You will need a SPI peripheral to do the NRZI encoding of the ADAT line. 3 of them.
Its a long time ago and don't remember the hard limits of the chip, but what about a LPC43xx's SGPIO and some additional gates for the NRZI encoding?
I used that chip to control multiple ( 8 ) RGB LED driver IC's really fast.
-
With assembly, I believe you can get a GPIO to toggle at 200MHz.
No way 200 MHz is coming out of an non-clockout gpio.
please see
200Mhz in the comments here: http://hackaday.com/2013/12/07/speeding-up-beaglebone-black-gpio-a-thousand-times/ (http://hackaday.com/2013/12/07/speeding-up-beaglebone-black-gpio-a-thousand-times/)
100MHz: http://www.cubieforums.com/index.php?topic=2041.0 (http://www.cubieforums.com/index.php?topic=2041.0)
50MHz: http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 (http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2)
also http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf (http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf)
-
Looks like I might need to get a Beaglebone Black to play with! Even if it doesn't work out for this, I'm sure it'll come in handy somewhere.
-
They're amazing little machines; far more punch to a BBB than a Raspberry Pi.
-
The i.MX6 boards should be able to output at a fair clip as well using the DMA controller (basically an extra processor).
-
The ADAT protocol
is was typically implemented by using the Wavefront Semiconductor chips. It is just another particular serial format, not significantly different than any other serial protocol, but I'm not sure it is published so that you can "reverse-engineer" it. But if we had the definition, any digital circuit of sufficient speed and power should be able to generate it
http://www.wavefrontsemi.com/index.php?products (http://www.wavefrontsemi.com/index.php?products)
Unfortunately, as you can see, all the ADAT format chips are EOL and no longer available. Dunno how people are implementing ADAT now?
-
Dunno how people are implementing ADAT now?
Also interested, just curiosity, wavefront second hand are very overpriced, but in any case, extinct IC with manage a very simple protocol, obsolescence because the niche is addressed to better solutions (MADI/AVB) but I still enjoy my "old" RayDAT and want for many years to interconnect my adat gear.
Maybe looking into a new Behringer item as adat 8200, but I guess that use custom ic's paying Alesis royalties.
It is more likely that a recent Motu, with AVB that means new platform&dev.board, unveil a generic ic programmed to ADAT trans/decode.
About AVB.
I took a few months looking AVB solutions, I am interested in soft. development. Now some pro-solutions AVB (also have Adat) come from Motu.
But in terms of development, check Xmos platform, a good AVB platform.
#Richard -> Xmos had ADAT in their roadmap for some time, maybe they have it now.
-
Unfortunately, as you can see, all the ADAT format chips are EOL and no longer available. Dunno how people are implementing ADAT now?
There are FPGA implementations out there. https://ackspace.nl/wiki/ADAT_project (https://ackspace.nl/wiki/ADAT_project).
The problem for me is, with FPGA's I'm not so sure of the Ethernet side, and with SBC's I'm not so sure of the ADAT / latency side.
-
will the data be sent via a switch/router?
-
will the data be sent via a switch/router?
Switch, yes.
Router, no.
-
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 ?)
-
Its not TCP, geez. Read.
-
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.
-
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.
-
"UDP" is not written anywhere in this thread? So while the protocol described could be UDP, it could be something else as well.
-
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.
-
Also, the audio stream contains no ordering information. Now that I read your post.
-
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 (http://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.
-
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.
-
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.
-
Get this:
http://parts.arrow.com/item/detail/arrow-development-tools/bemicromax10 (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 (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 (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 (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 (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 :(
-
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?
-
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.
-
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.
-
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.
-
I thought someone had mentioned it, apparently I failed at searching.
Only one M0 coprocessor though. Or is there a new one with two?
-
I thought the one in the iPhone, the LPC18A1, had two. But they don't sell that part. Too bad.
But there are more rumors: http://www.lpcware.com/content/forum/triple-core-lpc437x (http://www.lpcware.com/content/forum/triple-core-lpc437x)
If you're planning on making a production version, ask them.