Background Audio on Mobile Devices

Abstract

The subject disclosure is directed towards a technology in which a mobile device service plays background audio as instructed by a third party audio player application. The service continues to play background audio after the audio player application is deactivated from the foreground, e.g., as another application becomes the foreground application. Also described is launching agents to obtain additional information and/or to handle custom audio formats, and handling of user requests from a universal (system) volume control or the audio player application (when in the foreground).

Description

BACKGROUND

Contemporary mobile devices are used for many types of user applications, including running interactive applications and listening to music or other audio (e.g., broadcasts). Audio output is generally something a user often wants to have performed in the background, e.g., after setting up a playlist or other audio content, the user wants to be able to listen to the audio while still being able to use the device features and/or perform other foreground tasks.

To implement a background audio scenario, the system needs to let a process run in the background and play audio. Current solutions have one or more issues with such a scenario, including consuming too much battery and/or other system resources, providing poor (if any) integration with the system user experience/interface (UX), and/or the possibility of introducing a security threat to the system. Further, playback may stop unexpectedly due to resource depletion.

As a result, one solution is to use a where “first party” application as the background audio program, (where as used herein, “first party” generally refers to trusted code such as provided by the operating system vendor, and “third party” refers to applications from vendors, regardless of their source or trustworthiness). However, this limits the device system to not allowing third party applications to perform background audio playback and provide different user experiences, while consuming resources for the first party application, and so forth.

SUMMARY

This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.

Briefly, various aspects of the subject matter described herein are directed towards a technology by which a media service plays audio in a background process on a mobile device, as initially directed by a foreground (e.g., third party) application. The application, when in the foreground, communicates via an interface with the media service, including to provide information to the media service that corresponds to audio data (e.g., an audio track) to play. The media service plays the audio, and acts upon requests directed towards the audio playback as the media service plays the background audio.

For example, the requests directed towards the audio playback may correspond to user actions, such as play, pause, skip, stop, skip next, skip previous, seek, fast forward, rewind, rating-related actions, shuffle and/or repeat requests. The requests directed towards the audio playback may be to provide state information, such as playing, paused, stopped, fast forwarding, rewinding, buffering started, buffering stopped, track ready and/or track ended state.

In one aspect, the media service operates to launch an agent that provides the requests directed towards the audio playback. The foreground application may be deactivated, with the media service continuing the audio playback in the background. The media service may cause the agent to be re-launched as needed to obtain additional audio information, e.g., more tracks to play.

In one aspect, a universal volume control (e.g., system) component provides requests directed towards the audio playback. The application (when in the foreground) may provide information that determines the operation of the universal volume control component. The media service provides information that may be presented on a user interface of the universal volume control component, e.g., text (title, artist), images and so forth, such as obtained from the application and/or agent.

In one aspect, a source agent may be configured to output audio data that the media service processes into the audio playback. The source agent may use a (e.g., custom) codec, decryption mechanism, decompression mechanism, and/or a proprietary protocol to provide the audio data. The source agent may output the audio data to a shared memory for processing by the media service.

The information that corresponds to the audio data to play may be associated with a control flag that indicates via attribute settings whether the media service is allowed to take a particular action with respect to the audio playback. For example, the flag may include attributes that allow/deny skip next, skip previous, fast forward, pause, and/or rewind actions for any media item that is playing or queued to be played.

Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:

FIG. 1 is a block diagram representing example components for playing background audio, including when an audio playback application is deactivated from the foreground.

FIG. 2 is a block/control flow diagram representing example components for playing background audio, including when the audio is originally in a non-native audio format.

FIG. 3 is a block/control flow diagram representing example operations to prepare for and play background audio.

FIG. 4 is a block/data flow diagram representing example data that may be communicated to prepare for and play background audio.

FIG. 5 is a block diagram representing an exemplary non-limiting computing system or operating environment, e.g., in the example of a mobile phone device, in which one or more aspects of various embodiments described herein can be implemented.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generally directed towards a technology in which a mobile device or the like includes a background audio service. To play audio, an application (e.g., third party application) sends a request via the background audio service to a media service, which performs the playback. By providing a system service rather than allowing an untrusted application process to operate in the background, more security and stability are provided, with a known amount of impact on the system, while allowing third party applications to direct the background audio playback and playback-related operations.

