Audio over Ethernet is a technology that’s been collecting attention on-and-off for a while, but looks like it’s about to hit the mainstream. Part of me is stoked because pretty much everyone already has Ethernet cable lying around them but it’s a technology that is in no way ready for the greater open-source community.
Intel’s Open-AVB looks promising, but currently it only supports the Intel I210 Ethernet controller and I’m not confident in it enough to commit the time to port the existing code to any different chipsets.
Then there’s the proprietary solutions (ick).
Audinate’s Dante seems to be the big contender in this arena and Audinate offers you plug-and-play solutions, a more featured one in the form of a Spartan6-based add-on to your current implementation (no idea how much they cost). The article below claims that Dante doesn’t offer the timing-accuracy that Open-AVB possesses and that the accuracy isn’t even necessary unless network bandwidth has been exceeded. I’m taking that with a grain of salt, but if that is the case then why the proprietary hardware? Can’t I do that with the existing FPGA’s available bandwidth in my project?
So I think that it’s pretty clear that the disadvantage for Open-AVB is that it’s not finished, supports only specific chipsets, and must still be ported to all but a couple of them, plus you need expensive switching hardware. Advantages are that it’s free, open-sourced, and highly synchronised. Disadvantages for Dante is that it costs money (possibly a lot), is another embedded system on top of what you already have, and is closed-source. Advantages being potentially painless integration thus lower cost of development and you can use consumer network hardware.
The other fast(ish) option is to write a user-space application in the form of a JACK client, VST plugin, or similar program. I’ve written plenty of these network-audio-clients that were stable and offered low-latency over a consumer LAN network (the JACK server didn’t crash on my laptop waiting for samples so it was synchronized enough with my laptop’s audio card). However, this solution assumes there’s an audio interface that the JACK server is using for synchronisation in the first place (would have to create an interface that generates a clock) and totally breaks the expectations of systems looking for audio devices.
Anyone else thinking about this?
EDIT: My target use-case is for a few number of external audio devices connected to a computer or computers over 100/1000Mbps Ethernet LAN. I feel like current market solutions are a bit over-engineered (or aren’t platform agnostic), but I’m still not totally set… I think some formal, real-world tests and metric gathering is in order.