On Sun, Jul 11, 2010 at 1:17 PM, Joshua Boyd <jdboyd(a)jdboyd.net> wrote:
I just am not sure where you are getting that gig-e is
an old standard
that's been used for decades to deliver realtime information with
guaranteed quality of service connections.
Ethernet probably got it's official start in 1976 with the publication of
Metcalfe and Boggs "Ethernet: Distributed Packet-Switching For Local
Computer Networks." They'd been working with 2.9M/s networks for
several years prior to the publication of the paper.... Since then,
speeds have increased, network topologies have changed from a shared
carrier to point-to-point, and it has been used for a variety of
protocol-and-higher-level work in using it for multimedia or
guaranteed data delivery:
http://en.wikipedia.org/wiki/Avionics_Full-Duplex_Switched_Ethernet
http://en.wikipedia.org/wiki/Quality_of_service
http://en.wikipedia.org/wiki/IP_multicast
http://en.wikipedia.org/wiki/IP-TV
http://en.wikipedia.org/wiki/IP_telephony
http://en.wikipedia.org/wiki/Voice_over_IP
If you see GigE doing that, it is probably because it
is in controlled
circumstances, or the application has large enough tolerances, and still
some luck may be involved.
Gig-E is a cable running at a given datarate. Obviously, it's
controlled circumstances: one uses things like AFDX, QOS, Multicasting
or whatever other techniques one has at ones disposal in order to give
the needed data capabilities. Given that this is data-transfer that
(potentially) people's lives depend on, it's based on solid
engineering and not "luck." The concepts, the software, the protocols,
etc on this are often decades old, as I stated initially.
It isn't a terrible idea, but I think it would
only be really reliable
if you used a dedicated gige port and spoke raw ethernet instead of
tcp/ip.
The point of mentioning "Gig E" as opposed to 10Base-T running over a
coax is there's enough bandwidth available that you could easily have
general traffic and your "realtime-needing" audio or video on the same
cable. Protocols to do this have been around for decades, as I was
saying. It is well-understood engineering.
You just have to setup the "controlled circumstances" so that you can
guarantee a certain amount of bandwidth to your video or audio feeds.
How do you think companies with digital phone service share that
network with it's general internet access? Or for that matter, on a
different kind of network, how do cable providers manage to keep the
digital TV signals going uninterrupted while at the same time having
bandwidth allocated for home phone service, and home internet service
as well?
Still, a fast E device that plays 8 or 16 channels may
be quiet
reasonable, and under the right circumstances both reliable and easier
to build than a USB2 device.
The "pros" have been doing this all along:
http://en.wikipedia.org/wiki/MADI
http://en.wikipedia.org/wiki/EtherSound
http://en.wikipedia.org/wiki/AES47
http://www.qscaudio.com/products/network/QSys/Q-LAN_WhitePaper_2009-10.pdf
http://en.wikipedia.org/wiki/Audio_over_Ethernet
> PPS: likewise, i want my next MIDI port to be an
ethernet port with
> some MIDI jacks that talks ipMIDI and then use
>
http://qmidinet.sourceforge.net to talk to your ethernet-connected
> midi devices via alsa).
Sounds like it is time for someone to get a MCU
ethernet dev board...
Only if financial remuneration is involved, alongside a business plan
that involves getting these into people's hands at a reasonable cost.
-- Niels
http://nielsmayer.com