The_Lhc said:
"less control of the stream" - that doesn't even mean anything! It'll be noticable because you'll get drop outs (ie silence) in the sound because the streaming device can't buffer ahead far enough to play from memory whilst it waits for the network to catch up.
No, that's where you are wrong. Most people won't notice even 10% packet loss especially if the stream is mp3 or some other lossy compression. To an audiphile whisch uses uncompressed or lossless compression it would be audible but not as silence, to achieve audible silence it would have to drop several sequental packets, at least 30-50 depending on packetsize, although it would be less if Jumbo Frames are supported and used. It just sounds like something is missing when you have packetloss due to congestion since about 1 in 10 or 1 in 50 frames are missing.
The_Lhc said:
It might well do but that's not the same as improving the sound quality. That's improving the sound quantity, ie first there was no sound, then there was. That ISN'T what the OP is talking about however.
In the case of real-time ethernet streams case the
quality is directly dependent on the
quantity of frames that can be transmitted without queueing and without dropping.
Real-time streaming over ethernet has less to do with audio and much more to do with actual networking in a packet-switched environment. Perhaps you may consider consulting some networking literature in the discipline of real-time media.