The main reason why I prefer TCP/IP is that it is a reliable protocol. This means the data received is not susceptible to jitter/noise/interference etc... Because there is a checksum to prevent data corruption. So, this means that whats receive will be exactly the same as what is sent. Since TCP/IP works for wireless, we dont even need cables to transmit data. ITs also not limited to network cables. We can use optical fibre as well. Even HDMI can be used for data transmission. Some switches uses HDMI cable to link up the switches (stacking).
UDP is good but because it does not re-request for packets that is corrupted, its not so good for audio.
Although its not compatible with existing software, its very easy to "convert" the packets into data that can be used by the device. The best thing is since all these is done within the device, its alot easier to control noise/jitter etc....
I think you, like a poster earlier, are mixing up two different types of "audio transmission".
One, there is the high-level streaming model in which an encoded audio/video file is streamed from a content acquisition device to a network-connected "black-box" audio/video rendering device (that takes care of decoding and processing internally requiring no cables or using current mix of interconnects when necessary). These are typically called networked processors/amps. They can use pretty much any network protocol and do it wireless. But given IP networks are the easiest and most prevalent wired or wireless, that is what it has already converged to. There is typically sufficient buffering at the application level to not be affected much by underlying network delays or re-transmissions (within reason) or clock sync issues. These aren't competing with S/PDIF or HDMI for such applications.
Two, there are interconnects within the processing of the audio chain. Here you have to separate short-haul interconnect requirements (within an audio/video stack of equipment) and long-haul requirements (zone distribution, large theaters, etc. HDMI, TosLink, etc., have advantages (but not issue-free) for the former - direct point-point interconnects, zero config, no QoS requirements, no thick protocol stacks, etc. Networked protocols have advantages for the latter to reduce wiring clutter, have higher redundancy, etc.
All of the second type are under strict real-time audio constraints with virtually little or no buffering at the "application-level" for these transmissions. All delays, clock sync, protocol decoding, etc., are done with transceiver cards as part of the underlying protocol. This is where direct interconnects makes more sense than thick protocol stacks at either end for short-haul interconnects where the advantages of the latter aren't as much of a need.
USB is kind of weird in that it has been used for both of the above applications (as USB audio for the second type and as simple data transmission for the first type) but it wasn't really designed for either as a peer-peer inter-connect in particular - and hence the host/controller dichotomy, etc.
Kind of pushing one technology as a solution to all the different application is more ideological and hammer-and-nail situation than the best technical solution. So, context of what is required matters.
The digital interconnects are not as obvious as analog interconnects to many because they might have all the digital processing inside a single box. But when you start experimenting with and get experience with using separate boxes (for SOTA in each function), you start to realize the mess of inter-connection requirements and why the big seriously compromised all-in-one boxes are getting a virtual monopoly in deployment in consumer markets.
The solution to breaking up this processing into separates (in the digital domain) is not pushing connection technology that requires network geeks or some technical configuration for QoS or discovery or whatever. Just plug in a cable at both ends and you are done. If you have a universal connector for this purpose to replace the mess of inter-connect types available all the better for both consumers and manufacturers.
That was the motivation for this thread.