Abstract:
Described is a technology for managing audio playback queues maintained in separate memory spaces, e.g., in a game console, such that that audio playback continues upon transitioning between states (including reboots) that change a memory space&#39;s contents. For example, before transitioning from a dashboard mode to a game playing mode, the playback queue in memory space used for the dashboard (and the game) is copied to a second queue in a second (e.g., operating system) memory space. The dashboard queue&#39;s contents (often large) are truncated as necessary to fit in the relatively smaller queue space. When transitioning from a game to the dashboard mode, copying the queue back takes place after the dashboard is operational. A third type of queue corresponding to a container of an audio source is also managed, including copying its contents when appropriate to the memory that has the queue currently being used for playback.

Description:
BACKGROUND 
       [0001]    One feature of digital media devices/game consoles such as the Xbox® 360 allows a user to play an in-game sound track other than the musical audio track that accompanies the running game. In general this feature allows the game playing sound effects such as “bleeps” and “blips” to be heard, but substitutes a user&#39;s chosen music for that of the game&#39;s original music track. For some users, this is particularly desirable when playing old “arcade” style games or newer casual games in which the original music, typically electronically generated, is very repetitive and can quickly become monotonous. 
         [0002]    However, a problem with this feature is that the substituted music track stops playing when a user starts a new game, and/or ends the current game such as to return to the game console&#39;s dashboard. This is because internally, the system may perform a reboot at such times for various reasons, including security. Alternatively, the system may call an application programming interface to launch a new image, which also causes the music to stop playing. In any event, users are frustrated with having their music playback suddenly halted for taking (what the user considers to be simple) actions that seem unrelated to music playback. 
       SUMMARY 
       [0003]    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. 
         [0004]    Briefly, various aspects of the subject matter described herein are directed towards managing queues of audio lists maintained in separate memory spaces, such that audio playback continues upon transitioning between states that change the contents of one of the memory spaces. In one example, before a transition from a dashboard mode to a game playing mode, the queue is in a first memory space used for the dashboard mode. During the transition to game playing mode, the contents of the queue are copied to a second queue in a second memory space. The dashboard queue&#39;s contents (often large) are truncated as necessary to fit in the second queue (which is relatively smaller). Alternatively, when transitioning from a game playing mode to a dashboard mode, the second queue in the second memory space is used until after the transition, upon which it is copied to dashboard queue. A third type of queue corresponding to a container of an audio source is managed, including copying its contents when appropriate to the memory that has the queue currently being used for playback. 
         [0005]    In one example implementation, operating system logic copies the queue data in response to the transition, including truncating the data when copying from a larger queue to a smaller queue. The transition may include a reboot operation. Logic also handles starting of audio while a game is running, such as by enumerating the smaller queue with a list from a container corresponding to an audio source, or if too large, enumerating the second queue with one song at a time from an audio source such that the second queue builds a history of audio playback from the audio source. Additional logic that handles transitioning from the game playing mode to the dashboard mode, such as by copying playback queue data to the dashboard space after the dashboard is operational, such that audio playback is not halted upon this transition. The playback queue data may be from a container corresponding to an audio source, and may be copied in a background operation. 
         [0006]    Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    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: 
           [0008]      FIG. 1  shows an illustrative example block diagram of a game console that is configured to play back music when in a dashboard mode. 
           [0009]      FIG. 2  shows an illustrative example block diagram of a game console that is configured to play back music when in a game playing mode. 
           [0010]      FIG. 3  is a flow diagram representing example steps taken to maintain music playback when transitioning from the dashboard mode to the game playing mode. 
           [0011]      FIG. 4  a flow diagram representing example steps taken to maintain music playback when starting audio playback while in a game playing mode. 
           [0012]      FIG. 5  is a flow diagram representing example steps taken to maintain music playback when transitioning from the game playing mode to the dashboard mode. 
       
    
    
     DETAILED DESCRIPTION 
       [0013]    Various aspects of the technology described herein are generally directed towards maintaining music playback such that starting or ending a game from a user&#39;s perspective, including returning to the console&#39;s dashboard (which is equivalent to running a different game), does not cause the currently playing music to stop playing. In general and as described below, no reboots or APIs calls (e.g., to XLaunchNewImage( ) in an Xbox® environment) cause the currently playing music to stop playing. 
         [0014]    In one implementation described herein, maintaining music playback is described in context of an example game console architecture based upon Xbox® 360 technology. However, as can be readily appreciated, this is only one example, and the technology is not limited to any particular game console, or even to game consoles in general, but instead applies to any media playback device including game consoles in which maintaining music playback is desirable but at times would otherwise be adversely affected by internal device operations. 
         [0015]    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 music (or other audio) playback in general. 
         [0016]      FIGS. 1 and 2  show an example architecture in which a game console  102  includes a title (process) memory space  104  and operating system memory space  106 . In general, depending on the current operating state, the title memory space  104  contains a dashboard  108 , or contains a game (e.g., the game&#39;s code and data) as represented in the block labeled  208  in  FIG. 2 . 
         [0017]    The operating system memory space  106  includes the console operating system  110 . For audio playback, audio content may be read from various sources  111 - 115  and decoded by a suitable operating system component into a playback buffer  120 . An active playback queue (described below) contains pointers to the sources, e.g., a file path for hard disk drive files. Non-limiting example sources in  FIGS. 1 and 2  include a hard disk drive  111  in the console, a personal computer  112 , an MTP (media transport protocol) device  113 , another audio playback device  114 , a USB-compatible device  115  such as a CD-ROM or another hard drive, and so forth. Any or all of such sources  111 - 115  may be present and accessible at a given time. 
         [0018]    As can be seen in  FIGS. 1 and 2 , one aspect of playback concerns the way that a user&#39;s playback queue of songs is stored in memory, namely that the active queue may be different depending on whether the queue was created when the dashboard  108  was running or not. This is because when the dashboard is running, the entire title memory space  104  is available for the dashboard  108 , whereby a potentially very large list of songs may be stored in a playback queue  130 . In contrast, when the dashboard is not running, the currently loaded game has control of that memory space  104 , and a different music playback queue  132  is instead stored in operating system memory space  106 , which is relatively far more limited in space, whereby the music playback queue  132  cannot hold as large of a list as the queue  130 . For example, in one implementation, the dashboard&#39;s queue  130  may hold a list songs on the order of tens of thousands, whereas the operating system&#39;s queue  132  may hold a list of songs on the order of a hundred or so. Further, complications arise in that one of many possibly different devices  111 - 115  may be providing the music at any given time. 
         [0019]    To summarize, there are thus different types of queues that may exist, including the queue  130  containing a potentially large list of songs that uses the title&#39;s memory space  104 , corresponding to dashboard music playback. There is also the queue  132  in operating system memory  106 , such as containing a list of N songs, e.g., 100 songs obtained from an external playback device such as one of the devices  113 - 115 . 
         [0020]    For some devices, the information needed for the list corresponds to (and for consistency may be limited to) approximately one-hundred songs. If the user tries to play back a larger collection of songs, the list is truncated. For other devices, the operating system space may store information about the container that the user wanted to play, with the queue  132  used to store a history of which songs have been played. To this end, the operating system memory space  106  alternatively (or in addition to) may include a container object  250  which represents a related collection of songs (e.g., an album or genre) from a particular source (CO  250 ,  FIG. 2 ) and a history of the last N (e.g., 100) songs played from that container (e.g., corresponding to music on the HDD). The maintaining of the history allows playback modes such as shuffle (randomized) playback, repeat and so forth to be implemented. 
         [0021]    For completeness, there is also a fourth kind of playback queue, which is created by a game  208 , e.g., using APIs. This queue is stored in the game&#39;s title memory  208 , so the queue can be very large, but it will be lost when exiting the game because the music source (the game) is also going away at that point in time. 
         [0022]    Turning to an explanation of operation in one example implementation, persisting music playback across reboots corresponds to defining transition behavior (and an underlying conversion) between the types of playback queues. In general, the currently playing song will continue to play from operating system memory space  106 . Note that if transitioning (booting) from a game to another, and the queue is already in the operating system (a non-dashboard queue state), then no changes in the playback queue are made, and playback continues from the operating system. 
         [0023]      FIGS. 3-5  represent the transition operations in other scenarios, beginning at  FIG. 3  which represents example steps taken when transitioning from the dashboard to a game (which internally corresponds to a reboot). Note that the example logic of  FIGS. 3-5  may be contained in a component or the like of the operating system  110 . When switching from the dashboard to a game occurs, as represented at step  302 , a subset of the large queue  130  is copied to the small queue  132 , that is, the large queue  130  is truncated as necessary via steps  302  and  304 . By truncated as necessary, it is meant that if less than N songs&#39; data are in the large queue  130 , the entire queue  130  can be copied to the small queue  132 . For example, before taking the steps to start the game (including reboot) at step  304 , and starting the game (which will take over the title memory space  104 ) at step  306 , the copying operation to operating system memory  106  allows uninterrupted playback to continue from the operating system. 
         [0024]    Step  308  represents playing back from the operating system queue  132 , until some state change (step  310 ) ends playback. For example, state changes that can end the song playback include actions such as the user turning off the device, the user disconnecting the source, the user manually ending the song, and so forth. 
         [0025]    In one example within this dashboard to game transition scenario, if the user is at a song that is beyond the start of the large dashboard queue, e.g., at the fiftieth song, the large queue&#39;s contents are copied such that the small queue  132  includes some number of previously played songs, the current song, and some number of not-yet-played songs; for example, this copy may include up to the last twenty-five played songs, the current song, and the next seventy-four songs. This allows a user to go “back in time” to an extent with respect to playback. One hundred songs corresponds to playback on the order of approximately four to six hours. 
         [0026]      FIG. 4  represents a different scenario, corresponding to changes to playback while in a game. For example, while in a game if a user starts playback from a container  250  on a source which supports performant enumeration (e.g., a personal computer  112  such as via Windows® Media Connect or Windows Media Network Sharing Service  112  or the hard disk drive  111 ) as evaluated at step  402 , and the container  250  lists N (e.g., 100) songs or less (step  404 ), the songs are enumerated into a small queue  132  structure (step  406 ), since the songs can fit inside the small queue  132 . If the container has more than N songs at step  404 , each song is enumerated one at a time, when needed as represented via step  408 . At this point the queue functions as a history of what the most played songs, up to N. Note that background enumeration to fill the queue is an alternative, however in the example implementation, single enumeration is sufficiently fast. 
         [0027]    As represented via step  410 , playback from other sources tries to fill up the small queue  132  structure. Note that depending on the device, step  410  may request more than N (e.g., 100) songs, and discard any amount returned beyond N. 
         [0028]    Playback is represented at step  412 , which typically continues until the song is finished, as represented via step  414 . When finished, if single enumeration is taking place, another song is enumerated (step  408 ), otherwise the next song in the queue is played back (step  416 ). Note that the queue is maintained for history purposes, e.g., so that the same song is not played back again (unless such a mode is specifically requested by the user). Further, note that other state changes can end the song playback, such as the user turning off the device, disconnecting the source, manually ending the song and so forth, however these are not shown in  FIG. 4  for purposes of simplicity. 
         [0029]      FIG. 5  represents example steps when booting from a game to the dashboard, beginning at steps  502  and  504 , where an evaluation is made as to whether playing from a source which supports performant enumerations. If not, then the contents of the operating system queue  132  are copied into the dashboard&#39;s queue  130 , as represented by step  506 . If the source does support performant enumeration another check is made to check whether a container  250  with less than N (e.g., 100) songs is being used. If so, the contents of the operating system queue  132  are copied into the dashboard&#39;s queue  130 , as represented by step  506 . Playback continues through the reboot, because the operating system is used for the queue until the copy is complete. If playing a container  250  with more than N songs, a background enumeration of the container is performed (step  508 ) to populate the dashboard queue  130 . Step  510  represents playing back from the dashboard queue, until some state change (step  512 ) ends playback. 
         [0030]    Other alternatives are feasible, including compressing the data in some way (e.g., hashing) to maintain a larger number of songs in the small queue. Another alternation is to persist the large queue to the console&#39;s (or another) hard drive or similar storage, such as flash memory unit if present, and access it as necessary. Note that writing to a hard drive may slow down starting the game, and thus is not always desirable. Similarly, sometimes writing to a memory unit depending on whether it is available may provide different user experiences, and thus is not always desirable. 
         [0031]    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.