Why not use Ethernet for Audio?

[Me2]

After having read all sorts of (negative) posts about drivers for both USB and Firewire, and other proprietary tape machine interfaces, I have to ask the question why aren't manufacturers using Ethernet for connecting up audio equipment?

It isn't a question of drivers or OS support: Ethernet is possibly the easiest driver of them all to write: there's only send packet and receive packet primitives. I have to say that I think Ethernet chips are more widely supported than firewire chips.

It isn't a question of bandwidth: Gigabit Ethernet could easily handle multiple high quality audio streams. I mean even 24 bit 192KHz sample rate is only about 6-8Mbps per channel even after adding on encapsulation overhead. So 1Gbps Ethernet could probably handle a mixing desk type application with anything up to 64 top-quality mono channels, and certainly anything at consumer quality.

It isn't a question of cost: Ethernet chips are amongst the cheapest out there.

If isn't a question of protocols: there's plenty of alternative near real time transport protocols such as RTP/AVP that already act very similarly to USB with anything up to 44.1 16 bit or 90KHz clock mpeg2. And that could easily be extended to 192KHz or 176.4KhZ 24 bit professional quality via a new payload type.

It isn't a question of distance: Ethernet can outrun USB2 and firewire by massive multipliers. 100m over cheap twisted pair cable using 1000BASE-T. Or kilometers over fiber.

Is it simply latency? But you have that anyway in a large room. Sound only travels at 300m/s in air, and USB is already serial at ~320Mbps effective max rate. So remote recording and mixing desks already face this issue.

It isn't a question of compatability. Ethernet is as near universal as it comes.

It isn't a question of reliability: (switched) Ethernet networks run for years without any intervention. And you can easily build in multiple redundant paths with fail over.

So why not? Is it really the perceived lack of QoS and bandwidth reservation? Any ideas?

[Matt Syson]

Hi
It is probably on the lines of having a 'ragged' startup into digital audio, where competing 'teams' all came up with similar objectives but also wanting to be dominant.
'Legacy' activities hamper many ideas, elements of DOS in Windows' for example.
Certainly now, to look at all the various chipsets available it would be possible to do things quite easily but many would have to scrap whole chunks of previous RnD activity.
I was at AMEK and witnessed the various incarnations of 'comms' between a computer (ATARI then 'IBM') which, had USB2, Firewire or readily accessible networking chips been available would make things a lot easier but having made it work with an 'own make' comms protocol it is difficult to justify significant change.
Matt S

[gyraf]

It is my impression that you can't use it for real-time operation, as the protocol does not guarantee a specific order of "packages".

I may have this very wrong though :-)

Jakob E.

[5thString]

Originally Posted by gyraf

It is my impression that you can't use it for real-time operation, as the protocol does not guarantee a specific order of "packages".

I may have this very wrong though :-)

Jakob E.

I think you're right. The ethernet protocole doesn't garantee the order of the packages, nor does it garantee that all the packages will be delivered.

[ripple_fx1]

There are plenty of manufacturers using ethernet to distribute audio (Cobra Net comes to mind), but would you want the lovingly handcrafted signal of your high dollar outboard gear digitized and crammed through that inexpensive chip? Not even an all discrete class-a ethernet chip with a valve tacked on for good measure....

However, point taken - ethernet & cat5 is an inexpensive solution for analog and digital signal routing - but the quarter-inch and xlr lobby is large and powerful - people have died for heresey such as yours. Don't even get me started on the oxygen-free copper and esoteric wire....
Cheers! JR

[Matt Syson]

Hi
The issue of 'packages' and timing would be down to the application. Obviously for transport of audio it would need proper 'buffering' and error checking, but as the bandwidth is so high should not be a serious problem.
The need for the above 'overheads' is present anyway.
Who wants quality if we have MP3?
Matt S

[drtechno]

I wondering if anyone has tried running 4 aes/ebu lines with ethernet cable. ( 1 twisted pair per aes channel) I would think that would work.

