U.S. patent application number 13/162459 was filed with the patent office on 2012-08-16 for background audio on mobile devices.
This patent application is currently assigned to MICROSOFT CORPORATION. Invention is credited to Eric H. Bie, Rachel Jiang, Bryan Welbourne Nealer, William G. Patton, III, Christopher James Pearson, Peter John Torr, Yensheng Wang, Mei L. Wilson, Lejie Xu.
Application Number | 20120209413 13/162459 |
Document ID | / |
Family ID | 46637513 |
Filed Date | 2012-08-16 |
United States Patent
Application |
20120209413 |
Kind Code |
A1 |
Xu; Lejie ; et al. |
August 16, 2012 |
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).
Inventors: |
Xu; Lejie; (Redmond, WA)
; Torr; Peter John; (Bellevue, WA) ; Wilson; Mei
L.; (Redmond, WA) ; Jiang; Rachel; (Redmond,
WA) ; Nealer; Bryan Welbourne; (Seattle, WA) ;
Bie; Eric H.; (Duvall, WA) ; Pearson; Christopher
James; (Redmond, WA) ; Patton, III; William G.;
(Seattle, WA) ; Wang; Yensheng; (Sammamish,
WA) |
Assignee: |
MICROSOFT CORPORATION
Redmond
WA
|
Family ID: |
46637513 |
Appl. No.: |
13/162459 |
Filed: |
June 16, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61442701 |
Feb 14, 2011 |
|
|
|
61442713 |
Feb 14, 2011 |
|
|
|
61442735 |
Feb 14, 2011 |
|
|
|
61442753 |
Feb 14, 2011 |
|
|
|
61442740 |
Feb 14, 2011 |
|
|
|
Current U.S.
Class: |
700/94 |
Current CPC
Class: |
Y02D 70/146 20180101;
Y02D 70/164 20180101; H04N 21/439 20130101; H04N 21/233 20130101;
Y02D 70/124 20180101; Y02D 70/12 20180101; Y02D 30/70 20200801;
H04N 21/6175 20130101; H04N 21/4126 20130101; H04W 4/60 20180201;
Y02D 70/142 20180101; H04W 4/50 20180201; H04W 52/0264 20130101;
G06F 9/546 20130101; Y02D 70/26 20180101; Y02D 70/23 20180101; G06F
9/5011 20130101; Y02D 70/144 20180101; H04L 41/0893 20130101 |
Class at
Publication: |
700/94 |
International
Class: |
G06F 17/00 20060101
G06F017/00 |
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; and processing 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.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] The present application claims priority to U.S. provisional
patent applications Ser. Nos. 61/442,701, 61/442,713, 61/442,735,
61/442,740 and 61/442,753, each filed Feb. 14, 2011 and hereby
incorporated by reference. The present application is related to
U.S. patent applications attorney docket nos. 332296.02, 332297.02,
332320.02 and 332340.02, assigned to the assignee of the present
invention, and hereby incorporated by reference.
BACKGROUND
[0002] 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.
[0003] 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.
[0004] 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
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] Other advantages may become apparent from the following
detailed description when taken in conjunction with the
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] 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:
[0014] FIG. 1 is a block diagram representing example components
for playing background audio, including when an audio playback
application is deactivated from the foreground.
[0015] 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.
[0016] FIG. 3 is a block/control flow diagram representing example
operations to prepare for and play background audio.
[0017] FIG. 4 is a block/data flow diagram representing example
data that may be communicated to prepare for and play background
audio.
[0018] 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
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.RTM.) experience, and integration with
a program 118 via an XNA/Silverlight.TM. environment 120. To this
end, XNA and Silverlight.RTM. may use a native playback API to
perform audio playback, and media service playback coordinates the
request from Silverlight.RTM. and XNA. This design enables
application to use both XNA and Silverlight.RTM. code in one
process. Other aspects include a "Nowplaying" token, phone call
interruption, and others.
[0028] 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.
[0029] 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).
[0030] 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).
[0031] 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.
[0032] 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.
[0033] 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).
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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:
[0042] 1. Application creates service request ("play this track and
call me back when you need the next one")
[0043] 2. Service starts playing the track
[0044] 3. User closes application
[0045] 4. Current track ends
[0046] 5. Service asks system to call the agent to get the next
track
[0047] 6. System starts new process and invokes the agent
[0048] 7. Agent performs logic and provides the next track
information
[0049] 8. System suspends or kills the agent
[0050] 9. Current track ends . . . (back to step 5)
[0051] 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:
[0052] 1. Create an instance of the background service 108
(including the API set).
[0053] 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.
[0054] 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)
[0055] 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).
[0056] 5. For this example, assume the server returns a HTTP URL
that points to the track to play.
[0057] 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.
[0058] 7. The application 304 passes the new AudioTrack object to
the background audio service 108 via an appropriate function
call.
[0059] 8. The background audio service 108 creates a new media item
via an appropriate function call.
[0060] 9. The background audio service 108 queries the given
AudioTrack for the URI which it sets on the item.
[0061] 10. The background audio service 108 adds the track to the
media service/queue.
[0062] 11. The application calls the play function of the
background audio service 108.
[0063] 12. The background audio service 108 initiates playback by
calling the media service.
[0064] 13. The application receives events it is interested in.
[0065] 14. Shell tells the application it is closing.
[0066] 15. The application destroys its background audio service
108 object, and the media service continues to play the track.
[0067] 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:
[0068] 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.
[0069] 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.
[0070] 3. The agent creates a new AudioTrack and sets the metadata
accordingly.
[0071] 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."
[0072] 5. The agent passes the new AudioTrack object to the
BackgroundAudioPlayer.
[0073] 6. The agent calls background audio service 108.
[0074] 7. Playback resumes where the user left off (assuming that
the track is still available on the service).
[0075] 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:
[0076] 1. The application creates an instance of the background
audio service 108.
[0077] 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.
[0078] 3. The media service reports that there is a background
queue for this application.
[0079] 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.
[0080] 5. The application checks to see if there is a current
track, which in this example there is.
[0081] 6. The application gets the current track and queries for
the title.
[0082] 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.
[0083] 8. The application calls a function
(BackgroundAudioPlayer.PlayState) to get the current play state
(Playing).
[0084] 9. Because the content is playing, the application calls a
function (AudioTrack.Duration) to get the track's duration.
[0085] 10. The application calls a function
(BackgroundAudioPlayer.Progress) to get the current position.
[0086] 11. The application updates its UI with this
information.
[0087] 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.RTM.) 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:
[0088] 1. The original background audio agent receives the
save-related (On PlayStateChanged/Shutdown) callback.
[0089] 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.
[0090] 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.
[0091] 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:
[0092] 1. The audio background agent's OnUserAction callback is
fired. The UserAction enumeration is set to SkipNext.
[0093] 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).
[0094] 3. The audio background agent queries the web servers for
the URL of the next track to play.
[0095] 4. The audio background agent creates a new AudioTrack
object and sets the URL and other pertinent metadata.
[0096] 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.
[0097] 6. The audio background agent calls Play to begin playing
the new track.
Exemplary Operating Environment
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.RTM., 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.
[0103] 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.
[0104] 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.
[0105] 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.
[0106] 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.
[0107] 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.
[0108] 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.
[0109] 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.
[0110] 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.RTM.
messages. Yet another antenna (or a shared antenna) may transmit
and receive network messages via a wireless Ethernet network
standard.
[0111] 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.
[0112] 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.
[0113] 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.
[0114] 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.
[0115] 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.
[0116] 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
[0117] 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.
* * * * *