Specifications

5.3.7.1 Speeding up the network transfer

Small changes to try to optimize the code were made while monitoring the buffer size

that was being output to HyperTerminal. Changing the TCP packet size and shortening

the delays in the decoder interface made next to no difference to the speed; the buffer

emptied. After spending time making minor design changes, it was decided that a major

change was required. To solve the problem outside help contacted (Harald Kipp [20] the

person who designed the Ethernut OS and TCP stack). After contact via e-mail and

discussion of the design he noted that the problem could be that the TCP data was being

read through a SoStream device. Early in the design phase, it had been decided to use

the SoStream device because it was convenient. Harald Kipp advised that using the

SoStream requires much more processor time allocated to the operating system and is

hence much slower. The alternative is to simply use the NutTCPReceive function,

which performs a blocking receive on the socket. The program was modified to use

NutTCPReceive instead of reading from the SoStream nut device. The NutTCPRecieve

function is passed the current position of the receive pointer in the buffer. When the

receive function is finished it returns the number of bytes received and the pointer to the

buffer is incremented by this amount. The tests of this were an instant success. The

player filled the buffer and triggered the first interrupt and it then began to play music

without the buffer emptying. The change was dramatic. Instead of empting as soon as

the music started, the buffer only dipped in size when the music started and then stayed

about full through the song.

There was still one problem though: the sound was constantly being played but was

being played at half speed and there were loud clicks periodically. The half speed

playback had to be a problem with the configuration of the decoder, because the

function supplying the MP3 decoder did not signal that it ran out of buffer. After a little

research into how to configure the decoder, it was found that the configuration register

was set to use a 24.576Mhz crystal when is was actually connected to a 12.288Mhz,

explaining why it was playing at half speed. After setting the configuration register to

use the internal clock doubler, the audio now played at normal speed. This created

another problem: now that it was playing faster than before, it was using the buffer up

faster and the buffer started empting again. The buffer emptied quite slowly and then