but running as ethernet protocal for audio would be neat, wierless snake come into mind. I heard of some of the Linux Geeks out there expiramenting with the ethernet media but for now I think it will be locked into perprietory hardware world.

[rodabod]

We've been using audio over IP and video over IP for months now (for broadcasting).

It had a bit of a rough start, but works fairly well now.

Regarding the guarantee of packet delivery, it depends on the type of session. We've been using ASI for video/MPEG for a long time now, and in a way it doesn't differ that much really.

[Me2]

Glad to hear that broadcasting experiments are underway. Also read up about Cobranet (although this seems to miss the point of cost savings by having license costs and too much complexity by converting back and forth from analogue to digital)

Do you think this would ever make the transition into home studio / live audio equipment though?

I have considerable networking experience (20 years+) and have lived through all of the debate on token ring versus Ethernet etc. I can assure everyone that out of order packets just do not happen on small networks: maybe internationally on the Internet when there are imbalanced inbound and outbound routes or parallel path routing, but you wouldn't get that in a small or medium sized network. Even on the Internet, out of order packets are pretty rare. QoS packet marking is pretty much a complete red herring and a waste of time: it just says what to throw away if you don't have enough bandwidth. Jitter can be easily counteracted with a buffer. As for reliability, and packet loss, the previous poster is absolutely correct: it depends entirely on the choice of transport layer. Some transports will simply drop sound packets and cause a click whilst keeping latency low, whilst others would buffer and correct the drop with a retransmission. But the developers are free to choose whatever they want and the choice is certainly not mutually exclusive, so you can switch depending on your application.

Do you think it would it help the industry guys along if I told them that the entire telephone system and voice backbones of some countries have now been converted entirely to VoIP supporting millions of consumers, and no-one even noticed? Not a single telephonist wielding a jack plug in sight.....

Seems to me that a single cable/wireless snake running over Cat5e has got to be worth a fortune in saving of copper during manufacturing, cost of implementation and engineering, and ease of use in most applications. List price of a 100 foot snake is in the same price range as a quality mixing desk.

I can understand people wanting to stick to XLR/ quarter inch for any analogue portion, because they are easy and cheap for short connections, but once the signal is already digital I really don't see the issue. And why would you want to convert this signal back to analogue for mixing before turning it back into digital for retransmission only to be turned into analogue for amplification...... or use a compute-heavy encryption scheme like mpeg2 in a small system where broadcast bandwidth is not an issue.

I suspect other posters are correct, and this is purely due to momentum on the part of manufacturers who still think proprietary (digital) interfaces are necessary.

And if progress requires some heresy, so be it

Who's gonna be the first to build an equivalent of a live/studio mixing desk based on an Asterisk type PABX architecture adapted for high quality audio using PC technology and offering low pricing?

[HughH]

Hello,

SuperMac (AES-50-2005) and HyperMac. Already exists, works great.

Yes, we have used cat5 cable extensively with aes 110ohm distribution. Works great, matched impedance, longer distance than many 110 ohm cables.

Hugh

[Me2]

Originally Posted by HughH

Hello,

SuperMac (AES-50-2005) and HyperMac. Already exists, works great.

Yes, we have used cat5 cable extensively with aes 110ohm distribution. Works great, matched impedance, longer distance than many 110 ohm cables.

Hugh

All due respect. I think this solution kind of misses the point too. Dedicated standard just for audio. Dedicated chip set. Dedicated routers. Dedicated licence costs. Dedicated drivers. Dedicated software.

[rant mode on, and not aimed specifically at the previous poster]
Why don't you guys in the audio industry just embrace the cheap consumer grade compute technology like NAS, or audio over IP over Ethernet, or open source software, to produce high quality products?

