Ethernet Recording Interface?

d.bop

New member
I'm just curious to know if anyone has ever come across one (or if they even exist..)

It seems to me that using ethernet instead of firewire or usb would be a huge plus. We could have much longer cable runs (no more loud PC in the mixing and/or live room!) and not to mention: 1Gbit transfer speeds (vs 400Mb/s with fw and usb.)

The only problem I can think of is a pc detecting the device, but then again...I've been out of the "programming loop" for years, and the rate technology is moving these days, I'm sure it's possible.

Anyway, has anyone ever seen one/made one/dreamt of one/etc?
 
I've never seen one, but I can imagine they would be problematic. I'm sure they could code something to make the computer recognize it, but I think it would just conflict with wireless cards and other networky things. But I could be wrong.
 
The transfer rate of FireWire 400 is plenty. The transfer rate of USB 1.0 was very nearly plenty for most purposes. Bear in mind that even the borderline obscene 192 kHz audio at 24-bits only takes 4.6 Mbps per channel. Do you really need 217 channels of simultaneous audio I/O? :)

Ethernet has a whole host of problems for this sort of thing---latency, for one. The latency through a TCP/IP stack is colossal compared with that of a FireWire stack, so you'd have to stay down at the raw packet level, and you'd probably end up having to do some serious kernel programming work to make it play nice with any other traffic on that link.

I'm too tired to think through all the other problems, but I'm pretty sure it would be a complete disaster. :D

Not saying it hasn't been tried, though, at least using dedicated hardware:

http://en.wikipedia.org/wiki/Audio_over_Ethernet
 
Thanks for the quick replies!

Yeah... now that I'm actually awake, I'm starting to realize that it wouldn't really work the way I was thinking haha. (Another late-night, half-asleep, "genius" idea) :D

Thanks again! (and thanks for the links!)
 
It's not totally out to lunch. I've been told that some folks at a major chip vendor who will remain nameless think it's a good idea. On the other hand, that company makes what is IMHO some of the worst, most buggy, and most bloated Ethernet silicon on the planet, so perhaps that's not saying much. *shrugs*

In theory, at least, it could be done, and has been done on occasion as I mentioned. I'm just not sure it is worth the effort to put together a non-TCP-based discovery protocol on yet another bus, and particularly on a bus that has no concept of isochronous communication and would thus probably require some pretty significant changes to hardware---switches specifically come to mind.
 
Euphonix uses ethernet for all their stuff... so how bad could it be?? isn't the MADI systems that the big movie studios use ethernet as well???
 
As far as stuff hooked up to computers goes, AFAIK Euphonix just uses it for control surfaces, not audio interfaces. And no, MADI is not based on Ethernet. AES50 is based on the Ethernet physical layer, but I wouldn't go so far as to describe the result as being "over Ethernet". AES51 is apparently closer.

http://www.aes.org/standards/b_reports/b_meeting-reports/aes125-sc-02-02-report.cfm

There are a few devices out there that do use Ethernet, of course---mainly TV studio gear---and apparently it works well in that limited environment. Where you're likely to get into the most trouble is that there are thousands of different bits of Ethernet silicon out there, not all of which work all that well (and the most common ones are IMHO generally the ones with the worst performance and reliability). Within a very limited set of configurations, Ethernet would probably work just fine (with very specific Ethernet cards and possibly custom drivers for them). When you actually try to deploy this in a broad manner like you'd have to do for consumer-grade products, though, I'd expect it to be an absolute train wreck. :D
 
As far as stuff hooked up to computers goes, AFAIK Euphonix just uses it for control surfaces, not audio interfaces. And no, MADI is not based on Ethernet.
Yeah, Euphonix's big thing is how much faster and more accurate Ethernet is vs MIDI for control surfaces. I haven't personally used an MC-Control, but the concept is amazing. You're not limited to MIDI commands, so you can program any button to do anything, even toggle applications - say... jump from your DAW to film editing software; and the control surface instantly adapts to whatever application is "live." Very cool.

