I have asked you many questions in this thread - every time you show a dearth of knowledge in an area, I ask you a question. Here's another question to add to the many unanswered questions I have had to ask you - do you know the difference between a NAA & other ethernet devices in terms of functionality?
As for as the functionality we are discussing here, there is none. Let's dig into this. The Sonore MicroRendu has two boards. One board is an off-the-shelf, stand-alone computer:
This is a tiny board but courtesy of advancement in VLSI (IC) development we have a complete system on a chip, much like you have in your phone or tablet. There is flash memory that stores the operating system (Linux) and applications. There is DRAM memory. There is an Ethernet interface and there is USB. All of this is then coupled to another card created by Sonore that has a handful parts such as USB hub, Ethernet connector (missing on the small board computer), etc.:
Put the two together and you have a very small computer. In that regard, it is identical to a computer server you would build yourself. You might run Linux on that computer, Windows or Mac. No matter which, they all use a CPU, memory and a modern operating system to take care of
networking software stack which sits on top of the Ethernet physical layer. So whether you use a large computer or Sonore, the functionality remains the same.
Whether you use a computer server or a streamer what occurs is the same:
1. Ethernet packets (chunk of data) arrive at unpredictable times from the server.
2. Ethernet traffic is captured into DMA memory and a hardware interrupt is generated.
3. The packet is copied into kernel memory.
4. A DPC is called to handle the packet at lower interrupt priority.
5. One or more packets may arrive before DPC is serviced.
6. Sometime later when there are no higher priority hardware interrupts, the kernel services the DPCs
7. Appropriate function is called in the IP layer of the networking stack to handle the incoming packet
8. IP receive packet function examines the packet looking at destination address. If it is for another computer in its routing table, it will re-transmit it on its alternate interface.
9. If not, the protocol field in the packet is examined. In our situation it is most likely TCP packet (although for Internet streaming it may also be UDP).
10. Packet is put on the TCP receive link and TCP receive function is called.
11. Going into the workings of TCP is beyond the scope of this post but suffice it to say, checksums are preformed, acknowledges are sent if necessary.
12. TCP finds the app looking for its data by the port number in the packet. It searches its queue of sockets opened in listen mode with that port number.
13. Data is put on that socket queue and call is made to the operating system to wake up the process waiting for it.
14. Process thread is then running which then takes the raw data and does what it thinks is needed. In the case of USB output, another worker thread likely has that device open and with the appropriate API the data is pushed onto that (I am skipping tons of detail here).
15. This being a full blown computer (streamer or server), tons of other async activity is occurring. Timer interrupts are firing to update system time/clock, memory management to page in process pages and allocate buffer memory for networking. Other daemons are running that cause context switches, CPU cache flushing, TLB updates, on end on.
I will stop here and note again that so much activity is going on in the system to move bits from network interface to USB. And the same happens whether you are running an embedded Ethernet solution like a streamer/microrendu or your Mac, PC or dedicated DLNA server.
Now for anyone to go and focus on the Ethernet wire as if it is some RCA audio connection is just plain wrong. EThernet cable is a tiny, tiny portion of the system footprint. Crap load of other stuff is running all over to implement the rich interface we use on Ethernet whether it is file sharing, Roon endpoint, DLNA or something else. What it absolutely is not, is a dump data pump like you are assuming.
No matter what you do here, you are dealing with a highly noisy system compared to S/PDIF or USB. The solution to deal with that is to
buy a high-performance DAC that does not even blink when all this is happening outside it. Any DAC that audibly modulates its output because way, way upstream some ethernet cable is moving bits around needs to be thrown in the trash can.
Computer architecture and networking has been part of my professional experience for some four decades now John. I did my first Ethernet driver back in 1984 or so. Implemented TCP/IP stack shortly after. Kernel development for years more. And management and design of computer architecture for another decade. It is what has paid a roof our head and pays for the household bills still today
. Now, I don't know everything so happy to be corrected. First, I like to understand your background in this regard. Do you mind explaining what you know and how you came to know it?