It should be understood that any of the examples herein are non-limiting. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and mobile devices in general.

FIG. 1 is a block diagram showing various components in one example implementation. In general, a media service 102 plays back audio tracks as directed by a third party application 104 in conjunction with a player agent 106 (e.g., a “headless host” having no user interface) as described below. Communication between the application 104 and/or player agent 106 and the media service 102 is via a background audio service 108 (BackgroundAudioPlayer) that includes an API set.

The background audio service 108 supports basic playback and a custom codec mode. The playback mode can help the device save battery, and makes coding of the application relatively simple. In the custom codec mode, described below with reference to FIG. 2, an application can perform more powerful operations, such as support proprietary DRM (digital rights management) or proprietary codecs.

In one implementation, the application 104 calls into the background audio service 108 with a request to play audio. The media service 102 is notified, which in turn communicates with an application instance manager 110 (a system service) to launch the player agent 106. The communication between the media service 102 and the application instance manager 110 requests that resources be reserved for the agent 106, and notifies the application instance manager 110 that the player agent 106 is a time-critical resource (so that in typical operating circumstances, the resource is not subject to interruptions that if present provide a poor user experience). In general, the player agent 106 is independent of the application 104, as either one may remain operational while the other is not, both may operate at the same time, or neither may be operational at a given time.

In one implementation, the player agent 106 makes the actual playback requests and other playback-related requests (e.g., skip, rewind and so forth) on behalf of the application 104. This allows the application 104 to be removed from the foreground and so forth. In an alternative implementation, the requests may be shared between the agent and application, with the application choosing which requests it keeps for itself, and which are delegated to the agent, for example. Note that having a player agent be responsible for handling requests provides an advantage in the requests may originate via the application or other system services, and thus there are no conflicts, and the user may use the system even after the application has been terminated or otherwise deactivated.

In general, the media service 102 via a media service proxy/translator 112 notifies the application instance manager 110 on various events, such as on a user action and any play state change; (note that the media service proxy/translator 112 alternatively may be incorporated into the media service 102). Example user actions include play, pause, skip, stop, skip next, skip previous, seek, fast forward, rewind, rating-related actions, shuffle and/or repeat. Example play states include playing, paused, stopped, fast forwarding, rewinding, buffering started, buffering stopped, track ready and/or track ended.

Each time the media service wants to communicate with the player agent 106, the media service 102 instructs the application instance manager 110 to re-launch the player agent 106 if needed; note that this allows the application instance manager 110 to leave the player agent 106 in memory if desired, to put the player agent 106 into a dormant state (retained in memory but unable to run code until activated), or fully terminate the player agent 106 and re-launch an instance as needed. Once notified, the media service and the player agent 106 may communicate (via the background audio service 108) to perform further actions, such as to request a next track, notify the agent that the user has performed some action related to audio, e.g., by interfacing with the application 104 or a system-provided UVC (universal volume control) 114, and so forth.

Also shown in FIG. 1 is background audio support/integration with existing and future operating system user experiences, including UVC (universal volume control) 114 integration, a native first party player 116 (Zune®) experience, and integration with a program 118 via an XNA/Silverlight™ environment 120. To this end, XNA and Silverlight® may use a native playback API to perform audio playback, and media service playback coordinates the request from Silverlight® and XNA. This design enables application to use both XNA and Silverlight® code in one process. Other aspects include a “Nowplaying” token, phone call interruption, and others.

It should be noted that the mobile device may output the audio in any suitable form. For example, the mobile device may output the audio via internal speakers, via a headphone jack to a headset, via wireless or wired communication to another device (e.g., over Wi-Fi to an external sound system), and the like. The media service 102 may be considered as providing input source information to a sink.

FIG. 2 is a block diagram showing an alternative configuration, including a control agent 206 and a source agent 222. The control agent is similar to the player agent and is not described again. The source agent comprises a code/logic that is configured to support a non-natively supported media format, such as streamed or progressively downloaded from an associated source. The source agent 222 may be provided by an internet audio service, music service or the like, and in general is configured to handle decryption of encrypted content, decompression of compressed content, decoding of custom encoding formats, custom protocols, and so forth. A source agent may handle one or more such custom formats and the like. Unlike the player agent/control agent, the source agent 222 is needed to remain operational to provide the properly formatted content, and thus is not deactivated by the application instance manager (except possibly under extraordinary circumstances).

