>Maybe more an issue of the protocol than of the nominal speed. The >ethernet protocol has no fixed timeslices or such. If a data block >wants to travel over ethernet it sticks its head out, looks to the >left and right and if it sees a free space among the other data it >quickly jumps out and swims with the stream. Its following brothers >and sisters get somehow organized behind the leader. > >If you try audio over ethernet you will see a certain amount of >steady latency which does not change during one travel session. But >the latency won't be the same the next time because the time when the >first bits can take off differs. I am not really sure but I doubt >that faster ethernet will change that situation. Maybe a much faster >version but a 10 times faster net will not result in a 10 times >better performance. There is still the protocol. This is true enough as far as it goes, but the issues of the ethernet protocol itself can be pretty much minimised by not having any other data on the same network (and with modern networks where everything is switched, that can often be no other data on the same virtual network). If the data 'sticks its head out' and always sees no other data, the intrinsic ethernet latency is very small. Ethernet over audio should be quite doable - its just that it requires getting things right at several different levels (physical, network layout and switching, TCP/IP tuning, etc), so its hard to do well, and is nowhere near as 'plug and play' as people are used to ethernet being (especially if you want to get the latency as low as you can). >Honestly, I am not sure if audio over ethernat has a future. Ethernet >was never thought for that kind of stuff. If we had a kind of fast >"token ring" network i.e. or a dedicated protocol for audio (I think >Yamaha tried that) then yes. But with our usual networks it is >currently just an interesting experiment. Ethernet is the foundation of modern networking, and is likely to remain so for the foreseeable future, so thinking about token ring and such is just dreaming - and to be honest, I think its going to be far more practical for any use that requires a 'real' networking protocol than any alternative. Tuning ethernet right and getting an ethernet setup that has the latency as low as possible is almost certainly going to be easier in almost any situation than messing around with different protocols. Its also worth noting that its not really the case that token ring has better latency than ethernet - its just that token rings latency is far more deterministic and has an upper bound, which is a useful property in many situations, but ethernet should be as fast or faster when running in a low latency, low traffic, network. Though for small networks, where the machines are basically in the same room, firewire is probably the most practical alternative. You can run IP over firewire (its built into MacOS X), and if you want to experiment with audio over TCP/IP networking without the limitations of ethernet, that would be the obvious thing to try. I'd be interested to hear if the results are significantly better in this situation. Cheers David