Marzipan wrote:Yeah, I'm wondering if this has not been done because it's not technically possible, or just the software doesn't exist yet... It seems the VE Pro "nearly" does this, but obviously the main intention is for streaming the VI's, so I guess they've got no interest in implementing it...
One of the problems is that Ethernet is a shared access system, and unlike AES/EBU which just carries audio, Ethernet will have background layer-2 spanning-tree discovery packets, ARP, Universal Plug-and-Play discovery packets, possibly Internet traffic, etc... This traffic can mess up real-time audio transmission timing. In Audio, not receiving audio when you expect to due to jitter or packet loss can give you clicks and pops.
An AES/EBU frame is dedicated to moving audio blocks. Unlike Ethernet, AES/EBU isn't a multi-access medium, doesn't have IP packet header overhead or Layer-2 ethernet chatter. additional overhead on an Ethernet network, and even more if you choose to communicate over IP.
Further, remember that the operating systems we use are not 'Real Time' operating systems. There ARE real-time operating systems, which are optimized for real-time tasks like signal processing. Windows and OS X and Linux (without real-time extensions) are not real-time. What these operating systems do is to 'try their best' and keep audio flowing without glitches, but in practice, there is OS induced jitter, ethernet jitter, ethernet switch jitter, etc... If you want to see proof of network jitter, just ping your gateway:
Wizard-99:~ doktorfuture$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.182 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.150 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.166 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.158 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.159 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.161 ms
^C
--- 192.168.0.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
The average jitter here is AT LEAST +/-0.01 ms, or at least +/-10,000 nanoseconds of packet jitter. Neither Ethernet nor your PC was designed for real-time communications! For the most part we just rely on lots of CPU processing power and 'buffers' to make the latency tolerable. In fact, you can't even guarantee the ORDER that packets will be arrive at the receiving end. Ethernet is better for moving large data frames and efficiently using the available bandwidth.
By contrast, an AES/EBU audio signal is a dedicated single access (i.e. one transmitter) encoding and transmission system that sends real-time digital data with embedded clocking. It can easily give you +-20 nanoseconds of jitter (orders of magnitude smaller) since it is 100% dedicated to transmitting audio in REAL-TIME. Further, D/A dual PLL clock recovery circuits can usually get you within +/- 1 ns (or better) when reconstructing the clock signal. Question: What clock does ethernet streamed audio synchronize to? Answer: NOT OBVIOUS AT ALL!
What I'm trying to illustrate is streaming REAL-TIME audio over Ethernet is tough!
BUT, if you drop the 'REAL-TIME' requirement, AND you are using a transmission system with large-enough buffers, you can stream data back and forth between a PC a MAC, and a Linux box reliably, albiet with more latency. If you're using a DAW, things like that VE Pro make sense because the DAW will do latency compensation. Still, these systems aren't perfect (check their forums for lots of people with clicks/pops and drop-out problems). The VE Pro system is, in my opinion, still has the usual problems as it convergest towards REAL TIME use.
Another example of latency in non-real time network audio transmission is when you stream audio from one device to another. In this non-real time case the system which plays the audio has a big buffer that it fills 'as fast as it can'. You see this kind of thing when you play a youtube video, or an mp3. The data comes in all 'lurchy'. Only when there's enough data in the buffer can you safely play without going into a buffer over-run.
So everyone should be clear that 'real time networked audio' is a special case of 'networked audio'.
Luckily we are getting there. You can use JACK
http://jackaudio.org/applications to get you started. It's open source software, and doesn't have that 'commercial polish'. But I've gotten it to work whenever I put time into it.
JACK is a cross-platform audio server. That 'wormhole' program that was mentioned uses it I think.
JACK on PC's can be linked to ASIO. (JackRouter)
JACK can be linked to CORE AUDIO. (
http://www.jackosx.com/)
JACK can be linked to various Linux sound systems.
JACK applications are starting to appear to let you stream REAL-TIME data over IP networks:
http://netjack.sourceforge.net/
There are JACK applications which even let you 'jam' with others over the Internet:
http://sourceforge.net/apps/mediawiki/l ... =Main_Page
I wish there was a general solution to routing real-time audio over Ethernet (or some network) problem. The last serious attempt was Yamaha's MLAN. It was a sort of 'cross-platform' Scope. It looked GREAT but suffered from some implementation and adoption issues.
For now I will continue to run hundreds of feet of physical AES/EBU cables around because I can't afford to MADI.