Another example is the Slim Devices Squeezebox Transporter solution. The Transporter already has a general purpose processor and a high-quality DAC and an Ethernet network card in it and has great audio specs due to careful clock design. But why invent and write your own server software, so that a remote machine constantly has to be switched on (with all the attendant fan noise and power consumption), when there are already great network transports like Ethernet with literally millions of installed units, and disk file sharing standards and products like NAS that are already more than good enough at much cheaper price points? Why not have the transporter discover the software library contents by reading tags via the NAS file system, grab the audio file, and stream it locally (including all of the time critical buffering). No. Instead they have "SqueezeCenter software (requires download)" that has to run on a separate machine or you have to buy a (more expensive) NAS box that includes a TwonkyMedia server license. And before anyone says "mp3", this machine also supports lossless compression formats and has audio specs and interfaces that compete with my up market CD player.

Is this pure audio snobbery? Or poor engineering choices? Or is the volume and competition so low that there's no incentive to change?

I studied electronics and am a qualified chartered engineer. That included analogue design and digital design and software design. Not just one of the three. That's why I get frustrated at what I see as poor products based on proprietary standards (at inflated prices). Maybe I need to start my own company
[rant mode off]

OK I think I've made my point.

[undertone]

Originally Posted by Me2

Is this pure audio snobbery? Or poor engineering choices? Or is the volume and competition so low that there's no incentive to change?

I'd say it's mostly capitalism and concerns over piracy. What is there to gain by having a software solution that works on any ordinary hardware? What will guarantee that people won't just use it without paying you for it?

I've wondered why this doesn't exist as well. FXTeleport is one solution that carries audio back and forth successfully and sample-accurately for the ASIO protocol (but only for the ASIO protocol), though it doesn't expose the audio channels to anything but your DAW (unlike Jack). So it is possible and reliable, as many composers use it every day. I personally use MIDI via Ethernet every day and I lock machines via MTC and play softsynths in real time. So naturally, audio would be a logical development.

I was interested this a few years ago and did some extensive searches on the net, and while I did find some open source experiments on the topic, nothing was packaged into viable and working software. While the protocol side seems manageable, I think the fundamental problem is interfacing with the OS: you have to essentially create a virtual sound card to and from which you route audio streams. Anyone writing sound card drivers can tell you it's no trivial thing, especially cross-platform. Which is why people writing them typically make sound cards... and the last people who want you to find hardware-free solutions are certainly not the hardware manufacturers.

But if anyone with the requisite talent reads this: I'd buy a license for sure.

[Bob Olhsson]

Ethernet is already used in some high-end applications.

I suspect the main reason it isn't very common is because there's a lot of substandard Ethernet hardware on the market and audio manufacturers don't want to deal with the tech support problems that creates.

According to friends there will soon be nothing but USB3 and Ethernet.

[monomer]

Let me explain some things about computer networks as some people seem to have some misunderstandings regarding this.

First Ethernet.
This is the most basic type of connection.
It is the actual physical link.
It functions only within the scope of a direct connection (or through a switch, which is ALMOST a direct connection).

This basically means that all communication is conducted serially.
There are no issues with packets arriving out of order.
This will alow computers connected through switches to communicate pretty much directly.
Transmissions over ethernet are picked up from the line by the device being adressed. End of story.

