Specifications

recovered nearly immediately so it was close to being fast enough. At this stage it was

decided to change from using a 128kbbs test file to a larger 192kbbs test file. This was

so that if development time was being spent trying to get the network speed right then it

has to be fast enough to play all bit rates. In experimenting to try to find a little bit more

speed, it was found that changing the TCP packet size now had quite an effect on the

speed of transfer. It was found that the optimal packet size was 1.5Kbytes. Any smaller

or larger and the speed began to drop off. This was determined using the network

monitor in Windows XP, and at the 1.5K packet size the network utilization of the

10mbit connection got up to 3% or about 40kbytes/sec. At this point, the 192kbbs MP3

was now playing without emptying the buffer.

5.3.7.2 Removing clicks from the playback

It was now able to play while keeping the buffer from empting, but it still had persistent

clicks every now and then. The obvious reason was that the MP3 decoder was being

given data that was not a part of the original MP3, and the obvious place for this was at

the loop of the ring buffer. To test, every time the buffer was looped back to the start an

indicator was sent to HyperTerminal. When the indicator appears the click appeared

very shortly after. Remember from earlier that the buffer was filled by the TCP receive

function. This function was passed the current receive pointer and placed data on from

this point. When the receive function was finished the pointer was incremented the

number of bytes received. A check was then done to see if this pointer went past the

address space allocated to the buffer and if so, it was reset to the start of the buffer. The

transmit buffer would do the same, except one byte at a time would be sent to the

decoder and after each byte it would be determined if the pointer is past the end. This

creates two problems: the first is that the receive pointer can go well past the end of the

allocated space before it gets reset because it gets incremented by the number of bytes

received, whereas the transmit pointer will get reset as soon as it reaches the end

because it gets incremented one at a time. This means that the transmit pointer will

never get to the data that the TCP receive function puts after the allocated space. The

solution to this was to create a variable that stored the memory address the receive

pointer reached before it was reset: the flip pointer. The transmit pointer could now use

this value to determine when it should be reset and therefore, reach the end of the

receive data. The result of this was that the audio still had clicks but they were not as