There are a few devices out there that do use Ethernet, of course---mainly TV studio gear---and apparently it works well in that limited environment.
And those using ISDN, as well. In a sense, ISDN is pretty close to what the OP was after. Digital audio moving from one interface to another via Ethernet connections. As was mentioned earlier in the thread, anyone who's ever worked on ISDN or SourceConnect knows there's about a two-second delay (depending on how & how far you're connecting). Not a problem for transferring voiceover, but completely impractical for anyone producing music.
 
Yeah, Euphonix's big thing is how much faster and more accurate Ethernet is vs MIDI for control surfaces. I haven't personally used an MC-Control, but the concept is amazing. You're not limited to MIDI commands, so you can program any button to do anything, even toggle applications - say... jump from your DAW to film editing software; and the control surface instantly adapts to whatever application is "live." Very cool.

It's hard not to be more accurate than MIDI. Unless you're using a nonstandard clock, your clock rate is 31.25 kbps, or just shy of 4K bytes per second. A control change message takes three bytes, one that contains the channel ID and the command, one byte for the controller number, one byte for the value. So basically the commands can be at no better than about 1ms granularity, and that's if you aren't sending control changes on more than one channel down a single MIDI cable. As a data format, MIDI is really remarkably poor. :D



And those using ISDN, as well. In a sense, ISDN is pretty close to what the OP was after. Digital audio moving from one interface to another via Ethernet connections. As was mentioned earlier in the thread, anyone who's ever worked on ISDN or SourceConnect knows there's about a two-second delay (depending on how & how far you're connecting). Not a problem for transferring voiceover, but completely impractical for anyone producing music.

Heh. Well, not all Ethernet-based stuff is that slow. Part of the reason for the latency on ISDN is that it uses data compression. Source-Connect sits on top of either the TCP or UDP layer (probably the latter, but I'm not sure), which is pretty much guaranteed to involve a lot of latency and buffering to avoid dropouts due to network congestion causing packet delivery delays.

An Ethernet-based system would not be carrying IP traffic on the same wire. You'd be using an Ethernet card strictly for communicating with the device, so there's no contention, and since Ethernet is full duplex (in modern versions), the protocol could be pretty dumb by comparison and still work.

The big reasons I can think of that it isn't used more broadly are A. compatibility, and B. it would tend to monopolize the Ethernet card because no standard Ethernet switch has any notion of packet priority or isochronous delivery, and thus a switch would likely add significant jitter, which has significant implications when working at low latencies. :)
 
An Ethernet-based system would not be carrying IP traffic on the same wire. You'd be using an Ethernet card strictly for communicating with the device, so there's no contention, and since Ethernet is full duplex (in modern versions), the protocol could be pretty dumb by comparison and still work.

That right there is the point

The big reasons I can think of that it isn't used more broadly are A. compatibility, and B. it would tend to monopolize the Ethernet card because no standard Ethernet switch has any notion of packet priority or isochronous delivery, and thus a switch would likely add significant jitter, which has significant implications when working at low latencies. :)

Not necessarily. Number one you wouldn't necessarily have to use Ethernet switches, and even then there are powerful switches for example from Cisco that support QoS tagging allowing for giving higher priority to certain packets over others. This is how VoIP is implemented and how they get around the high jitter and latency issues with that. Granted VoIP traffic is highly compressed and voice traffic isn't nearly as demanding as multichannel 24/192 audio traffic.

However, you only need to look at the Waves ASA hardware accellerators to realise that Ethernet can be a viable platform for many audio applications.

Also, don't forget that Ethernet only describes the physical medium and doesn't mean that you'll need to use TCP/IP, IPX/SPX, AppleTalk or any other universal networking protocol.

Having said that, there are systems allowing several networked computers to run as a processing farm where you can use these computers on the network to essentially use them plugin accellerators.

Check out FX Teleport for example of using LAN to create a CPU farm for offloading VSTs to other computers, running in real-time.
 
I haven't seen or tried ethernet connect yet. However I do work for a music software company and several customers customers have told me that they have had many problems with ethernet connect. It's a very new technology... maybe wait til they get all the bugs out?
 
Hey everyone,

Wow, thanks for all of the responses! Yes, I was talking about a dedicated NIC card for the audio interface. I ask because I know there are interfaces out there that use CAT5 cable to connect controllers, not to mention Reaper and FXpansion software, etc, and that current firewire and usb cable lengths are pretty short without using expensive repeaters and I know CAT5 can basically be run through an entire building. I still think this could eventually be a pretty great option.

Anyway, continue on with the discussion. It's getting interesting :D
 
Not necessarily. Number one you wouldn't necessarily have to use Ethernet switches

You pretty much would if you want to have more than one device attached to that port, which was my point. I mean at 100 Mbit and lower, you could get by with a "every device knows when to speak" protocol and a hub instead of a switch, but I don't think Gigabit non-switched hubs exist.


and even then there are powerful switches for example from Cisco that support QoS tagging allowing for giving higher priority to certain packets over others. This is how VoIP is implemented and how they get around the high jitter and latency issues with that. Granted VoIP traffic is highly compressed and voice traffic isn't nearly as demanding as multichannel 24/192 audio traffic.

Yes, but you're not likely to see that stuff in people's homes. As far as this stuff being practical for anything but the very top end of the market, I just don't see it happening. For it to be practical to replace something like USB or FireWire, you'd basically have to implement all the protocols for things like device enumeration, isoch timing, etc. that FireWire implements in hardware, only you'd have to do it all in software. Either that or you'd have to use custom Ethernet silicon (I'm referring to the NIC here).
 
I haven't seen or tried ethernet connect yet. However I do work for a music software company and several customers customers have told me that they have had many problems with ethernet connect. It's a very new technology... maybe wait til they get all the bugs out?

Presonus is hinting that they've got a Gig-E product in the works.
 
Hey everyone,

Wow, thanks for all of the responses! Yes, I was talking about a dedicated NIC card for the audio interface. I ask because I know there are interfaces out there that use CAT5 cable to connect controllers, not to mention Reaper and FXpansion software, etc, and that current firewire and usb cable lengths are pretty short without using expensive repeaters and I know CAT5 can basically be run through an entire building. I still think this could eventually be a pretty great option.

If your device can work at S100 speeds, you can repeat over CAT5 with this:

http://www.pro-audio-warehouse.com/tp-300fw-p.html

I'm not sure which interfaces, if any, would be happy at S100, though.
 
Ethernet type networks are used in FOH applications in lieu of analog snakes. So it looks doable as an interface, just have to dedicate the nic card to the one task which means adding a second one to your computer.
http://www.mackie.com/products/ds3232/
Chili,
From a read on Mackie's site link here, it appears that this is similar to the Euphonix units in that - at least the way I read it - all the audio processing appears to stay within the box on stage, with the desk acting only as a controller. Am I reading that wrong?
 
Chili,
From a read on Mackie's site link here, it appears that this is similar to the Euphonix units in that - at least the way I read it - all the audio processing appears to stay within the box on stage, with the desk acting only as a controller. Am I reading that wrong?

You know... I'm not too familiar with it. But it looks like the audio does get sent down the Cat5 line. My thinking is if you want to use outboard gear, like reverb, you'd do it at the FOH station.

But I know what you're saying and that would seem like a better idea. Put everything on stage, ITB processing complete with DSP fx, a controller at the FOH and connect wirelessly. I'd imagine network traffic in this case would be minimal. No snake at all. Very cool. Does anyone do this yet??? Hmmmm...... thinking here. :rolleyes:
 
Chili,
From a read on Mackie's site link here, it appears that this is similar to the Euphonix units in that - at least the way I read it - all the audio processing appears to stay within the box on stage, with the desk acting only as a controller. Am I reading that wrong?

It actually is an audio pipe and a bidirectional control channel on a CAT-5 cable. No Ethernet involved except insofar as the cable pairs are twisted in the same way. It probably has as much in common with Ethernet as ADAT Lightpipe has with Ethernet over fiber. Same physical medium, different signaling, different data format on top of that signaling, etc.
 
Back
Top