Writing a network audio driver in Windows CE – Part 1
[Updated to reflect status of other parts of this blog]
In this series of blogs I will discuss the implementation of an audio driver that starts from the wavdev sample and streams audio over a network in real time. In part 1 I will list the main things that one has to worry about only when writing a network audio driver, and I will discuss each bullet point listed below in further blogs (parts 2 through 6) that will be posted in the date mentioned in the bullet point. If there is anything in particular that I listed (or didn’t list) that you want to see described in more detail, please let me know.
While there are multiple ways for writing an audio driver for Windows CE, probably the easiest way to get started is using the sample driver code provided with Windows CE.
For more information on the sample driver please see:
Starting from the wavdev driver most of the upper layer work is done, meaning only hardware specific changes need to be made. Please note that this is only sample code, and as the documentations suggests, you are encouraged to change the sources in any part of the code to fit your needs.
In an audio driver that plays to headphones or speakers, usually all the hardware specific layer does is write to certain hardware buffers obeying hardware interrupts. Audio drivers that write to a network are slightly different in that they write to a network buffer that then gets sent down the network stack and over some medium to a remote device.
Some important differences for network audio drivers, which I will treat in more detail in future blogs:
· Timing - There are no hardware interrupts, so either the driver or the network layers below it, must be able to throttle the speed at which data is sent to avoid overrunning the buffers in the receiving side, the buffers on lower layers of the network stack or the network itself. Further details in Part 2 – estimated post date 10/17/05.
· Bandwidth - Most networks can only send a limited amount of data; this means sending raw high quality PCM data might not be acceptable. The driver might need a mechanism to figure out how much data can be sent over the network and in which format can it be sent (which formats does the other side understand). Further details in Part 3 – estimated post date 10/24/05.
· Latency – Latency in hardware is usually very low. When transmitting data over the network this can increase significantly. Also, in general, buffering data and sending in large chunks improves bandwidth but increases latency. Further details in Part 2.
· Transient Errors – Certain networks can lose packets, it is important to consider if this is acceptable. Also, wireless networks can have their bandwidth decreased by noise or close to out of range situations; if using wireless networks are being used it is important for the driver to be able to cope with this situations. Networks can also be temporarily disconnected, thus the driver needs to be aware of disconnections/connections, and the correct actions to take in such cases. Note that most audio frameworks do not deal with this type of errors graciously because they where in general designed for writing to local hardware, where transient errors are extremely rare. Further details in Part 4 – estimated post date 11/14/05.
· Power consumption - This mostly only applies to portable devices, especially to if the driver is using wireless networks. For instance, design decisions need to be made to when to connect and disconnect to the remote device when the driver is idle or back in use. Further details in Part 5 – estimated post date 11/28/05.
[Author: Thais Melo]