On Sun, Jul 11, 2010 at 1:17 PM, Joshua Boyd <jdboyd@email-addr-hidden> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Jul 12 20:15:02 2010
This archive was generated by hypermail 2.1.8 : Mon Jul 12 2010 - 20:15:02 EEST