As represented in FIG. 2, an application 204 makes a request via the background audio service API to the media service 102 to play content, as represented by the arrows labeled (1a) and (1b) in FIG. 2. In turn, the media service 102 communicates with the application instance manager (the arrow labeled (2)), including to reserve resources and launch a control agent 206, similar to as described in FIG. 1 (but without a proxy/translator shown). The control agent 206 is launched as represented by the arrow labeled (3).

When launched, the control agent 206 makes requests to the media service 102 (arrow (4)), including a request for a particular source agent 222. The source agent may have been previous loaded into the device and maintained thereon, or downloaded on demand. As represented via the arrows labeled (5) and (6), the application instance manager launches the source agent 222.

The source agent 222 requests that the media service play a track (arrows (7a) and (7b)), informing the media service 102 that the source agent 222 will provide (e.g., stream) the properly formatted content. The source agent responds to the control agent 206 that the track is ready (arrows (8a) and (8b). The source agent 222 provides the properly formatted audio content (arrows (9a) and (9b) to a playing component of the media service 102, (DShow 226, incorporated into or coupled to the media service 102). In one implementation, the audio content is buffered via a shared memory 228, which is efficient as further data transfer/copying is avoided.

As can be seen, in a basic playback mode as in FIG. 1, the application 104 may implement a playback experience by sending a track (e.g., a uniform resource identifier/URI or such as an HTTP URL) to the service 102 and asking the service 102 to play it. The service 102 is responsible for parts of playback (reading/downloading/streaming content, parsing container formats, content decryption, audio stream decoding, and so forth).

In a custom codec mode as in FIG. 2, the application 204 in conjunction with the source agent 222 acquires the content via any arbitrary mechanism (such as downloading, streaming, reading from a local store, or dynamic generation such as for text-to-speech) and performs arbitrary processing as needed, such as decryption or decoding, before passing it to the native service. Because the shared memory 228 may be used to pass content, significant memory may be saved with improved performance relative to copying decoded content into another memory buffer. This design also enables ISVs (independent software vendors) to protect their content licenses more easily, e.g., by providing corresponding source agents, possibly along with the applications.

Turning to another aspect, as described above the device system provides a UVC 114 control/user interface by which the user is able to control audio playback independent of the application 104 or 204. In general, at any desired time, the user presses a hardware button to bring up the UVC 114 control/user interface.

Note that in one implementation, when the application 104 or 204 is in the foreground, the application may disable, limit or otherwise integrate with the UVC, such as to show its controls instead of or in addition to the UVC's controls, add text or images (e.g., album art) to the UVC user interface, and so forth. The background audio service API 108 enables an application to implement its own logic when it receives user interaction. User interactions with the UVC system user experience (such as skipping a track) are handled by the application. Applications have the opportunity to disable/enable the UVC playback control button, and/or change song metadata such as title, artist, and album art.

To this end, the media service 102 sends notifications to application foreground code, first party background code 116 and the UVC 114 when the playback state changes or other pertinent events occur to ensure the components have the correct metadata and playback status. For playback position, the application is able to query the background service. This notification design enables applications, the UVC 114, and the first party player 116 to obtain correct playback status and metadata, without introducing significant, unnecessary cross-process traffic.

When the application is in the background, the user may interface with the audio via the UVC 114. For example, the user may increase or decrease the volume, pause the track, skip the track and so forth. The media service 102 is instructed by the agent (or application) via a “Nowplaying” token or the like as to what may be displayed on the UVC user interface, e.g., text (title, artist, album name and/or the like), an image, a logo, and so forth. The UVC 114 communicates (e.g., directly) with the media service 102, including to subscribe to status changes (e.g., playback changes, such as play/pause/stopped play states as well as item changed (track switching) notifications, whereby UVC pulls the relevant data, such as title/artist/album from media services for display) and the like. Via the application/agent, the media service has information on what is playing now, and when the track changes, will instruct the UVC 114 to update the title (new track name). If the media service queues multiple tracks, the application/agent need not be involved until the queue needs to be updated/changed. Note that in one alternative, instead of sending a single track to play, the application/agent may send a playlist of multiple tracks. This may be more efficient, to avoid communicating with (including possibly launching) the agent for each new track.

Further, each media item (e.g., audio track) is associated with attributes in a media control flag that the application/agent may set, and which control what the UVC 114 is able to do with respect to a track. For example, the application may specify that a track (such as an advertisement, for example) cannot be skipped. Another application may let a user skip some limited number of tracks before having to listen to one fully, before again allowing skipping. In general, the media control flag includes attributes to allow/deny skip next, skip previous, fast forward, pause, and rewind.

Turning to integration with the device's telephone, when there is incoming call, the media service is notified. In one implementation, the background music volume is decreased, and a ringtone sound is audibly mixed with the background music. A user may configure the relative volume levels. If user presses ‘ignore’, the ringtone stops and the background audio will continue playing, e.g., at its previous volume level. If a user answers, the audio is paused (if allowed by the media control flag, or silenced if not, for example). Thus, the mixed audio output signal and ringtone continues until the call attempt ends in some way, e.g., is ignored (by explicit user action or until the call attempt terminates) or is answered (by the user or automatically). When a user-answered call ends, the audio resumes playing.

FIGS. 3 and 4 along with the following brief scenarios illustrate how third party applications can use the managed background audio playback API. For simplicity, assume that HTTP URLs are the URI of choice in the following examples. To this end, FIGS. 3 and 4 show basic building blocks and a data/control flow of a scenario for media playback. Note that as shown, the application 304 and agent 306 have their own isolated storage 330, and the media service has its own data store 332, which may include a queue. The following labeled steps correspond to the circled numerals in FIG. 3:

1. Application creates service request (“play this track and call me back when you need the next one”)

2. Service starts playing the track

3. User closes application

4. Current track ends

5. Service asks system to call the agent to get the next track

6. System starts new process and invokes the agent

7. Agent performs logic and provides the next track information

8. System suspends or kills the agent

9. Current track ends . . . (back to step 5)

For third party application background audio playback, the application 304 operates to contact its servers on the web 334. This typically includes authenticating the user and retrieving any user data. For this example, assume the content to be played is represented by an HTTP URL that points to some server. When the application 304 decides that it is time to begin playing music, the application may perform the following example steps:

1. Create an instance of the background service 108 (including the API set).

2. As part of its initialization, the background service 108 calls the media service 102 to create a queue for the application 304. This call creates the queue if one does not already exist for this application.

3. The application 304 checks to see if the background audio service 108 has a current track. (For this example, assume there is not already a queue)

4. There is not a current track, so the application 304 performs its operations to get a track from the server (which may include authenticating the user, and so forth).

5. For this example, assume the server returns a HTTP URL that points to the track to play.

6. The application 304 creates an AudioTrack object (or other suitable data structure), passing in the URL, track name, and any other metadata as desired.

7. The application 304 passes the new AudioTrack object to the background audio service 108 via an appropriate function call.

8. The background audio service 108 creates a new media item via an appropriate function call.

9. The background audio service 108 queries the given AudioTrack for the URI which it sets on the item.

10. The background audio service 108 adds the track to the media service/queue.

11. The application calls the play function of the background audio service 108.

12. The background audio service 108 initiates playback by calling the media service.

13. The application receives events it is interested in.

14. Shell tells the application it is closing.

15. The application destroys its background audio service 108 object, and the media service continues to play the track.

Resuming playback (persist playlist queues) is another scenario. A user may tap on the power button to turn the screen on. Without unlocking the phone the user may push the volume up key to bring up the UVC, and taps the play button and the station corresponding to the application starts playing again, e.g., the same song where it was stopped earlier. The following is an example:

1. The agent receives an “OnUserAction callback.” This callback's parameters provide a reference to the current track, with the action being “Play”. Assume that there is no current track because the queue was destroyed at some point.

2. The agent notices that there is no current track, whereby the agent goes to its persistent store to read in the title, source, and position of the last track it played.

3. The agent creates a new AudioTrack and sets the metadata accordingly.

4. The agent sets where the audio is to resume by calling a “progress” function of the background audio service 108, e.g., “BackgroundAudioPlayer.Progress.”

5. The agent passes the new AudioTrack object to the BackgroundAudioPlayer.

6. The agent calls background audio service 108.

7. Playback resumes where the user left off (assuming that the track is still available on the service).

Resuming applications (get queue state) is another example, where a user decides to double-check a song title that he or she cannot remember via the application. The user unlocks the device, navigates to the application list, and taps on the application icon. The application launches and displays the currently playing artist and the current song playback time counter. An “Events” label may be selected, which for example shows that a concert with the artist is upcoming. The following is an example:

1. The application creates an instance of the background audio service 108.

2. As part of its initialization, the background audio service 108 checks with the media service to see if there is already an application queue.

3. The media service reports that there is a background queue for this application.

4. The background audio service 108 retrieves the media item value for the currently playing track and creates a new AudioTrack object that contains the media item value.

5. The application checks to see if there is a current track, which in this example there is.

6. The application gets the current track and queries for the title.

7. Because this is the first metadata query, the AudioTrack object reaches the media service and obtains the available metadata. Then it returns the title.

8. The application calls a function (BackgroundAudioPlayer.PlayState) to get the current play state (Playing).

9. Because the content is playing, the application calls a function (AudioTrack.Duration) to get the track's duration.

10. The application calls a function (BackgroundAudioPlayer.Progress) to get the current position.

11. The application updates its UI with this information.

Switching playback between applications also may be performed. While a song/station is still playing via the previous application, the user may navigate into the first party media player (e.g., Zune®) application, for example, and taps on podcasts. The user taps the play button next to a new episode, causing the previous station to automatically stop playing and the new podcast playback to start. The podcast plays for a while, until the user decides to tune into other radio content. While the previous podcast is still playing, the user navigates to the application list and launches a different application, where the user finds a desired radio station and taps the play icon. The podcast automatically stops playing and the user now hears the desired radio station. The following is an example:

1. The original background audio agent receives the save-related (On PlayStateChanged/Shutdown) callback.

2. The original background audio agent grabs the current track from the given background audio service instance and saves off the title, source, current position, and so forth. It saves these values in its isolated storage 330.

3. To free up resources, the original background audio agent calls a function of the background audio service (BackgroundAudioPlayer.Close) which instructs the media service to delete the application's queue. Note that in the event that the original background audio playback was stopped due to the user playing a different media, the media service frees up the resource for the original application/agents as part of the Shutdown.

Playlist control (skipping) is yet another desirable feature. A user begins streaming music, and then goes into a Games hub to select a game, for example. After a few minutes of playing the game, an undesirable song is played; while in the gaming application, the user taps the volume up button making the UVC controls appear. The user may then tap the skip icon to move onto another song. The following is an example:

1. The audio background agent's OnUserAction callback is fired. The UserAction enumeration is set to SkipNext.

2. The audio background agent calls an internal method or the like that determines that the user is allowed to skip the current track (e.g., based on the company's business model/rules).

3. The audio background agent queries the web servers for the URL of the next track to play.

4. The audio background agent creates a new AudioTrack object and sets the URL and other pertinent metadata.

5. The audio background agent uses the background audio service's object that was also passed in as one of OnUserAction's parameters to set the new AudioTrack as the new current track. This action causes the currently playing track to stop.

6. The audio background agent calls Play to begin playing the new track.

Exemplary Operating Environment

FIG. 5 illustrates an example of a suitable mobile device 500 on which aspects of the subject matter described herein may be implemented. The mobile device 500 is only one example of a device and is not intended to suggest any limitation as to the scope of use or functionality of aspects of the subject matter described herein. Neither should the mobile device 500 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary mobile device 500.

With reference to FIG. 5, an exemplary device for implementing aspects of the subject matter described herein includes a mobile device 500. In some embodiments, the mobile device 500 comprises a cell phone, a handheld device that allows voice communications with others, some other voice communications device, or the like. In these embodiments, the mobile device 500 may be equipped with a camera for taking pictures, although this may not be required in other embodiments. In other embodiments, the mobile device 500 may comprise a personal digital assistant (PDA), hand-held gaming device, notebook computer, printer, appliance including a set-top, media center, or other appliance, other mobile devices, or the like. In yet other embodiments, the mobile device 500 may comprise devices that are generally considered non-mobile such as personal computers, servers, or the like.

Components of the mobile device 500 may include, but are not limited to, a processing unit 505, system memory 510, and a bus 515 that couples various system components including the system memory 510 to the processing unit 505. The bus 515 may include any of several types of bus structures including a memory bus, memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures, and the like. The bus 515 allows data to be transmitted between various components of the mobile device 500.

The mobile device 500 may include a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the mobile device 500 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the mobile device 500.

Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, Bluetooth®, Wireless USB, infrared, WiFi, WiMAX, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

The system memory 510 includes computer storage media in the form of volatile and/or nonvolatile memory and may include read only memory (ROM) and random access memory (RAM). On a mobile device such as a cell phone, operating system code 520 is sometimes included in ROM although, in other embodiments, this is not required. Similarly, application programs 525 are often placed in RAM although again, in other embodiments, application programs may be placed in ROM or in other computer-readable memory. The heap 530 provides memory for state associated with the operating system 520 and the application programs 525. For example, the operating system 520 and application programs 525 may store variables and data structures in the heap 530 during their operations.

The mobile device 500 may also include other removable/non-removable, volatile/nonvolatile memory. By way of example, FIG. 5 illustrates a flash card 535, a hard disk drive 536, and a memory stick 537. The hard disk drive 536 may be miniaturized to fit in a memory slot, for example. The mobile device 500 may interface with these types of non-volatile removable memory via a removable memory interface 531, or may be connected via a universal serial bus (USB), IEEE 5394, one or more of the wired port(s) 540, or antenna(s) 565. In these embodiments, the removable memory devices 535-537 may interface with the mobile device via the communications module(s) 532. In some embodiments, not all of these types of memory may be included on a single mobile device. In other embodiments, one or more of these and other types of removable memory may be included on a single mobile device.

In some embodiments, the hard disk drive 536 may be connected in such a way as to be more permanently attached to the mobile device 500. For example, the hard disk drive 536 may be connected to an interface such as parallel advanced technology attachment (PATA), serial advanced technology attachment (SATA) or otherwise, which may be connected to the bus 515. In such embodiments, removing the hard drive may involve removing a cover of the mobile device 500 and removing screws or other fasteners that connect the hard drive 536 to support structures within the mobile device 500.

The removable memory devices 535-537 and their associated computer storage media, discussed above and illustrated in FIG. 5, provide storage of computer-readable instructions, program modules, data structures, and other data for the mobile device 500. For example, the removable memory device or devices 535-537 may store images taken by the mobile device 500, voice recordings, contact information, programs, data for the programs and so forth.

A user may enter commands and information into the mobile device 500 through input devices such as a key pad 541 and the microphone 542. In some embodiments, the display 543 may be touch-sensitive screen and may allow a user to enter commands and information thereon. The key pad 541 and display 543 may be connected to the processing unit 505 through a user input interface 550 that is coupled to the bus 515, but may also be connected by other interface and bus structures, such as the communications module(s) 532 and wired port(s) 540. Motion detection 552 can be used to determine gestures made with the device 500.

A user may communicate with other users via speaking into the microphone 542 and via text messages that are entered on the key pad 541 or a touch sensitive display 543, for example. The audio unit 555 may provide electrical signals to drive the speaker 544 as well as receive and digitize audio signals received from the microphone 542.

The mobile device 500 may include a video unit 560 that provides signals to drive a camera 561. The video unit 560 may also receive images obtained by the camera 561 and provide these images to the processing unit 505 and/or memory included on the mobile device 500. The images obtained by the camera 561 may comprise video, one or more images that do not form a video, or some combination thereof.

The communication module(s) 532 may provide signals to and receive signals from one or more antenna(s) 565. One of the antenna(s) 565 may transmit and receive messages for a cell phone network. Another antenna may transmit and receive Bluetooth® messages. Yet another antenna (or a shared antenna) may transmit and receive network messages via a wireless Ethernet network standard.

Still further, an antenna provides location-based information, e.g., GPS signals to a GPS interface and mechanism 572. In turn, the GPS mechanism 572 makes available the corresponding GPS data (e.g., time and coordinates) for processing.

In some embodiments, a single antenna may be used to transmit and/or receive messages for more than one type of network. For example, a single antenna may transmit and receive voice and packet messages.

When operated in a networked environment, the mobile device 500 may connect to one or more remote devices. The remote devices may include a personal computer, a server, a router, a network PC, a cell phone, a media playback device, a peer device or other common network node, and typically includes many or all of the elements described above relative to the mobile device 500.

Aspects of the subject matter described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the subject matter described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Aspects of the subject matter described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a mobile device. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. Aspects of the subject matter described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

Furthermore, although the term server may be used herein, it will be recognized that this term may also encompass a client, a set of one or more processes distributed on one or more computers, one or more stand-alone storage devices, a set of one or more other devices, a combination of one or more of the above, and the like.

Conclusion

While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.

Claims

1. In a computing environment, a system comprising, a media service configured to play audio in a background process on a mobile device, an interface set by which an application when in the foreground communicates with the media service, the application communicating information via the interface to the media service that corresponds to audio data to play, the media service configured to act upon requests directed towards the audio playback as the media service plays background audio.

2. The system of claim 1 wherein the application provides a uniform resource identifier to the media service as the information that corresponds to audio data to play.

3. The system of claim 1 wherein the media service operates to launch an agent that provides at least one of the requests directed towards the audio playback.

4. The system of claim 1 further comprising a universal volume control component that provides at least one of the requests directed towards the audio playback.

5. The system of claim 4 wherein the application, when in the foreground, provides information that determines the operation of the universal volume control component.

6. The system of claim 4 wherein the media service provides information that is presented on a user interface of the universal volume control component.

7. The system of claim 1 further comprising a source agent, the source agent configured to output audio data that the media service processes into the audio playback, the source agent using a codec, decryption mechanism, decompression mechanism, or a proprietary protocol, or any combination of a codec, decryption mechanism, decompression mechanism, or a proprietary protocol to provide the audio data.

8. The system of claim 7 wherein the source agent is configured to output the audio data to a shared memory for processing.

9. The system of claim 1 wherein the information that corresponds to audio data to play is associated with a control flag, the control flag comprising data that indicates via one or more attributes whether the media service is allowed to take a particular action with respect to the audio playback.

10. The system of claim 9 wherein the control flag includes a set of one or more attributes, the set including an attribute for a skip next action, a skip previous action, a fast forward action, a pause action, or a rewind action, or any combination of attributes for a skip next action, a skip previous action, a fast forward action, a pause action, or a rewind action.

11. The system of claim 1 wherein the requests directed towards the audio playback correspond to user actions, and include play, pause, skip, stop, skip next, skip previous, seek, fast forward, rewind, rating-related actions, shuffle or repeat, or any combination of play, pause, skip, stop, skip next, skip previous, seek, fast forward, rewind, rating-related actions, shuffle or repeat.

12. The system of claim 1 wherein the media service acts upon requests directed towards the audio playback by returning state information, the state information including playing, paused, stopped, fast forwarding, rewinding, buffering started, buffering stopped, track ready or track ended, or any combination of playing, paused, stopped, fast forwarding, rewinding, buffering started, buffering stopped, track ready or track ended.

13. The system of claim 1 wherein the media service is coupled to a playback queue that maintains a playlist of a plurality of audio tracks.

14. In a computing environment, a method performed at least in part on at least one processor, comprising, communicating audio track information to a media service from an audio application operating as a foreground application of a computing device, obtaining audio data corresponding to the audio track information, closing the foreground application, processing the audio data in the media service to play the audio track, including as background audio while another foreground application is running.

15. The method of claim 14 further comprising, taking action to launch an agent to obtain additional audio track information.

16. The method of claim 14 further comprising, providing information provided by the application or the agent, or both, to a universal volume control component for presenting output corresponding to the information via a user interface of the universal volume control component.

17. The method of claim 14 further comprising, taking action to launch a source agent, the source agent configured to process non-native audio formatted data into native audio data that is processed to play the audio track.

18. One or more computer-readable media having computer-executable instructions, which when executed perform steps, comprising: running an audio user interface application as a foreground application on a mobile device;communicating information from the audio user interface application via a background audio service interface to a media service, the information directed towards playing at least one audio track; andprocessing audio data corresponding to the at least one audio track in the media service to provide audio for output, including after the audio user interface application is deactivated.

19. The one or more computer-readable media of claim 18 having further computer-executable instructions comprising, outputting an audible signal corresponding to the audio via the mobile device, receiving a telephone call attempt on the mobile device, and mixing a ringtone with the audible signal until the call attempt ends.

20. The one or more computer-readable media of claim 18 having further computer-executable instructions comprising, running a source agent to process non-native audio data into the audio data processed by the media service.