Writing background media apps that conserve power (HTML)

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

Introduction

New for Windows 8 is the always on always connected (AOAC) power model. This way your apps consume very little power while still being connected and responsive. This new low power state is referred to as connected standby (CS). A goal for this state is to enable low power audio playback so that background media apps can play for many hours on a single battery charge.

To reach the power goals for connected standby, the network connection must enter a low power state. This means that a background audio app can't access the network at will. Microsoft Media Foundation sources can still play networked content, such as through an HTML5 audio tag, from both network file locations and streaming media if you use inbox sources. But if an app needs to talk to the network for any other reasons, such as for license checks, metadata, or user statistics, you need to do some extra work.

These requirements apply only to apps that play audio in the background. For more info on background audio playback see How to play audio in the background.

How to access the network

There are three ways for a background audio app to access the network:

1. Background transfer API. This is the best option. Simply make your additional networking calls through the background transfer API as a file upload or download. All the work to bring the network up and down will be done for you. For more info, see Windows.Networking.BackgroundTransfer.

2. Wrap an existing MF bytestream. The background transfer API are designed for file transfer and may be too heavy handed for small, quick network communications. When an Media Foundation source or bytestream is instantiated, Windows takes a network reference on its behalf. This applies to custom Media Foundation sources and bytestreams too. A completely custom source or bytestream is quite complex, to simplify the problem, you can wrap inbox bytestreams. After initialization, the app can use the network as necessary using any networking API. When finished with the network, the wrapper initiates use of the inbox bytestream. The inbox bytestream in turn shuts off the network when it is done.

   For a custom source example see the Real-Time Communications Sample.

   For an example on how to communicate between an app and a source see the Media Stream Source Sample.

3. Fully custom Media Foundation source or bytestream. This is similar to option 2, but instead of using any inbox components, the developer writes the entire Media Foundation source or bytestream. In this case, it is your responsibility to notify Media Foundation when it is done with the network by issuing characteristics change. The figure shows an example flow.

   • See option 2 for custom source samples.
   • For bytestreams, you must set MFBYTESTREAM_DOES_NOT_USE_NETWORK = 0x00000800 flag and the MEByteStreamCharacteristicsChanged event must fire.
   • For sources, you must set the MFMEDIASOURCE_DOES_NOT_USE_NETWORK = 0x80 flag and the MESourceCharacteristicsChanged event must fire.

Here's an example of a two song playlist using either option 2 or 3.

If none of these solutions can work for your app, contact lpa_questions@microsoft.com. Please detail your exact use scenario and why the above options cannot work for you.

Other considerations

In addition to making sure your app accesses the network properly, there are a few other considerations for a low power audio app. Because the app can run when most of the system is suspended, you must keep power needs in mind while you develop the app. Using visibility change notifications (this will occur both when the app is in the background and when the device enters CS) as a hint, put the app into its own low power mode.

• Don't perform any UI updates. If the app is not visible, anything graphical or UI related uses power unnecessarily.
• Reduce work where possible. This ties in closely with the UI updates. If something is not necessary except when a user is present, it doesn’t make sense to do it when the app isn’t visible.
• Batch network communications. The longer the app can go without significant CPU or network use time, the better.
• When in connected standby, operations may take longer. The app gets throttled when in connected standby and has only a limited amount of time to run on the CPU.
• To help insure the best audio resource usage, you should limit the number of audio tags that are used in your application to only one or two simultaneously (this includes tags that may be initialized but not actively playing).