In an audio driver that plays directly to local hardware (local audio driver or LAD), the audio is usually sent to hardware in fully decoded (PCM) data mode and errors are rare and usually permanent. Thus most audio frameworks are designed with such assumption built in.
In networks however, transient errors are common and expected. For instance, most networks can lose packets. Certain networks can re-order packets. Networks can also be temporarily disconnected. Wireless networks can have their bandwidth decreased by noise or close to out of range situations. Thus networked audio drivers (from here on NADs) need to be aware of the situations above and handle them graciously:
· If lost packets are possible/expected:
o As mentioned in the bandwidth blog, to save bandwidth, a compression method might be used by a NAD before the data is sent over the network. This compression method should be chosen carefully to assure that if a packet is lost, all (stateless compression) or most of the data that is not lost can still be decoded.
o If packets are being lost often due to network saturation, action might be needed from the NAD to avoid consistent sound degradation. This case is equivalent to diminished bandwidth, and is treated in that entry.
· Packet re-ordering:
o If packet re-ordering can happen in the network, the source side should have a time stamp mechanism so the sink side can determined in which order the packets were sent.
· If temporary disconnections are possible/expected:
o Particularly in wireless networks, the sink and source sides might not be permanently connected due to power concerns. If a request to play audio is made, a connection might need to be started. The driver could do this transparently (connection started when the user hit play on a song for example) or ask the user to connect if currently disconnected.
o If the sink becomes disconnected in the middle of playback, the NAD should behave graciously, possibly warning the user about the error and stopping playback.
[Author: Thais Melo]