An overview on how the client/server audio streaming architecture works is available, but essentially all it says is that as a result of the user clicking on a relevant link, the client software, called RealPlayer, contacts the server software with a request for the audio asset to be played and the server software responds by sending a stream of compressed audio which the RealPlayer then decodes and plays as it arrives.

A more technical discussion of how the system works is available also.

A variety of delivery rates and qualities are available, and naturally network congestion has a very large impact. We tested delivery across the internet from example sites provided by Progressive Networks, connected by a shared ethernet LAN, and played 16Kbit/s audio with quite acceptable results. At that rate, sound is only voice quality. Dropouts did happen, but they didn't distract too much from the content, which was a lecture on bio-diversity. Occasionally, we heard a strange echo effect, apparently caused by the network, and there was a hissing in the background.

A different test, listening to 16 Kbit/s music from the same site also proved unsatisfactory, as the quality was too low for that application.

Using a free audio encoder for a test with our own source, which was a 500 Mbyte, 2minute long, 8 bit unsigned mono wav file sampled at 22kHz, we produced a 500 Kbyte RA file that delivers at 16 Kbit/s. (A compression ratio of 10). At this rate, the audio quality is acceptable for speech, and distortion caused by the compression is not great. Higher rates are available for better quality, at lower compression.

Summary

• Live and pre-recorded audio streaming.
• Audio file compression.
• The transport protocols used are TCP and UDP.
• The compression algorithm used is proprietry and varies for different delivery rates and sound quality.