Streaming audio is a content which is sent in compressed form over the internet and displayed to the viewer or end user in real time. As we discussed before that the audio or video file which streams actually it downloads the data in packets or frames (of Bytes) and with streaming audio or video file the user does not have to wait to download a file to play. Instead the data is sent to user in continues stream in form of frames or packets as it arrives. Rather the data is in compressed form so we need a player or plug-in which uncompress the streaming file and then sends to the user after that it will be able to play the data. Such players decode and display data, and they usually retrieve information a little faster than they play it. This extra information stays in a buffer in case the stream falls behind. The data sends from sender but it is in compressed form so we need to uncompress the data to make it able to play, so it passes through the streaming engine where it uncompress the data and generate the data in packet form (in bytes). (Figure 1) Then it sends to the medium where it decides where to response the request and then it sends the packets data to the receiver where data downloads in packets (buffers) and display to user where it can play a buffer file.
Streaming engines transmit media from resource location to one or more destinations. Traditional audio streaming systems fail to support high latency buffering or heavy compression. In contrast, life performance streaming uses small buffers and no compression to minimize latency. Streaming engine provides a format conversion component to enable audio transmission but this introduces additional latency. Using small packet size means waiting less time before sending the current packet. This increases the number of transmitted packets and packet rate which can have negative effects on performance. (Figure 2)
In streaming engine to source stream sends data in packets where the latency and interruption is occurring in which some byte packets sends accurately while some missing means latency occur and some get interrupted means noise occur in this packet destination so basically causes of effective packets are latency and interruption which is shown in figure 2.
Streaming in audio and video file is done in form of bits as the first or some of the bits download the file in buffers and then it becomes able to play (Figure 3). Like on web a media player may download first 10 seconds or few packets (in bytes) of file then it stores or buffers it and then starts to play. After playing this part when it reaches to the last bit of first part, downloading of next 10 seconds will start. Here the bits are known as packets. Each packet is independently addressed and travels separately and different packets can travel by different routes.
Figure 3: Audio/Video files streaming
In figure 3 it is shown that the packets or frame (Bytes) 8 bytes of each packet is travelling in both these files. So in this figure the audio and video file is streaming together where audio and video frames are together in byte by byte sequence.
On receiver side buffering component is responsible for ordering received packets. This is done by placing a data in a queue from which samples are passed at regular intervals. Sound source can be duplicated and recorded using multi channel recorder. Every channel is recorded simultaneously so the resulting audio file allows offline comparison of audio quality and temporal differences.
Quality of video is affected as Lost and damaged packets are not resend.
The media player actually never stores more than a little bit of the entire file. Once the downloaded part is played it will be deleted to free up the bits for the next part to download which will be played next
If we see numeric values in bytes how occurs then here is the example that how bytes represent in PCM domain. Suppose a frame of MP3 stereo audio data in the PCM domain is 5632 (= 352*2*2*2*2) bytes and every PCM sample is represented in 2 bytes. However, after going through the filter bank, the frequency domain coefficients require a floating point representation (float or double in C language), which is typically represented in 4 bytes of float or 8 bytes of double. That means we need 45056 (= 352*2*2*8) bytes to store a single frame of data in the MDCT domain, which is a factor of 4 in comparison with PCM data.