Entertaining, but missing the point. No-one disputes the fact that computers do data transfer. Although it's not completely given, there's a high probability that the same noughts and ones arrive at the DAC's buffer that were on the CD. So far, so good. Some questions, though:
1. If not computer pixies, what ensures data integrity - that the same noughts and ones arrive at their destination?
2. What else comes down the wire, onto the DAC, into the highly sensitive clock, and - at light speed - throughout the traces and wires of the DAC and amplfier?
3. How exactly is an analog signal different to a digital one?
4. What 'shape' is that data in when it arrives, in terms of jitter?
DACs are getting better. And a really good DAC will 'take care of' some of the difficulties a computer presents. But the DAC pixies don't fix everything - otherwise there wouldn't be such clearly audible differences between transports, would there?
OK, I worked alongside the guy who holds the patent for 10BaseT networking. As a Pro, this is what you may need to know to display some credibility, before asking such questions in public pertaining to integrity of network data. Point by point:
1. It's called checksum. You should research TCP/IP before you resort to your old cable ways:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet destination address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet source address (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP header, then TCP header, then your data |
| |
...
| |
| end of your data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ethernet designers allocated 48 bits for the Ethernet address. When you send a packet out on the Ethernet, this involves the Ethernet header. Every Ethernet packet has a 14-octet header that includes the source and destination Ethernet address, and a type code. In addition to the addresses, the header contains a type code. The type code is to allow for several different protocol families to be used on the same network. So you can use TCP/IP, DECnet, Xerox NS, etc. at the same time. Each of them will put a different value in the type field. Finally, there is a checksum. The Ethernet controller computes a checksum of the entire packet. When the other end receives the packet, it recomputes the checksum, and throws the packet away if the answer disagrees with the original. The checksum is put on the end of the packet, not in the header. The final result is that your message looks like the above.
Your music is embedded into each packet. But of course it is not music -it is 1s and 0s. No more. If a bit flips, then packet is sent again, and again and millions of times a second, until it checks to source file.
2. Nothing comes down the copper ethernet wire that can make any difference to the packets that await unpacking by the DAC. Otherwise they are resent as per above.
3. ????
4. There is no jitter in ethernet packets as there is no clocking before the DAC and packet transfer is dynamic and variable based on other packet traffic. And NO the packets can't taint or smear each other! It is so misinformed (that is being polite) to suggest as an expert Pro, to others seeking to get into CA, that jitter exists on a network. Data packets arrive not necessarily in sequential order, and are reassembled. That is why there is no timing.
Your last point on transports: I have found both Sonos, Squeezebox, played back to back with same FLAC through same DAC (Cyrus XP) to sound exactly the same. Your old world of spinning CD platters, powers supplies and cables, etc just does not apply to the newer world of the network as a digital transport mechanism, and it shows.