On Sun, Jul 11, 2010 at 1:17 PM, Joshua Boyd <jdboyd@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
