The key to success is avoidance of data copying. Usually data streams are moved from the Ethernet Controller to the Ethernet's driver buffer, then moved to the TCP buffer, again moved to the application buffer and finally from the application buffer to the MP3 decoder buffer. Some systems may use additional steps. Nut/OS tries to avoid these copies. In extreme, the data may be moved directly from the Ethernet controller to the MP3 controller. In reality this will fail, because TCP isn't realtime, but playing MP3 is. So at least one buffer stage is required to compensate the non deterministic arrival of TCP data. Each packet received is moved from the Ethernet controller into a so called NETBUF. Each NETBUF is added to a connection specific queue until the application request data from the connection. For portability reasons and to keep things simple, the application provides a buffer and calls NutTcpReceive() to get that buffer filled with application data out of the queued NETBUFs. This is another copy, but frees the application from dealing with system specific NETBUF structures.
The smart part is, that Nut/OS offers a special buffer management to avoid the final copy into the decoder buffer and that the Nut/OS MP3 decoder driver makes use of this buffer management. As stated, normally the application buffer is filled by some kind of read statement (first copy) and transfered to the driver by some kind of write statement (second copy).
When using the segmented memory management, the application will query the driver for buffer space first and then pass this buffer to the TCP read routine. This way the TCP read routine will directly fill the buffer of the decoder driver. When this has been done, the application commits the buffer filled and requests a new one and so on.
Finally the segmented memory mamagement API can not only handle a continuos memory space, but also one that is divided into several segments. This is usefull with banked memory hardware provided by Ethernut 2 boards.
1.5.1