Specifications

to the upper limit that was passed to the function. It returned before the full 1.5Kbyte

packet was received, normally at 536 bytes. This was while the player was actually

playing a song. If the player was stopped and the play was pressed again, the first

packet, and often the second packet would be 1.5Kbytes and the following packet would

be closer to 536bytes. It would then receive 536 bytes from that point on. This

suggested that the TCP receive function that was being called on the player was not

directly responding to the TCP send on the server. The Nut OS must have been handling

the direct receives from the send, placing the data into a buffer and then the TCP receive

function must have been reading out of this buffer. To test whether the function worked

synchronously, the limit of the TCP receive was set to a value of 3Kbytes. If this

function synchronously received data from the TCP send then it would not receive more

than 1.5Kbytes, because this is the size of the packet the server sends.

The test showed that indeed it did exceed the 1.5Kbytes and even sometime received the

full 3k after play was resumed. This meant that when the program disabled access to the

TCP receive, and expected it to stop receiving, the operating system kept receiving data.

Then when the receive was re-enabled it received this old data out of the buffer. This is

apptopriate for the pause function, but not for stop, next or previous, which all need to

play fresh data from the beginning of the song.

A lot of research was done into this underlying Nut OS buffer. It was definitely there

but the Ethernut documentation provided little information about it or how to

manipulate it. It was expected that a function might have been provided to flush the

buffer when required, but it was implemented somewhere in the Nut OS and little could

be found about it. The alternative was to look at the problem on a functional level. The

solution was to have the server program place a song gap identifier at the start of the

new MP3 song when a stop, next, or previous command was received. This was

implemented by simply sending “GAP” across the MP3 stream just before the first

packet of new MP3 data was sent, as shown in figure 23.