Coordinated forwarding of an audio data transmission

Abstract

Method comprising: identifying an audio collection including one or more songs at a first device (110); determining that the first device (110) is a playback device; Coordinating, at the first device (110), a playback of a song of the one or more songs by transmitting, from the first device (110) to a speaker (115), audio data from the audio collection, the audio data corresponding to the song; accessing a rule indicating whether a device other than the playback device should take over at the first device (110); automatically determining, by the first device (110), and while the first device (110) is coordinating playback of the song, that a second device (120) should take over as the playback device based on a property of the second device (120) and the accessed rule; Transmitting, from the first device (110) to the second device (120), one or more pieces of playback information for taking over the transmission of the audio data from the audio collection to the loudspeaker (115), wherein the one or more pieces of playback information identify at least the song and a takeover playback position within the song at which, after the takeover, the second device (120) is to begin playing the song, and wherein a current playback of the song coordinated by the first device (110) corresponds to a current playback position located at the takeover playback position within the song; and Terminating, at a time corresponding to the takeover playback position, the transmission of the audio data from the audio collection from the first device (110) to the loudspeaker (115).

Description

BACKGROUNDThe present invention relates generally to automated coordination between electronic devices, and more particularly to the smooth and automatic passing of a music collection replay between devices.Electronic devices have altered the ease with which persons can hear music. Many years ago, bulky playback units and physical media were needed to be able to play recorded wires. Now, wires from mobile devices can be played without using physical media. Users of these devices can therefore enjoy music while moving from place to place. However, music playback may be discontinued when the battery or battery of the device ends or the strength of a network connection weakens.Many mobile devices can play music so that the user can enjoy song while moving around. Nevertheless, the performance of a mobile device may degrade over time as its charge and / or network connection attenuates. Further, the existing dependency on the mobile device may cause the user to suspend using another music playback device associated with better sound quality (e.g., paired with better speakers), social inclusion (e.g., paired with speakers rather than earphones), and / or playback stability (e.g., charge). While a user may always choose to actively change playback devices, this may cause a playback break even during the change, and a playback position within an audio collection may be lost.EP 2 226 972 A2 discloses a digital living network alliance system and methods for providing content therein.US 2003 / 0 073 412 A1 discloses a system and a method for a mobile computer device for controlling devices.SUMMARYThe invention is defined in the independent claims. Advantageous embodiments are defined in the dependent claims. In acoustic embodiments, an audio collection including one or more song may be identified at a first device. A determination may be made that the first device is a playback device. Audio data from the audio collection may be conveyed to a speaker by the first device. In the first device, a rule can be accessed, from which rule it can be established whether a device other than the playback device is to take over. A determination that a second device is to take over as a playback device may be made by the first device based on a property of the second device and the rule being accessed. A characteristic of transmitting the audio data from the audio collection to the speaker may be transmitted from the first device to the second device. The transmission of the audio data from the audio collection from the first device to the speaker may be ended.In some embodiments, a dynamic set of devices may be identified at a master device. Each device of the dynamic set of devices may be within the same range and has the capability to communicate audio data to a speaker. The master device may identify a first device of the dynamic set of devices, which is a playback device that conveys audio data from an audio collection to a speaker. The master device may determine that a second device of the dynamic set of devices is to take over as the playback device. The main device may transmit a characteristic of transmitting the audio data from the audio collection to the speaker to the second device.Some embodiments relate to an electronic device that may include an input component configured to receive input from a user, an output component configured to transmit audio data, and one or more processors coupled to the input component and to the output component. The electronic device may also include a computer readable storage medium containing instructions that, when executed by the one or more processors, cause the one or more processors to perform a set of actions. The actions may include identifying an audio collection that includes one or more song and determining that the electronic device is a playback device. The actions may also include communicating audio data from the audio collection to a speaker, accessing a rule indicating whether to take over another device as a playback device, and determining that a second device is to take over as a playback device based on a property of the second device and the rule being accessed. The actions may further include communicating a characteristic of the communication of the audio data from the audio collection to the speaker to the second device and causing the communication of the audio data from the audio collection from the electronic device to the speaker to cease.Some embodiments relate to a main electronic device including one or more processors coupled to the input component and the output components and a computer readable storage medium. The medium may also include instructions that, when executed by the one or more processors, cause the one or more processors to perform a set of actions. The actions may include identifying a dynamic set of devices. Each device of the dynamic set of devices may be within the same range and has the capability to communicate audio data to a speaker. The actions may also include identifying a first device of the dynamic set of devices, which is a playback device that conveys audio data from an audio collection to a speaker, and determining that a second device of the dynamic set is to take over as the playback device. The actions may further include communicating a characteristic of communicating the audio data from the audio collection to the speaker to the second device.The following detailed description, together with the accompanying drawings, will provide a better understanding of the nature and advantages of the present invention.BRIEF DESCRIPTION OF THE DRAWINGSFig. 1 shows an example of audio reproduction transferred between devices in response to user movement. FIG. 2 shows examples of devices connected to a network with access to an audio collection. FIG. 3 illustrates a wearable device that wirelessly communicates with a mobile device according to an embodiment of the present invention. FIG. 4 is a simplified block diagram of a wearable device according to an embodiment of the present invention. FIG. 5 is a simplified block diagram of a mobile device according to an embodiment of the present invention. FIG. 6 is a flow diagram of a process for transferring audio playback between devices according to an embodiment of the present invention. FIG. 7 is a flow diagram of a process for coordinating transfer of audio playback between devices according to an embodiment of the present invention. FIG. 8 is a flow diagram of a process for responding to playback inputs in a distributed device playback network in accordance with an embodiment of the present invention. FIG. 9 is a flow diagram of a process for responding to device motion according to an embodiment of the present invention.DETAILED DESCRIPTIONCertain embodiments of the present invention may enable a smooth listening experience during which a user may enjoy continuous music playback despite moving between environments or using a device with limited playback capabilities. A user may initiate playback of an audio collection on a first device. The first device (e.g., before or after starting rendering the collection) may detect nearby devices (e.g., paired devices connected to the first device via a Bluetooth or BTLE connection). Using a rule, it can be determined whether the first device should remain (at least temporarily) the playback device, or whether a detected device should take over the playback, in which case playback transfer preparations can be undertaken. A message including playback information (e.g., an audio collection identifier, playback position, volume variable, and / or speaker identifier) and a playback start time may be sent to a second device. In some cases (e.g., when a playback transfer is coordinated by a host device independent of the first and second devices), a message is also sent to the first device indicating that it should stop its playback at a particular time. The second device may then begin playing music (e.g., using the same or a different speaker than used by the first device), and the first device may stop playing music substantially simultaneously.While a first playback device is playing song from an audio collection, in some embodiments, one or more second devices may be accessed to potentially take over the playback. This assessment may be made by comparatively assessing characteristics of the other devices, such as their energy source (e.g., favouring reliable AC energy sources), remaining battery charge (if applicable), strength of a network connection, access to a song and / or device type. For example, in a particular case, a device that relies on a battery or battery as power may initiate playback transfer to a second device with an AC power source (e.g., regardless of remaining battery or battery charge). When a determination is made to transfer the playback to a second device, a message may be sent to the second playback unit indicating when playback begins and which song is to be played. The first reproducing apparatus can stop reproducing at substantially the same time as the new reproducing apparatus starts reproducing.For example, a user may initiate playback of an audio collection using an electronic wearable device such as smart glasses, smart hearing elements, smart earphones, smart watch, smart bracelet, and the like. The wearable device may then continuously communicate music to a speaker, such as a Bluetooth speaker or a Bluetooth headset. While the wearable device may allow the music to follow the user as he moves, playing the audio collection may quickly empty the battery or battery of the wearable device, so that the user may be unlikely to be able to enjoy the music for a longer period of time. For example, the wearable device can therefore search even for other nearby devices equipped to take over the reproduction. The wearable device can capture a laptop with a stable AC power source that has other acceptable music playing capabilities. The wearable device may then send a message to the laptop indicating that the laptop should begin playing the audio collection (immediately or at a later time). The body-worn device can stop playing music at the hand-over time. The laptop may take over the playback and itself transmit music data to the same speaker (e.g., Bluetooth speaker or headset) as used by the wearable device or to another speaker. The wearable device, laptop, or other device may then monitor the laptop's playback and / or determine whether the laptop is to deliver its playback to another device (e.g., the wearable device or a third device). In this way, music reproduction devices can smoothly relay music reproduction to each other to benefit from their combined capabilities.Fig. 1 shows a user 105 listening to music while walking in a room. The user 105 wears a wearable device 110 on a body part (e.g., his head). The wearable device 110 may play music from an audio collection that may be accessed (e.g., streamed from a source or retrieved from a remote data store), for example, via a network, or stored on the device. Specifically, the wearable device 110 may communicate music to speakers 115 that the user 105 can position in their ears.The wearable device 110 may include a battery or battery that deflates during music playback. Thus, a master device (which may be wearable device 110 or another device) may perform monitoring to determine whether another device is in proximity that may take over the playing of the music. In the depicted illustration, a mobile device 120 (e.g., a smartphone) may be detected as a user 105 approaches it. The main device may assess characteristics of the mobile device 120, such as whether it has access to music (e.g., general or that in audio collection), its power state (e.g., remaining battery or battery charge), its power source (e.g., AC power as opposed to battery or battery), and / or a strength of a speaker connection. In this illustration, mobile device 120 has a stable power source, has access to the same audio collection (e.g., via a network connection), and has a satisfactory connection between mobile device 120 and speakers 115.Thus, in the depicted illustration, the host device may coordinate a transfer of a playback from the wearable device 110 to the mobile device 120. A message may be sent to mobile device 120 indicating that it is to begin playing songs. The message may further identify the audio collection and / or a playback variable that indicates or limits which music to play (e.g., a starting position in an audio collection). In some cases (e.g., when the master device is not the first device), a message indicating to stop playing song may also be sent to the wearable device 110. The mobile device 120 itself may access at least a portion of the same audio collection over the network using the collection identification from the message. The mobile device 120 may then begin playing the audio collection. The data that is retrieved and / or what is initially being played back may be determined based on the playback variables. For example, the reproduction variable may indicate a song identifier or an intra-song time, and reproduction may start appropriately. At substantially the same time, the wearable device 110 may stop transmitting music to the speakers 115.Thus, the music reproduction can be smoothly transferred from the body-worn device 110 to the mobile device 120. In this case, music continues to be conveyed over the same set of speakers 115, although in other embodiments, the speakers may change after transfer (e.g., to select speakers that are closest to the playback device). The transfer may even occur without any required intervention from the user and / or (in some cases) even without indicating to the user that the transfer is occurring, occurred, or will occur.FIG. 2 shows examples of devices connected on a network with access to an audio collection. Exemplary devices 205 that can play music include a wearable device 205 a(such as smart glasses, smart hearing elements, smart earphones, smart watch, smart bracelet, and the like), a phone 205 b(e.g., smart phone), a tablet 205 c, a television 205 d, and a computer 205 e.Each device 205 may be configured to play music through a speaker. For example, device 205 may include a speaker, device 205 may include an output port of a jack that may receive a cable that may be connected to a speaker, or device 205 may wirelessly communicate audio signals to a speaker. In the depicted illustration, each device 205 is Bluetooth compatible and may communicate with Bluetooth compatible speakers such as a listening element speaker 210a or a speaker 210b via a Bluetooth connection 215 or BTLE connection. A speaker for audio output may be selected by selecting or favorably weighting, for example, a speaker having a strongest connection to a reproduction device, a speaker having a strongest connection to a reproduction initiating device, a most recently used speaker, a most highly-located speaker (e.g., defined by a user) in a hierarchy among the within-range speakers, or a speaker selected by a user.Each device 205 may have access to an audio collection. An audio collection may include a collection of audio data, such as a collection of music data (or spoken data, such as a podcast). The audio collection may include a single song or a group of songs. In various cases, the audio collections accessible to the various devices 205 may be the same, different, or partially overlapping. The audio collection may include multiple songs and include an organization. For example, a particular audio collection may include a sorted playlist with the song in the playlist. As another example, a particular audio collection may include a group of songs, each categorized as a genie such as "big band.". In some cases, a portion or all of the audio collection is stored on a device and / or in the cloud. The cloud may be a remote storage accessible to a device via a network, such as the Internet. For example, a user may store a song library in the cloud, and one or more devices may thus be able to access the library via a network. In some cases, a portion or all of the audio collection is provided by a third party. For example, the audio collection may include an audio stream and / or an online radio. In some cases, a portion or all of the audio collection is streamed from a third party system.In the depicted illustration, each device may access a (same or different) audio collection (e.g., a collection of a user stored in the cloud or a collection provided by a third party) via a WLAN network 220. An audio access system 225 may (in some cases) verify that a device is authorized to receive a song of the audio collection. For example, a device 205 may request a song from an audio collection and add a user identifier to the request. This request may in some cases include an identifier of a particular collection, an identifier of a song, an identifier of a location in a song, and / or a song category (e.g., artist or genre). Audio access system 225 may then look up the user identifier in user account data store 230 to determine which collection or collections can be accessed by the user. When the user is authorized to receive the requested audio collection, the audio access system 225 may retrieve a portion or all of the audio collection from an audio collection data store 235 and output the collected data to the requesting device. This type of communication may be performed once, repeatedly, or continuously (e.g., in streaming applications).Each of the Bluetooth connection 215 and the WLAN network 220 may also support transfer of playback between devices. Specifically, the connections of a given device may allow other nearby devices to be detected, characteristics of the detected devices to be identified, a music playback to be transferred to a device, and / or to communicate playback-relevant inputs to a playback device. Short range connections, such as Bluetooth connection 215 or a BTLE connection, may be particularly convenient for such communications given the ability to store energy.The decision as to whether and / or which device is to take over audio reproduction can be made by a main device. This main device may include the playback device, another local device, or a remote system. Which device is designated as the main device may change with time (e.g., such that the playback device is always the main device) or may remain fixed (e.g., such that a wearable device 205a is always a main device or such that a device that initiated music playback is the main device until playback is completed).To coordinate playback transfer from a first device to a second device, a message may be sent to a second playback device (e.g., via Bluetooth connection 215) with explicit or implicit instructions to start playback. The message may further include details indicating which music is to be played and when playback is to begin. If appropriate (e.g., if the master device was not a playback device prior to transfer), the master device may also send a message to the first device to stop playback. The second device may then access appropriate music (e.g., by retrieving it from a local data store, receiving it from a remote data store, streaming it from a source, or receiving it from the first device) and continue the previous music playback seamlessly.Due to the similar connections of the devices, the reproduction can be smoothly transferred between devices. In a particular case, each device may have access to a same audio collection via audio access system 225. Thus, following a rendering transfer, a second device may continue rendering the same song that was rendered by a first device. Further, in some embodiments, each of multiple devices may even be configured to render song using the same speaker.It will be appreciated that the illustration in Figure 2 may be modified to include other types of connections and networks. For example, the connection 215 may be modified to include a wired connection, and the network 220 may include a local area network (local area network).FIG. 3 illustrates a wearable device 300 wirelessly communicating with a mobile device 302 according to an embodiment of the present invention. Although a simple wearable device and a smartphone are included in the illustration, it will be appreciated that the illustrative devices may represent any two electronic devices capable of reproducing and communicating audio files over a network. Examples of communication may include: broadcast searching for nearby devices, requesting a property from a receiving device, identifying a property (e.g., from a transmitting device), indicating that a receiving device is to take over music playback, accepting take over responsibility, and / or identifying playback information (e.g., an identifier of an audio collection). In this example, the wearable device 300 is shown as a banded display device having a front portion 304 connected to a strap 306, which may include a buckle 308 that facilitates connection and disconnection of distal ends of the strap 306.For example, the front portion 304 may include a touch-sensitive display 305, which may be suitably sized depending on where a person of a user is to wear the wearable device 300. A user may view the touch-sensitive display 305 through the information output on the wearable device 300 and provide input by touching the touch-sensitive display 305 of the wearable device 300. For example, a user may use the touch-sensitive display 305 to select an audio collection, initiate a playback of music in the audio collection, and / or control playback characteristics (e.g., volume, pause, and / or jump to the next song). In some embodiments, the touch-sensitive display 305 may occupy most or all of the front surface of the front portion 304.The strap 306 (including a buckle that may be present) may include sensors that allow the wearable device 300 to determine whether it is worn at a given time. The wearable device 300 may operate differently depending on whether it is currently being worn. For example, the wearable device 300 may deactivate various user interface and / or RF interface components when not worn. Additionally, in some embodiments, the wearable device 300 may notify the mobile device 302 when a user attaches or wears the wearable device 300. Further, the strap 306 may include sensors capable of detecting body movements of a user wearing the wearable device 300; examples of such sensors are described below.Mobile device 302 may be any device that communicates with wearable device 300 and that a user may carry from location to location and use in different locations. For example, the mobile device 302 may be a hand-held device configured to be held in a user's hand during use and stored elsewhere (e.g., in a pants bag or bag) when not in use. In FIG. 3, the mobile device 302 is shown as a smartphone; however, it may be replaced with other devices, such as a tablet computer, a media playback unit, any type of cellular phone, or other hand-held computing and / or communication device, laptop computer, or the like. In some embodiments, the wearable device 300 may also communicate with other host devices that are not necessarily mobile, such as desktop computer systems, point-of-sale terminals, security systems, environmental control systems, and so forth. The mobile device 302 (and any other host devices) may wirelessly communicate with the wearable device 300, e.g., using protocols such as Bluetooth or Wi-Fi. In some embodiments, the wearable device 300 may include an electrical connector 310 that may be used to provide a wired connection to the mobile device 302 and / or other devices using, for example, suitable cables. For example, the connector 310 may be used to connect to a power supply to charge an integrated battery of the wearable device 300.In some embodiments, the wearable device 300 and the mobile device 302 may cooperate to extend the functionality available on one of the devices. For example, the wearable device 300 and the mobile device 302 may establish pairing using a wireless communication technology such as Bluetooth. While the devices are paired, one of the devices may send notifications to the other device of selected events (e.g., receiving a phone call, a text message, or an email message) so that it may issue corresponding alarms to the user. As a particular example, mobile device 302 may send notifications to wearable device 300 to receive a phone call, text message, or email message. As another example, a playback device (e.g., mobile device 302) may send notifications of a song playback (e.g., song title, artist, and / or time in the song) to one or more other devices (e.g., wearable device 300). As yet another example, a notification may be sent that the playback is about to be transferred from a first device to a second device.The wearable device 300 may also provide an input interface through which a user may provide input. For example, the input may include a response to an alarm (e.g., accept a phone call, respond to a text message, or evaluate a song). As another example, the input may include one for initiating an action (e.g., changing a volume, skipping, advancing, rewinding, pause, playback, selecting a song, selecting a playlist, selecting a genre, turning on a display screen, placing a phone call, or sending a text message), or restricting speaker selection (e.g., selecting a speaker to be used, selecting a speaker not to be used, or selecting a speaker type not to be used). As yet another example, the input may include an indication that an identified playback transfer is not to occur.It will be appreciated that the wearable device 300 and the mobile device 302 are illustrative and that variations and modifications are possible. For example, the wearable device 300 may be implemented in a variety of wearable articles including a hearing element, a rfphonerd, a bracelet, a wristwatch, a bracelet, or the like. In some embodiments, the wearable device 300 may be operable regardless of whether the mobile device 302 is communicating with the wearable device 300.The wearable device 300 may be implemented using electronic components disposed within the front portion 304 and / or the strap 306. FIG. 4 is a simplified block diagram of a wearable device 400 (e.g., implementing the wearable device 300) according to an embodiment of the present invention. The wearable device 400 may include a processing subsystem 402, a storage subsystem 404, a user interface 406, an RF interface 408, a connector interface 410, a power subsystem 412, environmental sensors 414, and strap sensors 416. The wearable device 400 may also include other components (not explicitly shown).The storage subsystem 404 may be implemented using, for example, magnetic storage media, flash memory, other semiconductor memory (e.g., DRAM, SRAM), or other non-transitory storage medium, or a combination of media, and may include volatile and / or non-volatile media. In some embodiments, storage subsystem 404 may store media items such as audio files, video files, image or graphics files; user contacts information (names, addresses, telephone numbers, etc.); playlists; user scheduled deadlines and events information; notes, and / or other types of information, examples of which are described below. In some embodiments, storage subsystem 404 may also store one or more application programs (or apps) 434 that are executed by processing subsystem 402 (e.g., video game programs, personal information management programs (personal information management programs), media game programs, interface programs associated with particular host devices and / or host device functionalities, etc.).The user interface 406 may include any combination of input and output devices. A user may operate input devices of the user interface 406 to invoke functionality of the wearable device 400, and may view, listen, and / or otherwise perceive output from the wearable device 400 via output devices of the user interface 406.Examples of output devices include a display 420, speakers 422, and a haptic output generator 424. The display 420 may be implemented using compact display technologies, for example, LCD (liquid crystal display), LED (light emitting diode), OLED (organic light emitting diode), or the like. In some embodiments, the display 420 may include a flexible display element or a bent glass display element that allows the wearable device 400 to conform to a desired shape. One or more speakers 422 may be provided using small form factor speaker technologies, including any technology capable of converting electronic signals to audible sound waves. In some embodiments, the speakers 422 may be used to generate sounds (e.g., beeps or ring tones) and may or may not be able to reproduce sounds, such as voice or music, with a certain level of fidelity. The haptic output generator 424 may be, for example, a device that converts electronic signals into vibrations; in some embodiments, the vibrations may be strong enough to be felt by a user wearing the wearable device 400, but not so strong as to generate significant sounds. As described in more detail below, the wearable device 300 may further function to play songs by transmitting audio data to a separate speaker.Examples of input devices include a microphone 426, a touch sensor 428, and a camera 429. The microphone 426 may include any device that converts sound waves into electronic signals. In some embodiments, the microphone 426 may be sufficiently sensitive to provide a reproduction of specific words spoken by a user; in other embodiments, the microphone 426 may be usable to provide indications of general ambient sound levels without necessarily providing a high quality electronic reproduction of specific sounds.Touch sensor 428 may include, for example, a capacitive sensor array having the capability to associate contacts with a particular location or region on the surface of the sensor, and in some cases, having the capability to distinguish multiple simultaneous contacts. In some embodiments, touch sensor 428 may overlay display 420 to provide a touch-sensitive interface (e.g., touch-sensitive interface 103 of FIG. 3 ), and processing subsystem 404 may translate touch events (including taps and / or other gestures made with one or more contacts) into specific user inputs depending on what is currently displayed on display 420.For example, camera 429 may include a compact digital camera that includes an image sensor, such as a CMOS sensor, and optical components (e.g., lenses) arranged to focus an image onto the image sensor, along with control logic operable to use the image processing components to capture and store still and / or video images. Images may be stored in, for example, storage subsystem 404 and / or transmitted by wearable device 400 to other devices for storage. Depending on the implementation, the optical components may provide a fixed focal length or a variable focal length; in the latter case, auto focus may be provided. In some embodiments, camera 429 may be disposed along an edge of front element 304 of FIG. 3, e.g., the top edge, and oriented to allow a user to capture images of nearby objects in the environment, such as a barcode or QR code. In other embodiments, the camera 429 may be disposed on the front surface of the front member 304, for example, to capture images of the user. Depending on the implementation, zero, one or more cameras may be provided.In some embodiments, the user interface 406 may provide output to and / or receive input from an auxiliary device, such as a headset. For example, an audio jack 430 may connect to an auxiliary device via an audio cable (e.g., a 2.5 mm or 3.5 mm standard audio cable). The audio jack 430 may include input and / or output paths. Accordingly, the audio jack 430 may provide audio signals to the auxiliary device and / or receive audio signals from the auxiliary device. In some embodiments, a wireless connection interface may be used to communicate with an auxiliary device.Processing subsystem 402 may be implemented as one or more integrated circuits, e.g., one or more microprocessors or microcontrollers having one core or more cores, examples of which are known in the art. In operation, the processing system 402 may control the operation of the wearable device 400. In various embodiments, processing subsystem 404 may execute a variety of programs in response to program code, and may maintain multiple programs or processes executing simultaneously. At any given time, some or all of the program code to be executed may be in processing subsystem 404 and / or in storage media such as storage subsystem 404.By suitable programming, processing subsystem 402 may provide various functionalities for wearable device 400. For example, in some embodiments, processing subsystem 402 may execute operating system (OS) 432 and various applications 434, such as a telephone interface application, a text message interface application, a media interface application, a fitness application, and / or other applications. In some embodiments, some or all of these application programs may interact with a host device, e.g., by generating messages to be sent to the host device and / or by receiving and interpreting messages from the host device. In some embodiments, some or all of the application programs may operate locally on the wearable device 400. For example, if the wearable device 400 has a local media library stored in the storage subsystem 404, a media interface application may provide a user interface to select and play back locally stored media items.Processing subsystem 402 may also execute a playback transfer coordination code 436 (which may be part of OS 432 or separate, as desired). In some embodiments, executing the playback transfer coordination code 436 may cause the wearable device 400 to search (e.g., while playing music from an audio collection) to determine whether there is a nearby device (e.g., the mobile device 302) and evaluate characteristics of the device using a rule to determine whether the device should be made a playback device. If so, execution of the playback transfer coordination code 436 may send a message to the identified device preparing it to take over audio playback (e.g., identify what content to play, when to begin playback, and a volume parameter). Executing the code 436 may cause the wearable device 400 to stop playing music at a time when the device is to begin playing. In some embodiments, execution of the playback transfer coordination code 436 stops following playback transfer.In other embodiments, continued execution monitors playback at the playback device. For example, characteristics (e.g., location, battery or battery charge, power source, and / or strength of a network connection) of the playback device may be received from the device and evaluated alone or relative to other devices (e.g., wearable device 400 and / or other nearby devices) using a takeover rule. As another example, executing may monitor playback progress (e.g., a played song, a location in the song, or a radio station). In a particular case, this information can be sent by a playback device, for example, in routine intervals when a playback of a new song begins or after performing a playback-relevant user input (e.g., selecting a new song).The RF (radio frequency) interface 408 may allow the wearable device 400 to wirelessly communicate with various host devices. The RF interface 408 may include RF transceiver components, such as an antenna and supporting circuitry, to enable data communication over a wireless medium, e.g., using WLAN (IEEE 802.11 family standards), Bluetooth® (a family of standards promulgated by Bluetooth SIG, Inc.), or other wireless data communication protocols. In some embodiments, the RF interface 408 may implement a Bluetooth Low Energy (LE) proximity sensor 409 that supports proximity detection by estimating signal strength and / or other protocols for determining proximity to another device. In some embodiments, the RF interface 408 may provide near-field communication (NFC) capability (capability), e.g., implementing the ISO / IEC standards 18092 or the like; NFC may support wireless communication between devices over a very short range (e.g., 20 cm or less). The RF interface 408 may be implemented using a combination of hardware (e.g., driver circuits, antennas, modulators / demodulators, encoders / decoders, and other analog and / or digital signal processing circuits) and software components. Multiple different wireless communication protocols and associated hardware may be included in the RF interface 408.The connector interface 210 may allow the wearable device 200 to communicate with various host devices over a wired communication path, e.g., using Universal Serial Bus (USB), Universal Asynchronous Receiver / Transmitter (UART), or other wired data communication protocols. In some embodiments, connector interface 210 may provide a power port that allows wearable device 200 to receive power to charge an internal battery / battery 240, for example. For example, the connector interface 210 may include a connector such as a USB connector or a user-defined connector, as well as supporting circuitry.In some embodiments, the connector interface 410 and / or the RF interface 408 may be used to support synchronization operations in which data is transferred from a host device to the wearable device 400 (or vice versa). For example, a user may be able to adjust settings and other information for the wearable device 400. Although the user interface 406 may support data input operations, a user may find it more convenient to define customized information on a separate device (e.g., a tablet or smartphone) having a larger interface (e.g., with a real or virtual alphanumeric keyboard) and then transfer the customized information to the wearable device 400 via a synchronization operation. Synchronization operations may also be used to load and / or update other types of data in storage subsystem 404, such as media items, application programs, personal data, and / or operating system programs. Synchronization operations may be performed in response to an explicit user request and / or automatically, e.g., when wireless device 400 resumes communication with a particular host device, or in response to any device receiving an update of its copy of the synchronized information.The environmental sensors 414 can include various electronic, mechanical, electro-mechanical, optical, or other devices that provide information regarding external conditions in the environment of the wearable device 400. In some embodiments, the sensors 414 may provide digital signals to the processing subsystem 402, e.g., on a streaming basis or as desired in response to polling by the processing subsystem 402. Any type and combinations of environmental sensors may be used; an accelerometer 442, a magnetometer 444, a gyroscope 446, and a GPS receiver 448 are shown by way of example.Some environmental sensors may provide information regarding the location and / or movement of the wearable device 400. For example, accelerometer 442 may sense acceleration along one or more axes (relative to free fall), e.g., using piezoelectric or other components in conjunction with associated electronics, to generate a signal. Magnetometer 444 may sense an ambient magnetic field (e.g., the earth's magnetic field) and generate a corresponding electrical signal that may be interpreted as a compass direction. The gyroscope sensor 446 may sense rotational motion in one or more directions, e.g., using one or more MEMS gyroscopes (MEMS= Mikroelektro System) and associated control and sensing circuitry. The global positioning system (GPS) receiver 448 may determine a location based on signals received from GPS satellites.Other sensors may also be included in addition to or instead of these examples. For example, a sound sensor may include the microphone 426 along with associated circuitry and / or program code to determine, e.g., a decibels level of the ambient sound. Temperature sensors, proximity sensors, ambient light sensors, or the like may also be included.The strap sensors 416 may include various electronic, mechanical, electro-mechanical, optical, or other devices that provide information regarding whether the wearable device 400 is currently being worn. In some embodiments, certain features of the wearable device 400 may be selectively activated or deactivated depending on whether the wearable device 400 is currently being worn.The power subsystem 412 may provide power and power management capabilities to the wearable device 400. For example, the power subsystem 414 may include a battery / battery 440 (e.g., a rechargeable battery) and associated circuitry to distribute power from the battery / battery 440 to other components of the wearable device 400 that require electrical power. In some embodiments, the power subsystem 412 may also include circuitry operable to charge the battery / battery 440 when the connector interface 410 is connected to, e.g., a power source. In some embodiments, the power subsystem 412 may include a "wireless" charging unit, such as an inductive charging unit, to charge the battery / battery 440 without resort to the connector interface 410. In some embodiments, the power subsystem 412 may also include other power sources, such as a solar cell, in addition to or in place of the battery / battery 440.In some embodiments, the power subsystem 412 may control power distribution to components within the wearable device 400 to efficiently manage power consumption. For example, the power subsystem 412 may automatically place the device 400 in a sleep state when the belt sensors 416 or other sensors indicate that the device 400 is not being worn. The sleep state may be designed to reduce power consumption; accordingly, the user interface 406 (or components thereof), the RF interface 408, the connector interface 410, and / or the environmental sensors 414 may be down-regulated (e.g., to a low power state or fully powered off) while the strap sensors 416 are powered on (either continuously or at intervals) to detect when a user is applying the wearable device 400. As another example, in some embodiments, while wearable device 400 is worn, power subsystem 412 may turn on or off display 420 and / or other components depending on the movement and / or orientation of wearable device 400 detected by environmental sensors 414.The power subsystem 412 may also provide other power management capabilities, such as controlling the power consumption of other components of the wearable device 400 based on the source and amount of available power, monitoring power stored in the battery / battery 440, generating user alarms if the stored power falls below a minimum level, and so forth.In some embodiments, control functions of power subsystem 412 may be implemented using programmable or controllable circuitry that operates in response to control signals generated by processing subsystem 402 in response to program code executed therein, or that operates as a separate microprocessor or microcontroller.It will be appreciated that the wearable device 400 is illustrative and variations and modifications are possible. For example, the strap sensors 416 may be modified and the wearable device 400 may include a user operable control element (e.g., a button or button or switch) that the user may actuate to provide input. Controls may also be provided to, e.g., turn display 420 on or off, mute or actively switch sounds from speaker 422, etc. Wearable device 400 may include any types and combinations of sensors, and in some cases may include multiple sensors of a particular type.In various embodiments, a user interface may include any combination of any or all of the components described above, as well as other components not expressly described. For example, in some embodiments, the user interface may include only one touch screen or touch screen, and a speaker or touch screen and a haptic device, for example. If the wearable device has an RF interface, a connector interface may be omitted, and all communication between the wearable device and other devices may be performed using wireless communication protocols. A wired power connection, e.g., for charging a battery of the wearable device, may be provided separately from a data connection.While the wearable device is further described with reference to particular blocks, it should be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. Further, the blocks need not correspond to physically separate components. The blocks may be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry, and various blocks may or may not be reconfigurable depending on how the initial configuration is obtained. Embodiments of the present invention may be implemented in a variety of devices, including electronic devices implemented using any combination of circuitry and software. Moreover, each block in FIG. 4 is not required to be implemented in a given embodiment of a wearable device.A mobile device, such as mobile device 302 of FIG. 3, may be implemented as an electronic device using blocks similar to those described above (e.g., processors, storage media, user interface devices, data communication interfaces, etc.) and / or other blocks or components. FIG. 5 is a simplified block diagram of a wearable device 500 (e.g., implementing the wearable device 302 of FIG. 3 ) according to an embodiment of the present invention. Mobile device 500 may include a processing subsystem 502, a storage subsystem 504, a user interface 506, an RF interface 508, a power subsystem 512, and environmental sensors 514. Mobile device 500 may also include other components (not explicitly shown). Many of the components of the mobile device 500 may be similar or identical to those of the wearable device 400 of FIG. 4.For example, the storage subsystem 504 may be generally similar to the storage subsystem 204 and may include, e.g., using magnetic storage media, flash memory, other semiconductor memory (e.g., DRAM, SRAM), or other non-transitory storage medium, or a combination of media, and may include volatile and / or non-volatile media. Like the storage subsystem 404, the storage subsystem 504 may be used to store data and / or program code to be executed by the processing subsystem 502.The user interface 506 may include any combination of input and output devices. A user may operate input devices of the user interface 506 to invoke functionality of the mobile device 500, and may view, listen, and / or otherwise perceive output from the wearable device 500 via output devices of the user interface 506. Examples of output devices include a display 520, speakers 522, and a haptic output generator 524. Examples of input devices include a microphone 526, a touch-sensitive sensor 528, and a camera 529. These input and output devices may be similar to the output devices described above with reference to FIG. 4.Processing subsystem 502 may be implemented as one or more integrated circuits, e.g., one or more microprocessors or microcontrollers having one core or more cores, examples of which are known in the art. In operation, the processing system 502 may control the operation of the mobile device 500. In various embodiments, processing subsystem 502 may execute a variety of programs in response to program code and maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed may reside in processing subsystem 502 and / or in storage media such as storage subsystem 504.By suitable programming, processing subsystem 502 may provide various functionalities for mobile device 500. For example, in some embodiments, processing subsystem 502 may execute operating system (OS) 532 and various applications 534, such as a telephone interface application, a text message interface application, a media interface application, a fitness application, and / or other applications. In some embodiments, some or all of these application programs may interact with a wearable device, e.g., by generating messages to be sent to the wearable device and / or by receiving and interpreting messages coming from the wearable device. In some embodiments, some or all of the application programs may operate locally on the wearable device 500.Processing subsystem 502 may also execute a playback transfer coordination code 536 (which may be part of OS 532 or separate, as desired). In some embodiments, executing the playback transfer coordination code 536 may cause the mobile device 500 to receive a broadcast search message from a host device (e.g., the wearable device 300 of FIG. 3 ), determine current characteristics of the mobile device 500 (e.g., power source, battery or battery charge (if appropriate), strength of a WLAN network, whether a particular song or audio collection can be accessed, whether the particular song or audio collection is available in local memory, device type and / or strength of a connection to a speaker), and respond to the broadcast message with some or all of the determined characteristics. Executing the playback transfer coordination code 536 may further cause the mobile device 500 to receive a transfer preparation message (e.g., indicating what to play and when to begin playing) from a main device (e.g., the wearable device 300 of FIG. 3 ) to access the corresponding music and begin playing the music at the appropriate time. In some cases, executing the playback transfer coordination code 536 may further cause the mobile device 500 to then monitor its playback and / or begin searching for other devices to possibly take over the playback.The RF (radio frequency) interface 508 may allow the mobile device 500 to wirelessly communicate with various other devices and networks. The RF interface 508 may include RF transceiver components, such as an antenna and auxiliary circuitry, to enable data communication over a wireless medium, e.g., using mobile voice and / or data networks, WLAN (IEEE 802.11 family standards), Bluetooth® (a family of standards promulgated by the Bluetooth SIG, Inc.), or other wireless data communication protocols. In some embodiments, the RF interface 508 may implement a Bluetooth Low Energy (LE) proximity sensor 509 that supports proximity sensing by estimating signal strength and / or other protocols for determining proximity to another device. In some embodiments, the RF interface 508 may provide near field communication (NFC) capability, e.g., implementing the ISO / IEC standards 18092 or the like; NFC may support wireless communication between devices over a very short range (e.g., 20 cm or less). The RF interface 508 may be implemented using a combination of hardware (e.g., driver circuits, antennas, modulators / demodulators, encoders / decoders, and other analog and / or digital signal processing circuits) and software components. Several different wireless communication protocols and associated hardware may be included in the RF interface 508.The environmental sensors 514 may include various electronic, mechanical, electro-mechanical, optical, or other devices that provide information regarding external conditions in the environment of the wearable device 500. In some embodiments, the sensors 514 may provide digital signals to the processing subsystem 502, e.g., on a streaming basis or as desired in response to polling by the processing subsystem 502. Any type and combinations of environmental sensors may be used; an accelerometer 542, a magnetometer 544, a gyroscope 546, and a GPS receiver 548 are shown by way of example. These sensors may operate similarly to corresponding sensors in the wearable device 400 described above. Other sensors may also be included in addition to or in place of these examples, such as temperature sensors, proximity sensors, ambient light sensors, ambient sound sensors (or noise sensors), or the like.The power subsystem 512 may provide power and power management capabilities to the mobile device 500. For example, the power subsystem 512 may include a battery / battery 540 (e.g., a rechargeable battery) and associated circuitry to distribute power from the battery / battery 540 to other components of the mobile device 500 that require electrical power. In some embodiments, power subsystem 512 may also include circuitry operable to charge battery / battery 540 when an electrical connector (not shown) is connected to a power source. In some embodiments, power subsystem 512 may include a "wireless" charging unit, such as an inductive charging unit, to charge battery / battery 540 without resort to a physical connector. In some embodiments, the power subsystem 512 may include other power sources, such as a solar cell, in addition to or in place of the battery / battery 540.In some embodiments, the power subsystem 512 may control power distribution to components within the mobile device 500 to efficiently manage power consumption. For example, when the mobile device 500 is in an inactive state (not interacting with a user), the power subsystem 512 may place the device 500 in a low power state by, e.g., disabling various components of the user interface 506, the RF interface 508, and / or the environmental sensors 514. The power subsystem 512 may also provide other power management capabilities, such as regulating the power consumption of other components of the mobile device 500 based on the source and amount of available power, monitoring power stored in the battery / battery 540, generating user alarms if the stored power falls below a minimum level, and so forth.In some embodiments, control functions of power subsystem 512 may be implemented using programmable or controllable circuitry that operates in response to control signals generated by processing subsystem 502 in response to program code executed therein, or that operates as a separate microprocessor or microcontroller.It will be appreciated that the mobile device 500 is illustrative and that variations and modifications are possible. In various embodiments, further components may be provided in addition to or instead of those described above. Any device capable of interacting with another device to coordinate rendering as described herein may be a mobile device.Further, while the mobile device is described with reference to particular blocks, it should be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. Further, the blocks need not correspond to physically separate components. The blocks may be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry, and various blocks may or may not be reconfigurable depending on how the initial configuration is obtained. Embodiments of the present invention may be implemented in a variety of devices, including electronic devices implemented using any combination of circuitry and software. In addition, each block in FIG. 5 is not required to be implemented in a given embodiment of a mobile device.While FIGS. 3-5 illustrate characteristics of a wearable device and a mobile device, it will be appreciated that a device need not be mobile, and may nevertheless share a characteristic as described with respect to a wearable device or mobile device. For example, a desktop computer may include components shown in FIGS. 3, 4, and / or 5. Further, the disclosure herein may refer to any of a first device, second device, main device, interface device, or playback device. Each of such devices may include a characteristic described with respect to a body-wearable device of a mobile device, even if it is not itself wearable or mobile.Communication between a mobile device and a wearable device may be implemented according to any communication protocol (or any combination of communication protocols), upon use of which both devices are programmed or otherwise configured. In some cases, standard protocols such as Bluetooth protocols may be used. In some cases, a user-defined message format and syntax may be defined (including, e.g., a set of rules for interpreting particular bytes or sequences of bytes in a digital data transmission), and messages may be transmitted using standard serial protocols, such as a virtual serial port defined in particular Bluetooth standards. Embodiments of the invention are not limited to particular protocols, and those skilled in the art having access to the present teachings will recognize that numerous protocols may be used.According to certain embodiments of the present invention, devices (e.g., wearable device 300 and mobile device 302) may communicate such that a playback of an audio collection is smoothly transferred between the devices to advantageously utilize respective capabilities available at each device.FIG. 6 is a flow diagram of a process 600 for transferring audio playback between devices according to an embodiment of the present invention. Portions of the process 600 may be implemented in a first electronic device, while other portions may be implemented in a second electronic device. As a particular example, the first device may include the wearable device 300 and the second device may include the mobile device 302. However, it will be appreciated that a portion of the dynamic transfer benefit is that each device (e.g., depending on its current situation and / or rule) may be either the first or second device. Further, a single device may be each of the first and second devices at any given time. For example, mobile device 302 may first take a playback from wearable device 300 and may later transfer the playback to another device.In some cases, process 600 may begin after a set of devices are paired together and a user has requested (via an interface of a device) that music be played. For example, the user may have to open an app, select a song, playlist, or playback option. This request may be received at a first device. At block 600, the first device identifies an audio collection. The audio collection may include, for example, a playlist, a song, a portion of the song, an online radio station, or a podcast. The collection may be identified based on a selection from a user (e.g., a selected playlist), a selection from a remote system (e.g., operating an online radio station), and / or a previous playback station (e.g., such that playback is resumed where playback has previously stopped). The identification may be performed by searching a local or remote data store and / or by receiving a message coming from a remote system.In block 610, the first device begins playing the audio collection. The audio collection may be played through a speaker on the first device, through an audio jack receiving an audio cable connected to a speaker, or via a wireless communication to a speaker. The first device may select a speaker based on, e.g., a stored hierarchy or default setting, available speakers, and / or a user preference. Playing the audio collection may include retrieving and / or receiving (e.g., once, periodically, or continuously) music in the collection (e.g., from a local data store, a remote data store, or a message from a third party system).In block 615, a playback unit identifier rule is accessed. This rule may indicate how to select from devices to identify a playback device. The rule may include, for example, a formula, a hierarchy, each of which may receive characteristics of a device to determine whether the device is to be made a playback device. For example, a rule may include a score distribution formula including weights for each of: whether a device is plugged in, a strength of a WLAN connection of a device, and a distance between the device and the first device. The rule may indicate that the formula is to be applied to each detected device (e.g., including the first device and each of one or more second devices), and that the device with the highest score is to be a playback device. As another example, a rule may include a hierarchy indicating that computers are to be playback devices in front of mobile phones and mobile phones are to be playback devices in front of a wearable device. As another example, a rule may include a schedule that first requires a device to have access to the audio collection, and then identifies the device as a playback device when its battery or battery size (or remaining battery or battery capacity) exceeds that of the first device. In some cases, a rule includes a consistency factor that weights towards the device that plays music.The rule may be fixed or customizable by a user. For example, a user may identify a device hierarchy and specify particular devices that are never (or always) to take over as a playback device. In some cases, a same rule may be shared across devices so that playback device names are consistently assigned.At block 620, the first device may detect whether a second device is in a nearby environment. In a particular case, this sensing effort may involve sensing a paired device with which the first device may communicate via a short-range communication (e.g., Bluetooth or BTLE). In a particular case, this sensing effort may involve sensing a paired device that is within a specified distance from the first device. This detection may be enabled, for example, by tracking a location of the device within a pairing network using the GPS receivers of the devices and a WLAN network, or by using BTLE proximity detection protocols.At block 625, the second device may send one or more properties to the first device, and the first device may receive the properties at block 630. The properties can be obtained by push or pull transmission coming from the second device. For example, a first device may obtain properties by pull transmission (e.g., via broadcast message requesting information from the second device) at routine intervals or upon detecting degradation in a property of the first device. In some cases, the characteristics will be obtained in block 610 in response to receiving an initial input requesting music playback or after beginning playback of the audio collection by pull-transfer. The characteristics may include an indication of the location of the second device, power source, battery or battery charge, strength of a network connection, total processing power, current CPU utilization, and / or speaker inclusion. The properties may include information about a song access, such as which songs, playlists, or other audio collections are stored locally on the second device, or which remote audio collection data stores the second device has access to.In block 635, it is determined whether the second device is to be designated as a playback device. This determination may be made by evaluating the received properties using the rule. The assessment may involve a comparative assessment (e.g., compare multiple second devices and / or compare a second device to the first playback device). For example, the assessment may involve identifying a device having a highest score that is based on the characteristics. It will thus be appreciated that corresponding properties of the first device and / or one or more further, second devices may also be collected and analysed in order to carry out this comparison.If the second device is not to be termed a playback device, the process 600 returns to block 620, where another second device may be analyzed or changed characteristics (e.g., the same second device or the first device or the other devices may be considered in a comparative analysis). If the second device is to be called a playback device, the process 600 continues to blocks 640 and 645 where the first device may send playback information to the second device and the second device may receive the playback information. The playback information may include information that enables the second device to seamlessly take over the playback. For example, the playback information may include an identifier of a song and a playback position within a song (e.g., whether to transfer the playback during playback of the song), or an identifier of a playlist and a playback position within a playlist (e.g., whether to transfer the playback between songs or during a song). The second device may then access the song or playlist and continue to play. As another example, the playback information may include an identifier of an online radio station and / or a user identifier such that the second device may begin streaming of the corresponding music. As another example, the playback information may include a characteristic of music such as a genie or artist, so that the second device may search for a song corresponding to the characteristic to continue playback. The playback information may further include a time at which the second device is to take over the playback. However, in some cases, a default assumption may be used for such a time setting (e.g., an immediate takeover). The playback information may further include a tone setting such as a volume.At block 650, the second device may use the characteristics to identify the audio collection. It will be appreciated that this identification may include identifying a song corresponding to a song played at the first device. In a particular case, the song is the same, and the audio collection identified in block 650 corresponds to a later portion of the song relative to that already played. In a particular case, the songs are on the same playlist or belong to the same genus. In a particular case, the songs are from the same online music station, so the identification in block 650 includes identifying the station. Thus, the collection identification in block 650 may include an identification that allows the second device to determine which music to begin playing, such that, given (for example) an applicable or selected playlist, style preference, song selection, or station selection, the music playing transferred from the first device is substantially consistent.Upon identifying the audio collection, in block 655, the second device accepts the playback of the music at substantially the same time that the first device stops playing the music. In some cases, there may be a small transition window during which both devices play music (e.g., the same music) simultaneously, and a volume of the first device's play may be hidden when a volume of the second device's play is hidden. The playback may begin at a position within the collection as identified in the playback information received at block 645. For example, the playback information may include an indication to begin playback of song no. 4 (from playlist no. 5) at time 1:32 in the song at 15:20 o'clock. The song can be reproduced accordingly.The playback at block 655 may also match the playback at block 610 in non-content-related characteristics. For example, the reproduction information may include a volume, balance, or a filter to be applied. The second device may then adjust any settings or filtering to provide a consistent sound during playback transfer.The second device may play music using its local speakers, audio jack, or wireless connection. The second device may play music using the same speakers used by the first device, or may independently select speakers to be used (e.g., using a stored hierarchy or default setting, available speakers, and / or a user preference). Playing the audio collection may include retrieving and / or receiving (e.g., once, periodically, or continuously) music in the collection (e.g., from a local data store, a remote data store, or a message from a third party system).While process 600 illustrates a situation where a first device judges a single second device for takeover, it will be appreciated that the process could be modified such that multiple second devices are detected, characteristics are received from each second device, and then all second devices are evaluated in comparison.Process 600 may also be modified so that the second device makes the determination as to whether the playback is to be transferred. For example, a first device may use a technique for calculating a rendering score that depends on its characteristics (e.g., remaining battery / battery charge and / or strength of a network connection). The first device can then emit the score. Every other device that receives the broadcast can itself similarly calculate a playlist based on its own characteristics. If a given second device determines that its score exceeds that of the first device, it may respond to the first device (e.g., with its score). In a particular case, the first device may then compare all received scores and send playback information to the second device having the highest score. In a particular case, the first device sends playback information to the first responding second device.In a particular case, block 605 occurs in response to the first device receiving an input corresponding to a request to play music. Process 600 then indicates that the same device that received the input initially plays at least some music. In some cases, the first device immediately judges other nearby devices to identify a playback device, and does not need to playback any music itself.Process 600 allows music to be transferred smoothly between devices. Thus, music playback can be seamlessly transferred to devices with desired connectivity and / or performance conditions, music access conditions, and / or speaker connections without disrupting the user's music consumption. Although not shown, it will be appreciated that the process may be extended such that the second device performs equivalents of blocks 615, 630, 635, 640 and 660 and a third device performs equivalents of blocks 625, 645, 650 and 655. That is, regardless of which device is a reproduction device, each device may serve as a main device to rejudge whether the reproduction should be transferred to another device.Dynamic master device naming offers advantages. For example, when a master device is defined as a playback device, it can quickly detect potential performance degradations and begin searching for a new device to take over the playback. Such a definition, however, has several other potential disadvantages. While individual device takes-overs may be constrained based on effective distance constraints (e.g., Bluetooth connections) when the master device is relayed from device to device, there is a possibility that a rendering and master device may be quite disconnected from a user that initiated the rendering. Further, a takeover analysis may use resources of a device that might otherwise be concentrated on music playback.An alternative strategy is to use a main static device. The master device may include a device where playback was first initiated (e.g., a wearable device), a fixed device (e.g., fixed via a stored setting or a setting received upon input), or a remote system. Regardless of which device is selected, the label may remain fixed during a given playback session. The master device can coordinate playback transfers by sending messages not only to a device that is to take the playback but also to a device that is to end the playback.FIG. 7 is a flow diagram of a process 700 for coordinating transfer of audio playback between devices at a master device, in accordance with an embodiment of the present invention. A host device may include any device configured to make determinations about device playback actions, such as whether a playback takeover is to occur, which device is to take the playback, when the takeover is to occur, and / or whether the playback is to continue. These determinations need not be definitive (e.g., a user may be able to override a proposed transfer) or sufficient for a playback takeover (e.g., confirmation by a user may be required) in some embodiments. In some embodiments, no such conditions are available and takeovers proceed automatically following their identification. A master device designation may be fixed or temporary.For example, in a certain case, a main device may always be the wearable device 300. In a further case, the device which is currently playing music is always the main device.Blocks 705 and 710 of process 700 may correspond to blocks 605 and 610 of process 600. Generally, the master device may identify what to play (e.g., in response to an input corresponding to a playback request) and accesses a rule indicating which device to select to play at least a portion of the audio collection.At block 715, one or more devices may be identified. The identified devices may include a playback device and may include the master device itself. The identified devices may be those within a geographic region (e.g., centered on a location of a device, such as the wearable device) or paired and connected (e.g., via a Bluetooth connection) to a playback device (e.g., a wearable device, a playback device, or the master device). In a particular case, the identified devices may include those that respond to a broadcast message sent by the master device. In a particular case, the master device may send communication requests to each device in a set of devices (e.g., a set of paired devices), and the identified devices include those that respond to the requests.At block 720, the master device may identify one or more properties for each identified device. The properties may be included in a message sent by the device in response to a broadcast message or communication request. The characteristics may include an indication of device location, power source, battery or battery charge, network connection strength, total processing power, current CPU utilization, and / or speaker inclusion. The properties may include information about a song access, such as which song playlists or other audio collections are stored locally on the second device, or which remote audio collection data storage the device has access to.At block 725, the host device may select one of the identified devices as a potential playback device. The selection may be made by assessing the identified properties using the rule. The assessment may involve a comparative assessment (e.g., comparing properties across multiple identified devices). In a particular case, all identified devices may be simultaneously compared (e.g., by comparing a score). In a particular case, comparisons are made in pairs (e.g., comparing each non-playback device to a playback device). A potential playback device may then be identified as a first device that exceeds the playback device in comparison, or all such exceeding devices may be compared sequentially.At block 730, a determination may be made as to whether the selected potential playback device is different from a current playback device. If not, the process 700 may return to block 715, where device sets and characteristics may be monitored. Monitoring may continue immediately after a fixed duration or upon receiving an alarm (e.g., from a first device, the alarm indicating that a property or rendering score has fallen below a threshold).If the selected potential playback device is different from a current playback device, the process 700 proceeds to block 735 where a takeover alert is generated and caused to be issued. The alarm may be output to a user on an interface device, and the alarm (or information associated with the alarm) may be sent to an interface device (e.g., if the interface device is different from the master device). For example, in a particular case, the main device may cause a user (e.g., via a playback device or other device) to issue an alarm indicating that playback transfer is imminent and identifying the potential playback device. The alarm may also include characteristics of the potential playback device that caused it to be selected. The alarm may include a deselect option so that the user may prevent the potential playback device from assuming playback.At block 740, a determination is made as to whether a takeover by the potential playback device has been rejected. The determination may depend on an input from a user or its absence (e.g., identified based on a message from an interface device). For example, a default setting may be that potential transfers are to be performed in the absence of opposing user instructions.If it is determined that the potential transfer was rejected, the host device may end takeover preparations. Instead, the process 700 may return to block 715, where device sets and characteristics may be monitored. The deselect option may impose restrictions on a future selection of potential playback devices (e.g., permanently or within a playback session), such as preventing future selection of the previously selected device. (In even more extreme cases, a rejection may indicate that no transfer has to occur during a playback session or globally, in which case process 700 ends.)If the proposed playback transfer is not rejected, the master device may identify the potential playback device as the new playback device and may send playback information to it in block 745 (e.g., as described in corresponding block 640 in process 600). Further, the master device of the old reproduction device 750 may transmit a termination message. The termination message may include a time to stop playing music (or to fade out its music playing). Thus, the new reproduction apparatus can start reproducing music when the old reproduction apparatus stops reproducing music. It will be appreciated that in the event that the master device is the old or new playback device for a particular playback transfer process, a completion or playback information message may be omitted in favor of causing the playback to stop or begin. Process 700 may then return to block 715 where device sets and characteristics may be monitored.It will be appreciated that in some cases the potential playback device may have the opportunity to reject a proposed playback transfer. The master device may send a message to the potential playback device indicating a plan or request to reject the playback from being transferred to the potential playback device. This message may be separate from or combined with one including the playback information. In some cases, process 700 may require the potential playback device to respond to the message before proceeding to a playback transfer plan. In some cases, the process 700 may proceed to a playback transfer plan as long as no rejection response is received. Any such strategy may give the potential rendering device the opportunity to weight factors such as current processing load, rankings of items being processed currently, and / or access to Song.FIG. 8 is a flow diagram of a process 800 for responding to playback inputs in a distributed device playback network, in accordance with an embodiment of the present invention. The process 800 may be implemented in one or more interface devices. An interface device may include any device configured to receive and make inputs that control the playback of an audio collection. The interface device may include, for example, a playback device, a device where playback of an audio collection was initiated, or another device in communication with a playback device. In some cases, multiple interface devices are present in a local area network of devices such that each interface device is configured to receive input and communicate action commands to a playback device that plays an audio collection. For example, blocks 805-830 may be performed by a wearable device 300 and blocks 835-840 may be performed by a mobile device 302.At block 805, an interface device may receive an initial playback input. The input may correspond to a request to begin playing music. The input may indicate particular music to be played (e.g., song in a library, a stored playlist, or an online radio station) or restrictions on music (e.g., genre or artist).An audio collection may be identified in block 810, which may correspond to block 605 of process 600 and / or block 705 of process 700. A potential playback device may be identified at block 815. Analyses contributing to the selection may correspond to those discussed herein (e.g., with respect to block 635 of process 600 or block 725 of process 700).In block 820, the interface device may cause a notification to be generated and issued identifying a potential playback transfer. The notification may identify a current playback device and / or the potential playback device. The notification may use a speaker used by the current playback device to play music and / or a speaker predicted to be used by the potential playback device to play music. The notification may include one or more characteristics of each of the current playback device and the potential playback device (e.g., a battery or battery charge, power source, location, and / or strength of a network connection). The notification may include an estimate of a duration of time during which the current playback device will be able to continue playback based on its battery or battery charge.The notification may include a user input option such that a user may accept or reject the potential playback transfer. A default selection may be used in the absence of a response (e.g., such that the potential transfer is performed if not rejected or vice versa). In some cases, a user may select an accept or reject option on a screen and such input is conveyed back to the interface device.The interface device may estimate whether the proposed playback transfer has been accepted, at block 825. In some cases, if the interface device has not received a rejection indication, it may assume that the potential playback transfer has been accepted.If it is determined that the transfer has not been accepted, the process 800 may return to block 815, where devices may be monitored and a new selection of a potential playback device may be made, if appropriate.If it is determined that the transfer has been accepted, the interface device may identify the potential playback device as the new playback device and may send playback information to it at block 830 (e.g., as described at corresponding block 745 of process 700 and block 640 at process 600). The new playback device may then take over the playback as described herein.At block 835, the interface device may receive an input corresponding to a playback action. For example, the input may correspond to a playback, fast-forward, jump, rewind, pause, or stop command. As another example, the input may correspond to a selection of a playlist, a genres, an artist, a song, or a location within a song.Playback action information based on the input may be sent to a playback device in block 840. In some cases, the interface device queries a master device to identify a current playback device. In some cases, the interface device receives and stores an identification of each new playback device so that it can identify the current playback device. The reproduction device may then control the reproduction according to the information.For example, the music reproduction may be stopped or resumed appropriately, or a new song may be selected for reproduction.Thus, although music playback can be dynamically transferred between devices, a user can continue to interact with the same device or any convenient device and playback actions are applied accordingly.Structures of many audio collections provide a predictable nature as to which particular audio segments are played back at a particular time. For example, when reproduction of a song begins at 13:00 for 5 minutes, it can be predicted that at 13:02, reproduction is in the song for 2 minutes. Using this information, a transfer coordinating device may provide playback information indicating where within an audio collection a post transfer playback device should begin playback. User initiated playback actions (e.g., jumps to the next song or pauses) or buffering may interrupt this predictableness. Therefore, in some cases, a main device keeps track of the actual reproduction progress. The master device may be prepared to identify a playback location for another device that will take over the playback of the song. The master device may track progress by receiving messages from a playback device (e.g., periodically identifying a playback location or reporting a buffer delay or playback action) and / or from an interface device (e.g., identifying a buffer or playback action).Playback transfers can allow for longer music playback sessions. However, since many devices move in and out of a certain area, the question arises where to maintain the reproduction. FIG. 9 is a flow diagram of a process 900 for responding to device motion according to an embodiment of the present invention. A portion or all of the process 900 may be implemented in a main device or a playback device.The process 900 begins at block 905 where a determination may be made as to whether a device is moving. The device being evaluated may include a playback device, a device that initiated playback, a wearable device, or any device that communicates over a short range connection (e.g., Bluetooth or BTLE) within a paired network that plays music. The assessment may include using a reading from a sensor, such as an accelerometer or GPS receiver. The assessment may include using a bond strength. Thus, for example, two devices or one device and one loudspeaker may be connected via a Bluetooth connection. Changes in connection strength may indicate motion. The change may be detected at a moving device or at a device paired with the moving device.If no movement is detected, judgments can be made on the current playback device and / or on a normal takeover. If it is determined that a device is moving, a determination may be made at block 910 as to whether playback should continue.The playback continuation determination may be based on an application of a rule. The rule may identify a playback continuation result that depends on one or more of the following factors: which type of device is moving (e.g., a tablet, wearable device, etc.), whether the moving device has initiated playback, whether the moving device is a current playback device, whether (and / or how many) other paired devices are in communication with a speaker, whether a speaker that is currently playing music is the same speaker that has played music initially during the playback session, and a duration of the playback session that has occurred. For example, a rule may indicate that playback is to continue as long as another paired device remains connected to a speaker that initially issued the music during a playback session.The playback continuation determination may be based on a user preference. The preference may include, for example, a setting generally related to playback situations or input. For example, upon detecting that a device is moving, the master device may cause a notification to be presented via a device interface (e.g., a moving device or master device interface). A user may then respond to the notification with a request to end the playback session or continue playback, in which case the user may (in some cases) even identify which device is to playback music.If it is determined to continue playback, a playback location may be determined in block 915. The reproduction location need not be a geographical location, but may also be relative to a device. That is, in some cases, an affirmative answer to block 905 may indicate that a particular device is moving away from another device. Then, the question arises whether the reproduction is to follow the moving device or remain at the stationary device. The determination may depend on one or more of the following factors: which type of device is moving (e.g., a tablet, a wearable device, etc.), which device initiated playback (e.g., a device that is now moving, or one that is stationary), whether the moving device is a current playback device, whether a speaker is moving, whether (and / or how many) other paired devices are in communication with a speaker, whether a speaker that is currently playing music is the same speaker that was initially playing the music during the playback session, and a duration of the playback session that has occurred. For example, a playback location may follow the moving device when it has initiated playback and / or when a speaker is moving with the moving device. In some cases, the playback location is determined based on user input (e.g., identifying a device to play music).At block 920, one or more devices within the playback location are identified. In a particular case, the playback location includes the location of a particular device. The devices identified in block 920 include devices paired with the particular device and connected via a short range connection (e.g., Bluetooth or BTLE).Blocks 925, 930, and 935 may correspond to blocks 720, 725, and 745 in process 700. Generally, a playback device may be selected among the identified devices based on device characteristics and a rule (e.g., prefer devices with a longest remaining battery / battery life). If the selected device is different from a current playback device, playback information may be caused to be transmitted to the selected playback device at block 935.The following examples provide illustrations of how devices may interact to enable continuous music playback.Example 1At a wearable device, a user may initiate a playlist playback. Both the playlist and the song of the playlist may be stored in the cloud. The wearable device may access the cloud and begin to communicate song from the playlist to a wireless independent speaker. The wearable device may emit a broadcast signal to detect other devices. A nearby inserted tablet device may receive the signal and respond with its characteristics (e.g., being a tablet and having an AC power source). A rule may indicate that the playback is to be transferred to any responding device with an AC power source. The wearable device can thus determine that the reproduction is to be transferred to the tablet. The wearable device may send a play transfer message to the tablet identifying the playlist, a location within the playlist, and a volume setting. The tablet can then begin playing at the position at the time of takeover. It can adjust its own volume setting accordingly so that the volume of played-back song matches that of the playback of the wearable device.At the time of takeover, the wearable device may stop playing the playlist. However, the wearable device may still receive input (e.g., user input) corresponding to a request for a playback action and communicate information about such actions to the tablet so that they may be implemented.Example 2Following Example 1, the tablet may begin to move and approach an edge of a region of a speaker. The tablet may detect an attenuating connection and / or motion and may alert the wearable device (e.g., due to being a main device or a playback initiation device) to be about to leave the area of the speaker. The alarm may identify a location within a playlist and a short-term retransmission time. At the short term play transfer time, the tablet may stop playing and the wearable device may begin to communicate music corresponding to the position in the playlist to the wireless speaker.Example 3Following Example 1, the tablet may begin to move and approach an edge of a region of a speaker. The wearable device may detect an attenuating connection and / or motion and alert the tablet (e.g., due to being a playback device) that it is about to leave the area of the speaker. An alarm may be issued on one or both of the wearable device or the tablet, the alarm indicating that playback using the tablet will proceed unless a prompt is received. If no challenge is received, the tablet may continue to play. The wearable device may then stop accepting input regarding the playback.Example 4Following Example 1, the tablet may detect an attenuating connection with the wearable device. The tablet may send a playback transfer request having a position within the playlist and a short-term playback transfer time to the wearable device. At the short term play transfer time, the tablet may stop playing and the wearable device may begin to communicate music corresponding to the position in the playlist to the wireless speaker.Embodiments of the present invention may enable user interaction with one or more devices by providing a user with a longer music playback because the device combining capabilities may be optimally utilized. Although it may be convenient for a user to interact with a particular device, that device may lack the hardware or connection needed to maintain continuous music playback. Meanwhile, techniques described herein may still recruit one or more devices to participate in the requested playback, thereby gaining both user convenience of the device interacting with the user and battery or battery power or network connection of another device. While some embodiments provide a user (via an interface) with notifications of playback transfers and the opportunity to reject such transfer, one advantage of the technique is that it may occur automatically, quietly, and repeatedly. Thus, a user need not be involved in each device transfer and may instead only enjoy enhanced music reproduction.Although the invention has been described with reference to specific embodiments, those skilled in the art will recognize that numerous modifications are possible. For example, the sensors described herein may be replaced with other sensors or combinations of sensors. A variety of different mobile devices and wearable devices may be used.Embodiments described above assume that pairing or other connection has been established that allows the devices to recognize each other as devices authorized to cooperate. This may reduce the likelihood that a device will be automatically activated or used as a playback device as a result of communication with a device unauthorized by the user. For additional security, the communication session established between the devices may be secured. Some embodiments depicted or described herein relate to a simple banded smart wearable device. It will be appreciated that the embodiments may be modified to relate to other devices, such as a mobile device or a wearable device (e.g., smart glasses, smart hearing elements, smart earphones, smart watch, smart bracelet, and the like).It will be appreciated that techniques described herein may be applied beyond the scope of playing music. As a particular example, embodiments may extend to cross-device coordinated playback of any audio collection (e.g., a listenbook or a podcast). As another example, embodiments may extend to cross-device coordinated playback of a video collection. A user may initiate a playback of a movie on his wearable device. The wearable device may identify the movie (e.g., from local storage, remote storage, stream, etc.), retrieve, download, or receive a portion or all of the movie, and output the movie to a television or projector. The wearable device can then transfer the display of the film to another device, which can output it to the same television or projector. As yet another example, embodiments may extend to cross-device coordinated processing. To illustrate, a processing request after performing a very compute intensive task may be transferred to another device having a more powerful processor, parallel processing capability, stable and / or higher remaining or total battery size or battery charge (e.g., an AC power source). As a further illustration, a processing request may be transferred to another device with access to software for more efficiently responding to the request.The foregoing description may refer to specific examples of a wearable device and / or a mobile device (e.g., a mobile phone or smart phone). It should be understood that these examples are illustrative and not limiting; other devices may instead be employed and implement similar function blocks and / or algorithms to perform operations and / or other operations described herein. Further, some or all of the playback devices may be non-portable and / or non-mobile.Embodiments of this invention, e.g., in methods, apparatus, computer readable media, and the like, may be implemented using any combination of dedicated components and / or programmable processors and / or other programmable devices. The various processes described herein may be implemented on the same processor or on different processors in any combination. When components are described as being configured to perform certain operations, this configuration may be achieved, for example, by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as microprocessors) to perform the operation, or by any combination thereof. Further, although the embodiments described above may reference specific hardware and software components, those skilled in the art will appreciate that other combinations of hardware and / or software components may also be used, and that certain operations described as implemented in hardware may also be implemented in software, and vice versa.Computer programs incorporating various features of the present invention may be encoded and stored on various computer readable storage media; suitable media include magnetic disks or tape, optical storage media such as a compact disk (CD) or digital versatile disk (DVD), flash memory, and other non-transitory media. Computer readable media encoded with the program code may be packaged with a compatible electronic device, or the program code may be provided separately from electronic devices (e.g., via download from the Internet or as a separately packaged computer readable storage medium).Thus, although the invention has been described with respect to specific embodiments, it will be apparent that the invention is intended to cover all modifications and equivalents within the scope of the following claims.

Claims

A method comprising: identifying an audio collection including one or more song at a first device (110); determining that the first device (110) is a playback device; coordinating, at the first device (110), playback of a song of the one or more song by transmitting, from the first device (110) to a speaker (115), audio data from the audio collection, the audio data corresponding to the song; accessing, at the first device (110), a rule indicating whether to take over a device other than the playback device; automatically determining by the first device (110) and while the first device (110) coordinates the playback of the song that a second device (120) is to take over as the playback device based on a property of the second device (120) and the rule being accessed; transmitting, from the first device (110) to the second device (120), one or more items of playback information for a takeover of the transmission of the audio data from the audio collection to the loudspeaker (115), wherein the one or more items of playback information identify at least the song and a takeover playback position within the song at which, after the takeover has taken place, the second device (120) is intended to start the playback of the song, and wherein a current playback of the song, which is coordinated by the first device (110), corresponds to a current playback position, which is located at the takeover playback position within the song; and terminating, at a point in time corresponding to the takeover playback position, the transmission of the audio data from the audio collection from the first device (110) to the loudspeaker (115).The method of claim 1, further comprising evaluating the rule based on the property, wherein evaluating the rule includes evaluating a property of the first (110) device that corresponds to the property of the second device (120).The method of claim 1, further comprising: detecting, by the first device (110), a plurality of second devices, the plurality of second devices including the second device (120); and identifying a characteristic of the second device for each of the plurality of second devices, and wherein determining that the second device (120) is to take over as the playback device includes selecting the second device from the plurality of second devices based on each of the characteristics of the second devices.A method comprising: identifying, by a master device, a dynamic set of devices, wherein each device of the dynamic set of devices is within the same range and has the capability to communicate audio data to a speaker (115), and wherein each device of the dynamic set of devices is different from the master device; identifying, by the master device, a first device of the dynamic set of devices, wherein the first device is a playback device that coordinates playback of a song by communicating audio data from an audio collection to a speaker (115), wherein the audio data corresponds to the song; automatically determining, by the master device, and while the first device (110) coordinates playback of the song that a second device (120) of the dynamic set of devices is to take over as the playback device; transmitting an instruction message from the main device and to the second device (120) comprising one or more playback information for a takeover of the transmission of the audio data from the audio collection to the speaker, wherein the one or more playback information identifies at least one takeover playback position within the audio collection, wherein the takeover playback position is within the song, and wherein the instruction message indicates that the second device (120) is to initiate a playback of the song at the takeover playback position.The method of claim 4, wherein determining that the second device (120) is to automatically take over as the playback device is performed without receiving a user input requesting the take over.The method of claim 4 or 5, upon determining that the second device (120) is to take over as the playback device, further comprising: transmitting an indication from the main device and to the first device (110), after which transmission of the audio data from the audio collection to the speaker (115) is to be terminated.The method of any of claims 4 to 6, further comprising: for each device in the set of devices, identifying a set of characteristics of the device; and for each device in the set of devices, and at the master device, calculating a score based on the set of characteristics of the device, wherein the determination that the second device (120) of the dynamic set of devices is to take over as the playback device is made based on a comparison of the calculated scores.The method of any of claims 4 to 7, further comprising: repeatedly monitoring, by the master device, a property for at least one device in the set of devices; and repeatedly determining, by the master device, which device in the set of devices is to be the playback device.An electronic device, comprising: an input component configured to receive input from a user (105); an output component configured to transmit audio data; one or more processors coupled to the input component and to the output component; and a computer readable storage medium including instructions that, when executed by the one or more processors, cause the one or more processors to: identify an audio collection that includes one or more songs; determine that the electronic device is a playback device; coordinate playback of a song of the one or more songs by transmitting, to a speaker (115), audio data from the audio collection, wherein the audio data corresponds to the song; accessing a rule indicating whether to take over a device other than the playback device; automatically determining, based on a property of the second device and the rule being accessed, while the electronic device coordinates playback of the song that a second device (120) is to take over as the playback device; transmitting one or more playback information to the second device (120) for taking over transmission of the audio data from the audio collection, wherein the one or more playback information identifies at least a time in the song at which the second device (120) is to take over as the playback device, and wherein the time corresponds to a current time in the song associated with a current transmission of the audio data to the speaker; and causing transmission of the audio data from the audio collection from the electronic device to the speaker (115) to be ended at the time the second device (120) is to take over as a playback device.The electronic device of claim 9, wherein the electronic device includes a wearable device.The electronic device of claim 9 or 10, wherein the one or more playback information for assuming the transmission of the audio data includes an identification of the audio collection or an identification of the song.A master electronic device, comprising: one or more processors coupled to an input component and to an output component; and a computer readable storage medium containing instructions that, when executed by the one or more processors, cause the one or more processors to: identify a dynamic set of devices, wherein each device of the dynamic set of devices is within the same range and has the capability to communicate audio data to a speaker (115), wherein each device of the dynamic set of devices is different from the master electronic device; identify a first device (110) of the dynamic set of devices that is a playback device that coordinates playback of a song by communicating audio data from an audio collection to a speaker (115), wherein the audio data corresponds to the song; Automatically detecting, while the first device (110) coordinates the playback of the song, that a second device (120) of the dynamic set of devices is to take over as the playback device; and transmitting an instruction message to the second device (120) comprising one or more playback information for taking over the transmission of the audio data from the audio collection to the speaker, wherein the one or more playback information identifies at least one take over playback position within the audio collection, wherein the take over playback position is within the song, and wherein the instruction message indicates that the second device (120) is to initiate a playback of the song at the take over playback position.The master electronic device of claim 12, wherein the determination that the second device (120) is to take over as the playback device is made based on a corresponding characteristic of one or both of the first device or the second device, and wherein each of the characteristic or the corresponding characteristic indicates a current resource availability, a current accessibility to a connection (215), a location, a power source, or a device type.The main electronic device of claim 12, wherein the determination that the second device (120) is to take over as the playback device is made based on a property of the first device and a corresponding property of the second device.The master electronic device of any of claims 12 to 14, wherein the dynamic set of devices includes a wearable device.

Images