Share via

Writing a network audio driver in Windows CE – Part 5 - Power consumption

  • Article

Writing a network audio driver in Windows CE – Part 5 - Power consumption

            This blog will discuss power consumption, the fifth bullet point in my first blog about networked audio drivers. This is mainly a concern in portable devices using wireless networks, where battery life is important and wireless radio power consumption is usually significant.

In an audio driver that plays directly to local hardware (local audio driver or LAD), typical distribution of power consumptions is in:

· Higher CPU load to process audio from storage to output:

o If audio data is encoded, decoding audio data;

o General processing of audio data in the driver.

· Disk, reading audio data from storage source:

o Spinning/seeking/reading in a hard disk;

o Reading from flash memory.

·   Audio hardware, playing back the reconstructed audio signal to:

o Headphone jacks;

o System speakers.

These activities generally consume a little extra power, optimization from the driver behavior is usually not needed, and this extra power usage ceases when the playing of the audio is done.

For a networked audio driver (NAD) all of the above, with the exception of the outputting the audio signal to hardware, still apply. In addition, there is power used to send data over the network to the remote device responsible for playback (the sink). In a wired network, there is usually little or none extra power involved in sending data through the network. The wireless case is more interesting, since the cost of having a wireless (i.e. Bluetooth, 802.11) radio on is usually fairly high. Moreover, wireless radios usually have varying levels of power consumption depending on what mode they are on .

For an example of how this can create non-trivial design decisions, when a user requests to play a track, if the source and the sink side don’t have an active connection, a NAD might have to negotiate a connection with a sink device before it starts playing the track. Establishing this connection consumes some power and takes some amount of time, thus adding some latency between the time when the user requests a play to the data actually getting played in the sink side. If the connection is already up, the data can be sent over the network right away without the delay for connection setup, but there is generally some cost involved in keeping the connection up. After the track is done playing, for how long should the connection be maintained (possibly not allowing the wireless radio to go into a lower/no power consumption mode) considering the user could potentially request that a new track be played soon after the initial one is done? The answer to that question is implementation specific, but can follow from:

· How much power is saved by disconnecting the connection;

· How likely is the user to request that a sound be played again;

· What kind of user experience the driver should be optimized for;

· What the underlying hardware is, and how it behaves in relation to power consumption (for example, certain Bluetooth radios have power save modes built into hardware that are automatically activated and transparent to upper layers).

[Author : Thais Melo]

Comments