Writing a network audio driver in Windows CE – Part 3 - Bandwidth

  • Article

            This blog will discuss bandwidth, the second bullet point in my first blog about networked audio drivers.

            In an audio driver that plays directly to local hardware (local audio driver or LAD), bandwidth is usually not a concern since it is only dependent on internal components (disk bandwidth, bus speed, processor speed, DMAs, etc) which provide more than enough bandwidth to play music, is well known and rarely varies.

A networked audio driver (or NAD) on the other hand sends packets down the network stack it is using, which then go over some medium to a different device, where it gets played. So it depends in local bandwidth (above paragraph) and network bandwidth. I will from here on only discuss network bandwidth.

Networks can only send a limited amount of data, usually have more than one user and are used for more than one purpose. This means that using network bandwidth efficiently is important. One way to do so is to compress the music being transferred in a format that both the source and sink understand. The decision on what type/amount of compression to use could be:

  • fixed (registry setting or hard coded in both source and sink);
  • made at connect time during a connect handshake or some other connecting mechanism;
  • made during streaming if compression type/amount needs to change.

            A NAD using a network where the available bandwidth may vary should also be designed to adapt to those situations. For example, on a wireless medium, bandwidth decreases if there is noise in the channel or distance between source and sink increases. In both wired and wireless mediums, if other users/applications are using the network, the bandwidth available for the NAD decreases. As mentioned in the timing blog, one possible solution is to decrease the bit rate of the audio data being streamed. Another solution is to temporarily stop streaming until there is again acceptable bandwidth and possibly notify the user in some way. If real time behavior is expected, simply streaming the audio data at a lower bandwidth than required will create poor user experience (depending on the sink implementation, it could create skipping, playing the data at an incorrect rate, etc).

 

[Author: Thais Melo]