This will only work if the sender and receiver can 'see' each other.
This is called a Local Area Network.
(it's all slightly more complicated than this but it will do)

It should be the coolest thing you would ever see for audio.
Fast, flexible and cheap with almost no downsides.

But back in the days people wanted to communicate with other people far away.
So they invented a set of standards that would tell a new kind of device (a router) how to find those other people.

This set of standards was eventually called TCP/IP.

So you already have your Local Area Networks.
What you do is you put a router at some point in your LAN and connect that router to a lot of other routers all over the world.
You would use ethernet to talk to the routers and tell them 'here is a package of data, please send it to someone somewhere who has this address'.
You would also put in a sequential number in each package you send to the router.
But that number is not read by the router, it is read by the receiver at the other side of the world.
The router network (basicaly the Internet) doesn't realy care about the sequence of data. It just sends whatever you give it to its destinations.
It sends it over a route that it thinks is a good route. So each of the packets you feed the router could end up traveling over a completely different route to get to its destination.
So it is possible for one packet to travel for a longer time than another packet.

It is then up to the receiver to put all the packets in the right order.
If the receiver thinks it didnt receive some of the packets needed to reconstruct the complete message it can send a request back to the sender to request a re-transmission of that packet.

This whole thing (and some more stuff) is done by the TCP/IP protocols.
Also, because there is this chance of packets not arriving (on time) and we have to deal with latencies over the internet.
Latency is the time that a packet would travel over the slowest route set by the router(s) you send things through.

But TCP/IP is only realy needed if the computers are not directly in the same network!

So computer networks (Ethernet, the most basic form) can do some realy fancy stuff localy where they are not hindered by the multiple routes that could be taken to reach a destination.

You could send off enormous ammounts of data pretty fast.

So i'm also wondering why ethernet was never realy used in pro audio.
Maybe its' just too 'nerdy' for the audio peeps?

[gsilbers]

its been used for a while..

check out fx teleport and audioport from audioimpressions.com

and midiovelan for midi (less data but justin case)

[undertone]

Originally Posted by gsilbers

check out fx teleport and audioport from audioimpressions.com...

Thanks for audioimpressions! It's about time. Now I have to wait for someone to do Mac to PC...

[roboton]

and I think the ramifications are enormous.

I would use UDP or RTP. I am willing to be wrong, but I see nothing good coming from using TCP in an audio setting. Everyone says the packets arrive in order, but I personally would not want to bank on it, especially if you had 50 or 100 ethernet-based patch points trying to talk to say, one ethernet-based DAC. The latency in handling that many TCP streams concurrently, especially if each one were 10-20 mbps per second could potentially cause problems.

I would think that a high-end switch with a backplane large enough to support "theoretical gigabit" across every port would be a smart investment to make. Say I had a 24 port gigabit switch, I would want it to have a 10 gigabit "fast path" so that 10 devices could talk across the switch at full gigabit speeds (unlikely) without oversubscribing the switch.

The other thing I would do is make sure that any "aggregation points" such as a DAC or DAW would have at a minumum of two gigbit ethernet ports capable of running as close to the gigabit limit as possible (very few applications and OS'es are capable of running at gigabit speeds...). I would team these two ports into a 2 gbps aggregate interface.

I would also consider an out-of-band active probing protocol that can then supply data to all the participating audio devices to regulate the UDP/RTP flows a little better. Basically a "Call Admission Control" for all the devices within a given "Audio over IP" system.

What I am envisioning here is an ethernet-based studio that allows dozens or more ethernet based devices to transmit audio all at the same time. Think about your console with ethernet-based send and receives into a cat 6 patch panel that is patched into your ethernet-enabled outboard gear, or even better, a patch port with digital-analog conversion on board so that you could patch out to analog gear and back in.

The thing I am getting at is that there is no reason you couldn't have hundreds of ethernet jacks in your studio, all talking across a switched network. This would be possible, but vendors would need to build some fairly robust gear to make it possible. Netgear and D-Link wouldn't deliver.

[Me2]

Originally Posted by roboton

> What I am envisioning here is an ethernet-based studio that allows dozens or more ethernet based devices to transmit audio all at the same time.

Exactly. An Ethernet switch carrying virtual audio channels completely replacing the "switch" fabric" / patch bays, cable snakes, mixers, and physical buses of a traditional mixing desk with a complete and cheap any-to-any space time space switch matrix with built in mixing: hence the telephone exchange references earlier. That's also just PCM audio switching: just not very high quality.

And I have no idea why D-Link couldn't do this for you. I know you guys love to over engineer. But there already are enough cheap non-blocking Ethernet switches that run at wire speed on all ports simultaneously. Have a look in some of the fanciest data centres in the World. Does everything run on massive Cisco switches? Nope. You'll find plenty of cheaper brands in there too.

It just takes a bit of imagination to separate out the various functions required into building blocks. Why do you need to load ALL of the audio streams via a NIC into an OS that isn't jitter/real time optimized via two parallel gigabit interfaces just to mix it and send it back out again on the same interface? OK maybe some of them for special effects treatment that can't be done in silicon, but not all. Why would you even go back into the analogue domain before the consumer kit (e.g. SACD player/ iPod) once you have converted (which is a relatively high latency operation)? Again, maybe for some special analogue effects inserts, but not for all audio streams.

Ethernet switches already exist on single chips. See https://www.broadcom.com/collateral/pb/5324M-PB01-R.pdf You can also already get a DSP mixer with basic effects on a single chip (see M Audio's latest offerings which do local mixing in the IO unit to avoid latency e.g. M-AUDIO - ProFire 610 - High-Definition 6-in/10-out FireWire Audio Interface with Octane Preamp Technology) Hopefully someone's gonna combine the two of these functions and build a PCM based DSP mixer chip with built in Ethernet interfaces one day. Basic PCM based mixing and patching is no more complex than clocking, adding, and multiplying. Hardly complex functions to do in silicon at wire speed when you already have an ethernet switch fabric as a basis to handle the IO. Then all you need to do is load in the virtual patching config and mixing parameters from your (smart) external controller (already exists in M Audio's drivers), one or more disks for recording (Ethernet NAS), and add some effects units, which I suspect is where the residual cost will reside. Equally you could build a high quality DAC into your instrument with Ethernet out (how much do you think these chips really cost if a USB audio unit is retailing in a shop for $200?)

Bye bye $10000 digital mixing desks. Hello $500 ones. (or less)

[roboton]

Man, that is an awesome response, and one I have to totally agree with. I'll ponder that for a couple of days and let you know what I think.

[space2012]

Yamaha mLan
FX-Max Teleport

[monomer]

Originally Posted by space2012

Yamaha mLan
FX-Max Teleport

Yeah,
What happened to mLan ?
It should have been the next big thing years ago!

[Adams1234]

In the live world I've seen digital snakes coming about rather quickly. mlan, and ethersound within Yamaha digital boards are becoming much more useful. The problem there has been getting a line signal at the stage and having control over the head amps on stage from the console. it can be done, and is being done, but it usually locks a person into one manufacturer from snake to console. Pro co has also made a digital snake but you have to buy extra boxes for head amp control on stage, and you add an extra d to a conversion depending on which unit you go with.

[undertone]

Originally Posted by Me2

Exactly. An Ethernet switch carrying virtual audio channels completely replacing the "switch" fabric" / patch bays, cable snakes, mixers, and physical buses of a traditional mixing desk with a complete and cheap any-to-any space time space switch matrix with built in mixing: hence the telephone exchange references earlier.
...

Sounds like a business plan. I'm in!

[Jimmy B]

And of course, 2 years later this comes out...

RedNet

[Ed Zeppeli]

That looks wicked! For some reason when I say Rednet I can't help but think of The Shining.

I wonder what they'll sell for...



Warren

[undertone]

Originally Posted by Jimmy B

And of course, 2 years later this comes out...

RedNet

...and it's tied to proprietary hardware.

Of course.

[cyrano]

Originally Posted by undertone

...and it's tied to proprietary hardware.

Of course.

Not really. Just the endpoints. Anything in between, such as switches is just standard. They did state that they won't support other hardware. But that's understandable. Some network hardware isn't very good and it would put a lot of strain on Focusrite's support...

Dante uses standard IP-based networking and components, such as Ethernet cables, routers and switches, to carry up to 256 channels (128 in and 128 out) of high-resolution digital audio over a standard Ethernet network.

Let's say it's a partially open system. The Rednet PCIe card for instance, is advised, but not required.