Playback transition between audio device

Abstract

To provide a method and a non-transitory computer-readable medium for migrating (swapping) playback sessions between portable playback devices, such as "smart" headphones, earphones, handheld speakers, and the like, and playback devices of a zone-based media playback system.SOLUTION: A push swap method that allows continuation of playback when location changes (from home to away or vice versa) or listening style changes (from playback on headphones 710a to playback on playback device 110b or vice versa) detects a swap trigger, determines source playback device(s) and target playback device(s), and performs swap of the playback session between the source playback device(s) and target playback device(s).SELECTED DRAWING: Figure 8A

Description

Technical Field

[0001] This application claims the benefit under 35 U.S.C. § 119 of U.S. Provisional Patent Application No. 62 / 811,962, filed Feb. 28, 2019, entitled “Playback Transitions,” which is hereby incorporated by reference in its entirety.

[0002] The present disclosure relates to consumer products and, in particular, to methods, systems, products, features, services, and other elements directed to media playback, and to some aspects thereof.

Background Art

[0003] Before Sonos, Inc. began developing a new type of playback system in 2002, options for accessing and listening to digital audio at high volumes were limited. Sonos filed a patent application in 2003, one of its first, titled "Method for Synchronizing Audio Playback between Multiple Networked Devices," and began selling its first media playback system in 2005. With the Sonos Wireless Home Sound System, people can experience music from multiple sources through one or more networked playback devices. Through a software control application installed on a controller (such as a smartphone, tablet, computer, voice input device), people can play desired music in any room equipped with a networked playback device. Media content (such as songs, podcasts, video sound) is streamed to the playback devices, and different corresponding media content can be played in each room equipped with a playback device. Also, multiple rooms can be grouped to play the same media content synchronously and / or the same media content can be listened to synchronously in all rooms.

Brief Description of the Drawings

[0004] The features, aspects, and advantages of the technology disclosed herein can be better understood by reference to the following description, the appended claims, and the accompanying drawings, as set forth below. Those skilled in the art will understand that the features shown in the drawings are for illustrative purposes only and that variations including different features and / or additional features and their arrangements are possible.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 1E

Figure 1F

Figure 1G

Figure 1H

Figure 1I

Figure 1J

Figure 1K

Figure 1L

Figure 1M

Figure 2A

Figure 2B

Figure 2C

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 4A

Figure 4B

Figure 4C

Figure 4D

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 7C

Figure 7D

Figure 7E

Figure 7F

Figure 7G

Figure 8A

Figure 8B

Figure 8C

Figure 9

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 13A

Figure 13B

Figure 14

Figure 15

Figure 16A

Figure 16B

Figure 16C

Figure 16D

Figure 16E

Figure 17A

Figure 17B

Figure 17C

Figure 17D

Figure 17E

Figure 17F

Figure 18A

Figure 18B

Figure 18C

Figure 19A

Figure 19B

Figure 19C

Figure 20A

Figure 20B

Figure 20C

Figure 21A

Figure 21B

Figure 21C

Figure 22A

Figure 22B

Figure 22C

Figure 22D

Figure 23A

Figure 23B

Figure 23C

Figure 23D

Figure 23E

Figure 23F

Figure 23G

Figure 23H

Figure 23I

Figure 23J

Figure 23K

Figure 23L

Figure 23M

Figure 24A

Figure 24B

Figure 24C

Figure 24D

Figure 24E

Figure 24F

Figure 25A

Figure 25B

Figure 25C

Figure 26A

Figure 26B

Figure 26C

DETAILED DESCRIPTION OF THE INVENTION

[0005] I. Overview The exemplary techniques described herein relate to the transfer of a playback session between wearable playback devices such as "smart" headphones and earbuds, and playback devices of a zone-based media playback system. Further exemplary techniques relate to the transfer of a playback session between a portable (e.g., battery-powered, transportable) playback device and a playback device of a zone-based media playback system. Such a transfer is referred to herein as a "swap" or "playback session swap". Such exemplary swap techniques facilitate continuity of playback when transitioning between locations (e.g., from home to away or vice versa) or listening paradigms (e.g., personal or voice-emitting). Additionally, some exemplary techniques can reduce the degree of user input (or other user involvement) associated with the transfer of playback as compared to some other techniques.

[0006] In an exemplary example, a user initiates a playback session with exemplary headphones while away from home. For example, the user starts listening to KEXP Seattle using earbuds paired with a mobile device (e.g., a smartphone) via a wireless connection such as 802.15 (Bluetooth®) or 802.11, among other examples. In this example, KEXP radio is streamed to the mobile device over the Internet.

[0007] When returning home, the user may wish to continue listening to KEXP radio by speaking. To initiate a playback session swap from the earbuds to a playback device within the kitchen, the user may input to the earbuds. Since the earbuds are continuing the playback session, this input designates the earbuds as the source for the playback session swap. The target of the swap (i.e., the kitchen zone) may be pre-specified with a predetermined swap pair with the earbuds or may be determined after the input using proximity detection techniques such as audio chirping as described in more detail herein. The earbuds and / or mobile device perform a playback session swap with the kitchen zone, and the playback of KEXP radio continues to speak continuously with the playback device within the kitchen.

[0008] In another exemplary example, the user can initiate a playback session with an exemplary portable speaker. For example, the user starts listening to WBEZ Chicago using a handheld speaker in the dining room. In this example, WBEZ Chicago is streamed to the handheld speaker via the home local area network over the Internet. Wanting to meditate, the user moves the handheld speaker to the living room and asks the voice assistant service to play meditation music. The handheld speaker plays the approval from the voice assistant service and starts playing a curated meditation playlist from the streaming audio service.

[0009] While the user is playing a curated meditation playlist, a friend of the user enters the living room and proposes that the user check out a new Childish Gambino track that is playing via a control application on the smartphone. To initiate a playback session swap from the smartphone to a handheld speaker, the friend holds the smartphone near the handheld speaker and initiates a Near Field Communication (NFC) exchange between the smartphone and the handheld speaker. This exchange designates the smartphone as the source of the playback session swap and the handheld speaker as the target. The smartphone executes the playback session swap with the handheld speaker, and the playback of the Childish Gambino track continues without interruption with audio output from the handheld speaker.

[0010] To enjoy the Childish Gambino track with a more powerful amplifier and / or larger transducers, the user initiates a playback session swap from the handheld speaker to a playback device in the living room by entering the handheld speaker. This input designates the handheld speaker as the source of the playback session swap. The handheld speaker automatically designates the living room zone as the target of the swap based on the detected proximity of the handheld speaker to the living room zone. The handheld speaker executes the playback session swap with the living room zone, and the playback of the Childish Gambino track continues without interruption with volume output from the playback device within the living room.

[0011] In a third exemplary example, in the evening, the user can start a playback session in the bedroom on a soundbar device that plays audio content from the TV. A user who wishes to continue with the volume turned down so as not to disturb a partner who is trying to put a baby to sleep in an adjacent room can initiate a playback session swap from the soundbar device to a handheld speaker that the user has placed on the nightstand. Since the handheld speaker is physically close to the user, the user can comfortably listen to the audio from the TV at a lower volume level.

[0012] After putting the baby to sleep, the partner comes into the bedroom and finds the user asleep. To initiate a playback session swap from the handheld speaker to a pair of headphones, the partner may enter an input into the headphones. This input designates the headphones as the target for the playback session swap. The source of the swap (i.e., the handheld speaker) is determined based on context (i.e., based on the active playback session). The handheld speaker performs the playback session swap with the headphones, and the playback of the TV audio continues at volume without interruption through the headphones.

[0013] As described above, the exemplary techniques described herein include playback session swapping. Exemplary embodiments include detecting a swap trigger, determining a source playback device and a target playback device, and performing a playback session swap between the source playback device and the target playback device.

[0014] Some of the examples described herein may refer to functions performed by a given actor such as a "user", "listener", and / or other entity, but it should be understood that this is for illustrative purposes only. The claims should not be construed to require actions by such exemplary actors unless explicitly required by the terms of the claims themselves.

[0015] Furthermore, in this specification, some functions are described as being performed "based on" or "in response to" another element or function. "Based on" is to be understood as one element or function being related to another function or element. "In response to" is to be understood as one element or function being a required result of another function or element. For the sake of brevity, when a functional link exists, the function is generally described as being based on another function. However, such disclosure should be understood as disclosing any type of functional relationship.

[0016] In the figures, the same reference numbers generally identify similar and / or identical elements. To facilitate the description of any particular element, the most significant digit or digits of the reference number refer to the figure in which the element is first introduced. For example, element 110a is first introduced and described with reference to FIG. 1A. Many of the details, dimensions, angles, and other features shown in the figures merely illustrate particular embodiments of the disclosed technology. Accordingly, other embodiments can have other details, dimensions, angles, and features without departing from the spirit or scope of the present disclosure. Further, those skilled in the art will understand that additional embodiments of the disclosed technologies can be practiced without relying on some of the details described below.

[0017] II. Preferred Operating Environment FIG. 1A is a partial cross-sectional view of a media playback system 100 disposed in an environment 101 (e.g., a house). The media playback system 100 includes one or more playback devices 110 (individually identified as playback devices 110a-n), one or more network microphone devices ("NMDs") 120 (individually identified as NMDs 120a-c), and one or more control devices 130 (individually identified as control devices 130a, 130b).

[0018] As used herein, the term "playback device" can generally refer to a network device configured to receive, process, and output data of a media playback system. For example, a playback device can be a network device configured to receive and process audio content. In some embodiments, the playback device includes one or more transducers or speakers powered by one or more amplifiers. However, in other embodiments, the playback device includes either (or neither) a speaker and an amplifier. For example, a playback device can include one or more amplifiers configured to drive one or more speakers external to the playback device via corresponding wires or cables.

[0019] Furthermore, as used herein, the term "NMD" (i.e., "network microphone device") can generally refer to a network device configured for audio detection. In some embodiments, the NMD is a stand-alone device primarily configured for audio detection. In other embodiments, the NMD is incorporated into (or vice versa) a playback device.

[0020] The term "control device" can generally refer to a network device configured to perform related functions to enable user access, control, and / or configuration of the media playback system 100.

[0021] Each of the playback devices 110 is configured to receive an audio signal or data from one or more media sources (e.g., one or more remote servers, one or more local devices) and play the received audio signal or data as sound. One or more NMDs 120 are configured to receive a spoken word command, and one or more control devices 130 are configured to receive user input. In response to the received spoken word command and / or user input, the media playback system 100 can play audio via one or more of the playback devices 110. In certain embodiments, the playback devices 110 are configured to initiate playback of media content in response to a trigger. For example, one or more of the playback devices 110 can be configured to play a morning playlist when a related trigger condition (e.g., presence of a user in the kitchen, detection of operation of a coffee machine) is detected. In some embodiments, for example, the media playback system 100 is configured to play audio from a first playback device (e.g., playback device 100a) in synchronization with a second playback device (e.g., playback device 100b). Interactions between the playback devices 110, NMDs 120, and / or control devices 130 of the media playback system 100 configured according to various embodiments of the present disclosure are described in more detail below with respect to FIGS. 1B - 1H.

[0022] In the illustrated embodiment of FIG. 1A, the environment 101 is a home having a plurality of rooms, spaces, and / or playback zones including, clockwise from the upper left, a master bathroom 101a, a master bedroom 101b, a second bedroom 101c, a family room or den 101d, an office 101e, a living room 101f, a dining room 101g, a kitchen 101h, and an outdoor patio 101i. Specific embodiments and examples are described below in the context of a home environment, but the techniques described herein may be implemented in other types of environments. In some embodiments, for example, the media playback system 100 may be implemented in one or more commercial facilities (e.g., restaurants, malls, airports, hotels, retail stores or other stores), one or more vehicles (e.g., sport utility vehicles, buses, cars, ships, boats, airplanes), multiple environments (e.g., a combination of a home environment and a vehicle environment), and / or any other suitable environment where multi-zone audio may be desirable.

[0023] The media playback system 100 can constitute one or more playback zones, some of which may correspond to rooms within the environment 101. The media playback system 100 may be formed by one or more playback zones, after which additional zones may be added or removed to form, for example, the configuration shown in FIG. 1A. Each zone may be given a name corresponding to a different room or space, such as office 101e, master bathroom 101a, master bedroom 101b, second bedroom 101c, kitchen 101h, dining room 101g, living room 101f, and / or balcony 101i. In some aspects, a single playback zone may include multiple rooms or spaces. In certain aspects, a single room or space may include multiple playback zones.

[0024] In the illustrated embodiment of FIG. 1A, the master bathroom 101a, the second bedroom 101c, the office 101e, the living room 101f, the dining room 101g, the kitchen 101h, and the outdoor patio 101i each include one playback device 110, and the master bedroom 101b and the den 101d include a plurality of playback devices 110. In the master bedroom 101b, the playback devices 110l, 110m may be configured to synchronously play audio content, for example, as individual ones of the plurality of playback devices 110, as a combined playback zone, as an integrated playback device, and / or as any combination thereof. Similarly, in the den 101d, the playback devices 110h-j may be configured to synchronously play audio content, for example, as individual ones of the plurality of playback devices 110, as one or more combined playback devices, and / or as one or more integrated playback devices. Additional details regarding combined playback devices and integrated playback devices are described below with respect to FIGS. 1B and 1E, and FIGS. 1-I through 1-M.

[0025] In some aspects, one or more playback zones within the environment 101 may play different audio content. For example, while one user is grilling on the patio 101i and listening to hip-hop music being played by the playback device 110c, another user may be preparing food in the kitchen 101h and listening to classical music being played by the playback device 110b. In another example, a playback zone may play the same audio content in synchronization with another playback zone. For example, a user may listen to the same hip-hop music being played by the playback device 110c on the patio 101i while it is being played by the playback device 110f in the office 101e. In some aspects, the playback devices 110c and 110f synchronously play the hip-hop music such that the user perceives that the audio content is being played seamlessly (or at least substantially seamlessly) as the playback devices move between different playback zones.

[0026] a. Suitable media playback system FIG. 1B is a schematic diagram of a media playback system 100 and a cloud network 102. For ease of illustration, in FIG. 1B, certain devices of the media playback system 100 and the cloud network 102 are omitted. One or more communication links 103 (hereinafter referred to as "link 103") for communicatively connecting the media playback system 100 and the cloud network 102 are provided.

[0027] Link 103 can be composed of, for example, one or more wired networks, one or more wireless networks, one or more wide area networks (WANs), one or more local area networks (LANs), one or more personal area networks (PANs), one or more communication networks (e.g., one or more Global System For Mobiles (GSM) networks for mobile devices, Code Division Multiple Access (CDMA) networks, Long-Term Evolution (LTE) networks, 5G communication networks, and / or other suitable data transmission protocol networks). The cloud network 102 is configured to deliver media content (e.g., audio content, video content, photos, social media content) to the media playback system 100 in response to requests sent from the media playback system 100 via link 103. In some embodiments, the cloud network 102 is further configured to receive data (e.g., voice input data) from the media playback system 100 and, correspondingly, send commands and / or media content to the media playback system 100.

[0028] The cloud network 102 is composed of computing devices 106 (individually identified as the first computing device 106a, the second computing device 106b, and the third computing device 106c). The computing device 106 can constitute an individual computer or server, for example, a media streaming service server that stores audio and / or other media content, a voice service server, a social media server, a media playback system control server, etc. In some embodiments, one or more of the computing devices 106 constitute a module of a single computer or server. In a specific embodiment, one or more of the computing devices 106 constitute one or more modules, computers, and / or servers. Further, although the cloud network 102 is described in the context of a single cloud network, in some embodiments, the cloud network 102 constitutes a plurality of cloud networks with communication-connected computing devices. Further, in FIG. 1B, the cloud network 102 is shown as having three computing devices 106, but in some embodiments, the cloud network 102 comprises fewer (or more) than three computing devices 106.

[0029] Media playback system 100 is configured to receive media content from network 102 via link 103. The received media content can be composed of, for example, a Uniform Resource Identifier (URI) and / or a Uniform Resource Locator (URL). For example, in some cases, media playback system 100 can stream, download, or otherwise obtain data from a URI or URL corresponding to the received media content. Network 104 communicatively connects link 103 with at least a portion of the devices of media playback system 100 (e.g., one or more of playback device 110, NMD 120, and / or control device 130). Network 104 can include, for example, a wireless network (e.g., a WiFi (registered trademark) network, Bluetooth (registered trademark), Z-Wave network, ZigBee (registered trademark), and / or other suitable wireless communication protocol network) and / or a wired network (e.g., a network consisting of Ethernet (registered trademark), Universal Serial Bus (USB (registered trademark)), and / or other suitable wired communication). As used herein, as would be understood by one of ordinary skill in the art, "WiFi (registered trademark)" can refer to several different communication protocols, including, for example, communication protocols transmitted at 2.4 gigahertz (GHz), 5 GHz, and / or another suitable frequency, such as Institute of Electrical and Electronics Engineers (IEEE) 802. 11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ac, 802.11ad, 802.11af, 802.11ah, 802.11ai, 802.11aj, 802.11aq, 802.11ax, 802.11ay, 802.15, etc.

[0030] In some embodiments, network 104 constitutes a dedicated communication network for the media playback system 100 to send messages between individual devices and / or to send media content between a media content source (e.g., one or more of computing devices 106). In certain embodiments, network 104 is configured to be accessible only to devices within the media playback system 100, thereby reducing interference and contention with other household devices. In one example, the dedicated communication network is implemented as a mesh network, and the devices of the media playback system form the nodes of the mesh network. One or more root nodes of the mesh network are connected to a household WiFi network that functions in parallel with the mesh network.

[0031] However, in other embodiments, network 104 constitutes an existing household communication network (e.g., a household WiFi (registered trademark) network). In some embodiments, link 103 and network 104 constitute one or more of the same networks. In some aspects, for example, link 103 and network 104 constitute a communication network (e.g., an LTE network, a 5G network). Further, in some embodiments, the media playback system 100 is implemented without passing through network 104, and the devices constituting the media playback system 100 can communicate with each other via, for example, one or more direct connections, a PAN, a communication network, and / or other suitable communication links.

[0032] In some embodiments, audio content sources may be periodically added or removed from the media playback system 100. In some embodiments, for example, the media playback system 100 performs indexing of media items when one or more media content sources are updated, added, and / or removed from the media playback system 100. The media playback system 100 can scan for identifiable media items within some or all of the folders and / or directories accessible to the playback device 110 and generate or update a media content database that includes metadata (e.g., title, artist, album, track length) and other relevant information (e.g., URI, URL) for each identifiable media item found. In some embodiments, for example, the media content database is stored in one or more of the playback device 110, the network microphone device 120, and / or the control device 130.

[0033] In the illustrated embodiment of FIG. 1B, playback devices 110l, 110m constitute group 107a. The playback devices 110l, 110m can be arranged in different rooms in the home and can be grouped into group 107a temporarily or permanently based on user input received by control device 130a of media playback system 100 and / or another control device 130. When arranged within group 107a, the playback devices 110l, 110m can be configured to synchronously play the same or similar audio content from one or more audio content sources. In certain embodiments, for example, group 107a includes a combined zone in which playback devices 110l, 110m each constitute the left and right audio channels of multi-channel audio content, thereby generating or enhancing the stereo effect of the audio content. In some embodiments, group 107a further includes playback device 110. However, in other embodiments, media playback system 100 omits group 107a and / or other grouped arrangements of playback devices 110. Details regarding groups and other arrangements of playback devices are described below with reference to FIGS. 1-I through 1-M.

[0034] The media playback system 100 includes NMD120a and 120d having one or more microphones configured to receive voice utterances from a user. In the illustrated embodiment of FIG. 1B, NMD120a is a stand-alone device and NMD120d is integrated into the playback device 110n. NMD120a is configured to receive, for example, voice input 121 from user 123. In some embodiments, NMD120a transmits data associated with the received voice input 121 to a voice assistant service (VAS) configured to (i) process the received voice input data and (ii) send corresponding commands to the media playback system 100. In some aspects, for example, the computing device 106c constitutes one or more modules and / or servers of a VAS (e.g., a VAS operated by one or more of SONOS®, AMAZON®, GOOGLE®, APPLE®, MICROSOFT®). The computing device 106c can receive voice input data from NMD120a via the network 104 and the link 103. In response to receiving the voice input data, the computing device 106c processes the voice input data (e.g., "Play Hey Jude by The Beatles") and determines that the processed voice input includes a command (e.g., "Hey Jude") for playing a song. The computing device 106c then transmits, accordingly, a command for playing "Hey Jude" by The Beatles on one or more of the playback devices 110 of the playback device 110 from an appropriate media service (e.g., via one or more of the computing devices 106) to the media playback system 100.

[0035] b. Suitable playback device FIG. 1C is a block diagram of a playback device 110a having an input / output 111. The input / output 111 can include an analog I / O 111a (e.g., one or more wires, cables, and / or other suitable communication links configured to transmit analog signals) and / or a digital I / O 111b (e.g., one or more wires, cables, or other suitable communication links configured to transmit digital signals). In some embodiments, the analog I / O 111a is, for example, an audio line-in input connection that constitutes an automatically detected 3.5 mm audio line-in connection. In some embodiments, the digital I / O 111b includes a Sony / Philips Digital Interface Format (S / PDIF) communication interface and / or cable, and / or a Toshiba Link (TOSSLINK) cable. In some embodiments, the digital I / O 111b includes a High-Definition Multimedia Interface (HDMI (registered trademark)) interface and / or cable. In some embodiments, the digital I / O 111b includes, for example, one or more wireless communication links from radio frequency (RF), infrared, WiFi (registered trademark), Bluetooth (registered trademark), or other suitable communication protocols. In certain embodiments, the analog I / O 111a and the digital 111b may not necessarily include cables, and include interfaces (e.g., ports, plugs, jacks) configured to receive the connectors of the cables that transmit analog signals and digital signals, respectively.

[0036] The playback device 110a can receive media content (e.g., audio content consisting of music and / or other sounds) from the local audio source 105 via, for example, an input / output 111 (e.g., a cable, wired, wired, PAN, Bluetooth® connection, ad-hoc wired or wireless communication network, and / or another suitable communication link). The local audio source 105 can comprise, for example, a mobile device (e.g., a smartphone, a tablet, a laptop computer) or another suitable audio component (e.g., a television, a desktop computer, an amplifier, a record player, a Blu-ray player, a memory storing digital media files). In some embodiments, the local audio source 105 includes a local music library on a smartphone, a computer, a network-attached storage (NAS), and / or another suitable device configured to store media files. In certain embodiments, one or more of the playback device 110, the NMD 120, and / or the control device 130 constitute the local audio source 105. However, in other embodiments, the media playback system completely omits the local audio source 105. In some embodiments, the playback device 110a does not include the input / output 111 and receives all audio content via the network 104.

[0037] The playback device 110a further includes an electronic device 112, a user interface 113 (e.g., one or more buttons, knobs, dials, touch-sensitive surfaces, displays, touchscreens), and one or more transducers 114 (hereinafter referred to as "transducer 114"). The electronic device 112 is configured to receive audio from an audio source (e.g., local audio source 105) via an input / output 111 and one or more computing devices 106a-c (FIG. 1B) via a network 104 (FIG. 1B), amplify the received audio, and output the amplified audio for playback via one or more transducers 114. In some embodiments, the playback device 110a optionally includes one or more microphones 115 (e.g., a single microphone, multiple microphones, microphone array) (hereinafter referred to as "microphone 115"). In certain embodiments, for example, the playback device 110a having one or more optional microphones 115 can operate as an NMD configured to receive voice input from a user and perform corresponding one or more operations based on the received voice input.

[0038] In the illustrated embodiment of FIG. 1C, the electronic device 112 includes one or more processors 112a (hereinafter referred to as "processor 112a"), a memory 112b, software components 112c, a network interface 112d, one or more audio processing components 112g (hereinafter referred to as "audio processing component 112g"), one or more audio amplifiers 112h (hereinafter referred to as "amplifier 112h"), and a power source 112i (e.g., one or more power supplies, power cables, power receptacles, batteries, induction coils, Power-over Ethernet (POE) interfaces, and / or other suitable power sources). In some embodiments, the electronic device 112 optionally includes one or more other components 112j (e.g., one or more sensors, video displays, touchscreens).

[0039] Processor 112a can include a clock-driven computing component configured to process data, and memory 112b can include a computer-readable medium (e.g., a tangible, non-transitory computer-readable medium, a data storage device into which one or more software components 112c are loaded) configured to store instructions for performing various operations and / or functions. Processor 112a is configured to execute instructions stored in memory 112b to command one or more operations. The instructions can include, for example, causing playback device 110a to obtain audio data from an audio source (e.g., one or more of computing devices 106a-c (FIG. 1B)) and / or causing another audio data of playback device 110 to be obtained. In some embodiments, the instructions further include causing playback device 110a to transmit audio data to another one of playback device 110a and / or another device (e.g., one of NMD 120). In certain embodiments, the instructions further include causing playback device 110a to pair with another device of one or more playback devices 110 to enable a multi-channel audio environment (e.g., a stereo pair, a combined zone).

[0040] Processor 112a can be further configured to execute instructions for causing playback device 110a to synchronize the playback of audio content with another one of one or more playback devices 110. As will be appreciated by those skilled in the art, during the synchronized playback of audio content on multiple playback devices, a listener will preferably not be able to perceive a time difference between the playback of audio content by playback device 110a and the playback of audio content by one or more other playback devices 110. Additional details regarding audio playback synchronization between playback devices are described, for example, in U.S. Patent No. 8,234,395, which is incorporated by reference above.

[0041] In some embodiments, the memory 112b is further configured to store data associated with the playback device 110a, such as one or more zones and / or zone groups of which the playback device 110a is a member, audio sources accessible to the playback device 110a, and / or a playback queue associated with the playback device 110a (and / or another one of the one or more playback devices). The stored data can be updated periodically and can include one or more state variables used to describe the state of the playback device 110a. The memory 112b can also include data associated with the state of one or more other devices of the media playback system 100 (e.g., the playback device 110, the NMD 120, the control device 130). In some aspects, for example, the state data is shared at predetermined intervals (e.g., every 5 seconds, every 10 seconds, every 60 seconds) among at least some of the devices of the media playback system 100, such that one or more of the devices have the latest data associated with the media playback system 100.

[0042] The network interface 112d is configured to facilitate data transmission between the playback device 110a and one or more other devices on a data network such as, for example, the link 103 and / or the network 104 (FIG. 1B). The network interface 112d is configured to transmit and receive data corresponding to media content (e.g., audio content, video content, text, photos) and other signals (e.g., non-transitory signals) including digital packet data having an Internet Protocol (IP)-based source address and / or an IP-based destination address. The network interface 112d can analyze the digital packet data so that the electronic device 112 can properly receive and process data directed to the playback device 110a.

[0043] In the illustrated embodiment of FIG. 1C, network interface 112d includes one or more wireless interfaces 112e (hereinafter referred to as "wireless interface 112e"). The wireless interface 112e (e.g., a suitable interface including one or more antennas) may be configured to wirelessly communicate with one or more other devices (e.g., one or more of other playback devices 110, NMD 120, and / or control device 130) that are communicatively connected to network 104 (FIG. 1B) according to a suitable wireless communication protocol (e.g., WiFi®, Bluetooth®, LTE). In some embodiments, network interface 112d optionally includes a wired interface 112f (e.g., an interface or receptacle configured to receive a network cable such as Ethernet®, USB-A, USB-C, and / or Thunderbolt cable) configured to communicate in a wired connection with other devices according to a suitable wired communication protocol. In certain embodiments, network interface 112d includes wired interface 112f and excludes wireless interface 112e. In some embodiments, electronic device 112 completely excludes network interface 112d and transmits and receives media content and / or other data via another communication path (e.g., input / output 1111).

[0044] The audio processing component 112g is configured to process and / or filter data constituting the media content received by the electronic device 112 (e.g., via the input / output 111 and / or the network interface 112d) to generate an output audio signal. In some embodiments, the audio processing component 112g includes, for example, one or more digital / analog converters (DACs), audio preprocessing components, audio enhancement components, digital signal processors (DSPs), and / or other suitable audio processing components, modules, circuits, etc. In certain embodiments, one or more of the audio processing components 112g can include one or more sub-components of the processor 112a. In some embodiments, the electronic device 112 omits the audio processing component 112g. In some aspects, for example, the processor 112a executes instructions stored in the memory 112b to perform audio processing operations for generating an output audio signal.

[0045] Amplifier 112h is configured to receive and amplify an audio output signal generated by the audio processing component 112g and / or the processor 112a. The amplifier 112h can include an electronic device and / or component configured to amplify the audio signal to a level sufficient to drive one or more transducers 114. In some embodiments, for example, the amplifier 112h includes one or more switching or class-D power amplifiers. However, in other embodiments, the amplifier includes one or more other types of power amplifiers (e.g., linear gain power amplifiers, class-A amplifiers, class-B amplifiers, class-AB amplifiers, class-C amplifiers, class-D amplifiers, class-E amplifiers, class-F amplifiers, class-G amplifiers, and / or class-H amplifiers, and / or another suitable type of power amplifier). In certain embodiments, the amplifier 112h includes a suitable combination of two or more of the aforementioned types of power amplifiers. Further, in some embodiments, an individual amplifier 112h corresponds to an individual transducer 114. However, in other embodiments, the electronic device 112 includes one amplifier 112h configured to output the amplified audio signal to a plurality of transducers 114. In some other embodiments, the electronic device 112 omits the amplifier 112h.

[0046] The transducer 114 (e.g., one or more speakers and / or speaker drivers) receives the amplified audio signal from the amplifier 112h and renders or outputs the amplified audio signal as sound (e.g., audible sound waves having a frequency between about 20 Hertz (Hz) and about 20 kilohertz (kHz)). In some embodiments, the transducer 114 can comprise a single transducer. However, in other embodiments, the transducer 114 comprises a plurality of audio transducers. In some embodiments, the transducer 114 comprises one or more types of transducers. For example, the transducer 114 can include one or more low-frequency transducers (e.g., subwoofers, woofers), mid-frequency transducers (e.g., midrange transducers, midwoofers), and one or more high-frequency transducers (e.g., one or more tweeters). As used herein, "low frequency" can generally refer to audible frequencies below about 500 Hz, "midrange frequency" can generally refer to audible frequencies between about 500 Hz and about 2 kHz, and "high frequency" can generally refer to audible frequencies above about 2 kHz. However, in certain embodiments, one or more of the transducers 114 comprise transducers that do not conform to the aforementioned frequency ranges. For example, one of the transducers 114 may comprise a midwoofer transducer configured to output sound at frequencies between about 200 Hz and about 5 kHz.

[0047] For purposes of illustration, Sonos, Inc. currently offers (or has offered) for sale certain playback devices including, for example, "SONOS ONE", "PLAY:1", "PLAY:3", "PLAY:5", "PLAYBAR", "PLAYBASE", "CONNECT:AMP", "CONNECT", and "SUB". Other suitable playback devices may additionally or alternatively be used to implement the playback devices of the exemplary embodiments disclosed herein. Further, one of ordinary skill in the art will understand that the playback devices are not limited to the exemplary embodiments described herein or to the offerings of Sonos products. In some embodiments, for example, one or more playback devices 110 comprise wired or wireless headphones (e.g., over-ear headphones, on-ear headphones, in-ear earphones). In other embodiments, one or more playback devices 110 comprise a docking station for a personal mobile media playback device and / or an interface configured to interact with the docking station. In certain embodiments, the playback device may be integrated with another device or component such as a television, a lighting fixture, or some other device for use indoors or outdoors. In some embodiments, the playback device omits a user interface and / or one or more transducers. For example, FIG. 1D is a block diagram of a playback device 110p that does not comprise a user interface 113 or a transducer 114 and comprises an input / output 111 and electronics 112.

[0048] FIG. 1E is a block diagram of a combined playback device 110q that acoustically couples a playback device 110a (FIG. 1C) and a playback device 110i (e.g., a subwoofer) (FIG. 1A). In the illustrated embodiment, playback devices 110a and 110i are separate ones of playback device 110 housed in separate enclosures. However, in some embodiments, combined playback device 110q comprises a single enclosure that houses both playback devices 110a and 110i. Combined playback device 110q can be configured to process and reproduce different sounds than uncombined playback devices (e.g., playback device 110a of FIG. 1C) and / or paired or combined playback devices (e.g., playback devices 110l and 110m of FIG. 1B). In some embodiments, for example, playback device 110a is a full-range playback device configured to render low, mid, and high frequency audio content, and playback device 110i is a subwoofer configured to render low frequency audio content. In some aspects, playback device 110a is configured to render only the midrange and high frequency components of a particular audio content when combined with a first playback device, and playback device 110i is configured to render the low frequency component of the particular audio content. In some embodiments, combined playback device 110q includes additional playback devices and / or another combined playback device. Embodiments of additional playback devices are described in further detail below with respect to FIGS. 2A - 3D.

[0049] c. Suitable Network Microphone Device (NMD) FIG. 1F is a block diagram of NMD120a (FIGS. 1A and 1B). NMD120a includes one or more audio processing components 124 (hereinafter referred to as "audio component 124") and a plurality of components described with respect to playback device 110a (FIG. 1C) including processor 112a, memory 112b, and microphone 115. NMD120a optionally includes other components also included in playback device 110a (FIG. 1C) such as user interface 113 and / or transducer 114. In some embodiments, NMD120a is configured as a media playback device (e.g., one or more of playback devices 110) and further includes, for example, audio component 112g (FIG. 1C), amplifier 114, and / or one or more of other playback device components. In certain embodiments, NMD120a comprises an Internet of Things (IoT) device such as, for example, a thermostat, an alarm panel, a fire detector and / or a smoke detector. In some embodiments, NMD120a includes only a microphone 115, audio processing 124, and some of the components of electronic device 112 described above with respect to FIG. 1B. In some embodiments, for example, NMD120a includes processor 112a and memory 112b (FIG. 1B) while omitting one or more other components of electronic device 112. In some embodiments, NMD120a includes additional components (e.g., one or more sensors, cameras, thermometers, barometers, hygrometers).

[0050] In some embodiments, the NMD can be incorporated into a playback device. FIG. 1G is a block diagram of a playback device 110r including an NMD 120d. The playback device 110r can include many or all of the components of the playback device 110a and further includes a microphone 115 and audio processing 124 (FIG. 1F). The playback device 110r optionally includes an integrated control device 130c. The control device 130c can include, for example, a user interface (e.g., the user interface 113 of FIG. 1B) configured to receive user input (e.g., touch input, voice input) without using a separate control device. However, in other embodiments, the playback device 110r receives commands from another control device (e.g., the control device 130a of FIG. 1B).

[0051] Referring again to FIG. 1F, the microphone 115 is configured to obtain, capture, and / or receive sound from the environment (e.g., the environment 101 of FIG. 1A) and / or the room in which the NMD 120a is located. The received sound can include, for example, utterances, audio reproduced by the NMD 120a and / or another playback device, background voices, ambient sounds, etc. The microphone 115 converts the received sound into an electrical signal to generate microphone data. The audio processing 124 receives and analyzes the microphone data to determine whether there is a voice input in the microphone data. The voice input can be composed of, for example, an activation word following a trigger word that includes a user request. As will be understood by those skilled in the art, the activation word is a word or other voice cue that means the user's voice input. For example, when querying AMAZON (registered trademark) VAS, the user may say the activation word "Alexa". Other examples include "OK, Google" for calling GOOGLE (registered trademark) VAS and "Hey, Siri" for calling APPLE (registered trademark) VAS.

[0052] After detecting the wake word, the voice processing 124 monitors the microphone data for user requests associated with the voice input. The user requests may include, for example, commands to control network-enabled devices such as a thermostat (e.g., a NEST (registered trademark) thermostat), a lighting device (e.g., a PHILIPS HUE (registered trademark) lighting device), or a media playback device (e.g., a Sonos (registered trademark) playback device). For example, the user may say the wake word "Alexa" and then say "Set the thermostat to 68 degrees" to set the temperature within a home (e.g., the environment 101 of FIG. 1A). The user may say the same wake word and then say "Turn on the living room" to turn on the lighting device in the living room area of the home. Similarly, the user may say the wake word and then say a request to play a specific song, album, or music playlist on a playback device within the home. The reception and processing of the voice input data will be described in more detail with reference to FIGS. 3A - 3F.

[0053] d. Suitable control device FIG. 1H is a partial schematic view of control device 130a (FIGS. 1A and 1B). As used herein, the term "control device" can be used interchangeably with "controller" or "control system". Among other features, control device 130a is configured to receive user input related to media playback system 100 and, in response thereto, cause one or more devices within media playback system 100 to perform operations or actions corresponding to the user input. In the illustrated embodiment, control device 130a comprises a smartphone (e.g., iPhone (registered trademark), Android phone) on which media playback system controller application software is installed. In some embodiments, control device 130a comprises, for example, a tablet (e.g., iPad (registered trademark)), a computer (e.g., a laptop computer, a desktop computer), and / or other suitable devices (e.g., a television, an automotive audio head unit, an IoT device). In certain embodiments, control device 130a comprises a dedicated controller for media playback system 100. In other embodiments, as described above with respect to FIG. 1G, control device 130a is integrated into another device within media playback system 100 (e.g., playback device 110, NMD 120, and / or one or more of other suitable devices configured to communicate via a network).

[0054] The control device 130a includes an electronic device 132, a user interface 133, one or more speakers 134, and one or more microphones 135. The electronic device 132 includes one or more processors 132a (hereinafter referred to as "processor 132a"), a memory 132b, software components 132c, and a network interface 132d. The processor 132a can be configured to execute functions related to facilitating user access to, control of, and configuration of the media playback system 100. The memory 132b can include data storage capable of loading one or more software components executable by the processor 302 to execute those functions. The software components 132c can include applications and / or other executable software configured to facilitate control of the media playback system 100. The memory 112b can be configured to store, for example, the software components 132c, media playback system controller application software, and / or other data related to the media playback system 100 and the user.

[0055] Network interface 132d is configured to facilitate network communication between control device 130a and one or more other devices within media playback system 100 and / or one or more remote devices. In some embodiments, network interface 132 is configured to operate according to one or more suitable communications industry standards (e.g., infrared, wireless, wired standards including IEEE 802.3, wireless standards including IEEE 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.15, 4G, LTE). Network interface 132d can be configured to transmit and / or receive data to, for example, playback device 110, NMD 120, others of control device 130, one of computing devices 106 of FIG. 1B, devices that make up one or more other media playback systems, etc. The data transmitted and / or received can include, for example, control commands for the playback device, state variables, playback zones and / or zone group configurations. For example, based on user input received at user interface 133, network interface 132d can transmit playback device control commands (e.g., volume control, audio playback control, audio content selection) from control device 304 to one or more of playback devices 100. Network interface 132d can also transmit and / or receive configuration changes such as, for example, addition / removal of one or more playback devices 100 to a zone, addition / removal of one or more zones to a zone group, formation of a combined player or integrated player, separation of one or more playback devices from a combined player or integrated player. Details of zones and groups are shown in FIGS. 1-I through 1-M.

[0056] The user interface 133 is configured to receive user input and can facilitate the control of the media playback system 100. The user interface 133 includes media content art 133a (e.g., album art, lyrics, video), a playback status indicator 133b (e.g., elapsed time and / or remaining time indicator), a media content information area 133c, a playback control area 133d, and a zone indicator 133e. The media content information area 133c can include the display of the currently playing media content and / or related information (e.g., title, artist, album, genre, release year) regarding the media content in the queue or playlist. The playback control area 133d includes selectable (e.g., via touch input and / or via a cursor or another suitable selector) icons for causing one or more playback devices in the selected playback zone or zone group to perform playback operations such as play or pause, fast forward, rewind, skip next, skip previous, input / end of shuffle mode, input / end of repeat mode, input / end of crossfade mode, etc. The playback control area 133d may also include selectable icons for changing equalization settings, playback volume, and / or other suitable playback operations. In the illustrated embodiment, the user interface 133 comprises a display presented on the touch screen interface of a smartphone (e.g., iPhone (registered trademark), Android phone). However, in some embodiments, user interfaces of various formats, styles, and interactive sequences may alternatively be implemented on one or more network devices to provide equivalent control access to the media playback system.

[0057] One or more speakers 134 (e.g., one or more transducers) may be configured to output sound to a user of the control device 130a. In some embodiments, the one or more speakers comprise individual transducers configured to output corresponding low frequencies, midrange frequencies, and / or high frequencies. In some aspects, for example, the control device 130a is configured as a playback device (e.g., one of the playback devices 110). Similarly, in some embodiments, the control device 130a is configured as an NMD (e.g., one of the NMDs 120) that receives voice commands and other sounds via one or more microphones 135.

[0058] The one or more microphones 135 can include, for example, one or more condenser microphones, electret condenser microphones, dynamic microphones, and / or other suitable types of microphones or transducers. In some embodiments, two or more microphones 135 are arranged to capture position information of an audio source (e.g., voice, audible sound) and / or are configured to facilitate filtering of background noise. Further, in certain embodiments, the control device 130a is configured to operate as a playback device and an NMD. However, in other embodiments, the control device 130a omits one or more speakers 134 and / or one or more microphones 135. For example, the control device 130a may omit the speaker or microphone and comprise a device (e.g., thermostat, IoT device, network device) that is part of the electronic device 132 and includes a user interface 133 (e.g., touch screen). Embodiments of additional control devices are described in further detail below with respect to FIGS. 4A - 4D and FIG. 5.

[0059] e. Appropriate playback device configuration Figures 1-1 through 1M illustrate exemplary configurations of playback devices in zones and zone groups. First, referring to Figure 1M, in one example, a single playback device can belong to a zone. For example, the playback device 110g in the second bedroom 101c (Figure 1A) may belong to Zone C. In some implementations described below, multiple playback devices can be "bonded" to form a "bonded pair", which together form a single zone. For example, the playback device 110l (e.g., the left playback device) can be bonded to the playback device 110l (e.g., the left playback device) to form Zone A. The bonded playback devices may have different playback responsibilities (e.g., channel responsibilities). In another embodiment described below, multiple playback devices can be merged to form a single zone. For example, the playback device 110h (e.g., the front playback device) may be merged with the playback device 110i (e.g., the subwoofer) and the playback devices 110j and 110k (e.g., the left and right surround speakers respectively) to form a single Zone D. In another example, the playback devices 110g and 110h can be merged to form a merged group or zone group 108b. The merged playback devices 110g and 110h may not be specifically assigned different playback responsibilities. That is, the merged playback devices 110h and 110i can play audio content in the same way as they would if they were not merged, apart from playing audio content synchronously.

[0060] Each zone within the media playback system 100 may be provided for control as a single user interface (UI) entity. For example, Zone A may be provided as a single entity called the master bathroom. Zone B may be provided as a single entity called the master bedroom. Zone C may be provided as a single entity called the second bedroom.

[0061] The combined playback devices can have different playback responsibilities, such as responsibilities for specific audio channels. For example, as shown in FIG. 1-I, playback devices 110l and 110m may be combined to generate or enhance the stereo effect of the audio content. In this example, playback device 110l may be configured to play the audio components of the left channel, while playback device 110k may be configured to play the audio components of the right channel. In some implementations, such stereo combination may be called "pairing".

[0062] Furthermore, the combined playback devices may have additional and / or different respective speaker drivers. As shown in FIG. 1J, a playback device 110h named "front" may be combined with a playback device 110i called "sub". The front device 110h can be configured to render the mid to high frequency range, and the sub device 110i can be configured to render the low frequency. However, when not combined, the front device 110h can be configured to render the full range of frequencies. As another example, FIG. 1K shows a front device 110h and a sub device 110i further combined with a left playback device 110j and a right playback device 110k respectively. In some implementations, the right device 110j and the left device 102k can be configured to form the surround or "satellite" channels of a home theater system. The combined playback devices 110h, 110i, 110j, and 110k can form a single zone D (FIG. 1M).

[0063] The merged playback devices may not be assigned a playback responsibility, and each of the respective playback devices can render the entire range of audio content that each is capable of. Nevertheless, the merged devices may be represented as a single UI entity (i.e., a zone as described above). For example, the playback devices 110a and 110n in the master bathroom have a single UI entity for Zone A. In one embodiment, each of the playback devices 110a and 110n can output the entire range of audio content that the respective playback devices 110a and 110n can synchronize to.

[0064] In some embodiments, the NMD is combined or merged with another device to form a zone. For example, the NMD 120b may be combined with the playback device 110e that together forms Zone F, also called the living room. In other embodiments, a stand-alone network microphone device may itself be within a zone. However, in other embodiments, a stand-alone network microphone device may not be associated with a zone. Further details regarding associating a network microphone device with a playback device as a designated device or a default device can be found, for example, in the previously referenced U.S. Patent Application Publication No. 15 / 438,749.

[0065] Zones of individual, combined, and / or merged devices can be grouped to form zone groups. For example, referring to FIG. 1M, zone A can be grouped with zone B to form zone group 108a that includes two zones. Similarly, zone G can be grouped with zone H to form zone group 108b. As another example, zone A may be grouped with one or more other zones C-I. Zones A-I can be grouped and ungrouped in a number of ways. For example, three, four, five, or more (e.g., all) of zones A-I may be grouped. When grouped, zones of individual and / or combined playback devices can play audio in synchronization with each other as described in the previously referenced U.S. Patent No. 8,234,395. Playback devices may be dynamically grouped and ungrouped to form new or different groups that play audio content in synchronization.

[0066] In various embodiments, the zones within the environment may be a combination of the default names of the zones within the group or the names of the zones within the zone group. For example, zone group 108b can be assigned a name such as "Dining + Kitchen" as shown in FIG. 1M. In some embodiments, the zone group may be given a unique name selected by the user.

[0067] Certain data may be stored in the memory of a playback device (e.g., memory 112c of FIG. 1C) as one or more state variables that are periodically updated and used to describe the state of the playback zone, playback device, and / or associated zone group. The memory may also be associated with the states of other devices of the media system and can include data that is sometimes shared between devices so that one or more of the devices have the most recent data associated with the system.

[0068] In some embodiments, the memory can store instances of various variable types related to the state. The variable instances can be stored together with an identifier (e.g., a tag) corresponding to the type. For example, a particular identifier may be a first type "a1" for identifying a playback device of a zone, a second type "b1" for identifying playback devices that can be combined within the zone, and a third type "c1" for identifying a zone group to which the zone can belong. As a related example, the identifier associated with the second bedroom 101c can indicate that the playback device is the only playback device in zone C rather than within a zone group. The identifier associated with the den can indicate that the den is not grouped with other zones but includes the combined playback devices 110h to 110k. The identifier associated with the dining room can indicate that the dining room is part of the dining + kitchen zone group 108b and that devices 110b and 110d are grouped (FIG. 1L). The identifier associated with the kitchen can indicate the same or similar information by virtue of the kitchen being part of the dining + kitchen zone group 108b. Other exemplary zone variables and identifiers are described below.

[0069] In yet another example, as shown in FIG. 1M, the media playback system 100 can store variables or identifiers that represent other associations of zones and zone groups, such as identifiers associated with an area. The area can include clusters of zone groups and / or zones that are not within a zone group. For example, FIG. 1M shows an upper area 109a that includes zones A - D and a lower area 109b that includes zones E - I. In one aspect, the area can be used to call a cluster of zone groups and / or zone groups of zones and / or another cluster that share one or more zones. In another aspect, this is different from a zone group that does not share zones with another zone group. Further examples of techniques for implementing areas can be found, for example, in U.S. Patent Application Publication No. 15 / 682,506, filed on August 21, 2017, entitled "Room Association Based on Name", and U.S. Patent No. 8,483,853, filed on September 11, 2007, entitled "Controlling and manipulating groupings in a multi - zone media system". Each of these applications is hereby incorporated by reference in its entirety. In some embodiments, the media playback system 100 may not implement areas, in which case the system may not store variables associated with areas.

[0070] In a further example, the playback device 110 of the media playback system 100 is named and arranged according to a control hierarchy called a home graph. Under the home graph hierarchy, the basic unit of the home graph hierarchy is a "set". A "set" refers to individual devices or a plurality of devices that operate together when performing a given function, such as an individual playback device 110 or a combined zone of playback devices. After the set, the next level of the hierarchy is a "room". Under the home graph hierarchy, a "room" can be considered as a storage location for a set of a given room in a house. For example, an exemplary room corresponds to the kitchen of a home, is assigned the name "kitchen", and can include one or more sets (e.g., "kitchen island"). The next level of an exemplary home graph hierarchy is an "area" that includes two or more rooms (e.g., "upper floor" or "lower floor"). The top level of the home graph hierarchy is "home". Home refers to the entire house and all the sets within it. Each level of the home graph hierarchy is assigned a human-readable name to facilitate control via the GUI and VUI. Further details regarding the home graph control hierarchy can be found, for example, in U.S. Patent Application Publication No. 16 / 216,357, entitled "Home Graph", which is hereby incorporated by reference in its entirety.

[0071] III. Exemplary Systems and Devices FIG. 2A is a front isometric view of a playback device 210 configured according to an aspect of the disclosed technology. FIG. 2B is a front isometric view of the playback device 210 without a grill 216e. FIG. 2C is an exploded view of the playback device 210. Referring collectively to FIGS. 2A-2C, the playback device 210 includes a housing 216 that includes an upper portion 216a, a right or first side portion 216b, a lower portion 216c, a left or second side portion 216d, a grill 216e, and a rear portion 216f. A plurality of fasteners 216g (e.g., one or more screws, rivets, clips) attach a frame 216h to the housing 216. A cavity 216j (FIG. 2C) within the housing 216 is configured to receive the frame 216h and the electronic device 212. The frame 216h is configured to carry a plurality of transducers 214 (individually identified as transducers 214a-f in FIG. 2B). The electronic device 212 (e.g., the electronic device 112 of FIG. 1C) is configured to receive audio content from an audio source and transmit an electrical signal corresponding to the audio content to the transducers 214 for playback.

[0072] The transducer 214 is configured to receive an electrical signal from the electronic device 112 and is further configured to convert the received electrical signal into audible sound during playback. For example, the transducers 214a-c (e.g., tweeters) can be configured to output high-frequency sound waves (e.g., sound waves having a frequency exceeding about 2 kHz). The transducers 214d-f (e.g., mid-woofers, woofers, mid-range speakers) can be configured to output sound at a lower frequency than the transducers 214a-c (e.g., sound waves having a frequency lower than about 2 kHz). In some embodiments, the playback device 210 includes some transducers different from those shown in FIGS. 2A-2C. For example, the playback device 210 can include less than six transducers (e.g., 1, 2, 3). However, in other embodiments, the playback device 210 includes more than six (e.g., 9, 10) transducers. Further, in some embodiments, all or a portion of the transducers 214 are configured to operate as a phased array to preferably adjust (e.g., narrow or widen) the radiation pattern of the transducers 214, thereby changing the perception of the sound emitted from the user's playback device 210.

[0073] In the illustrated embodiment of FIGS. 2A-2C, the filter 216i is axially aligned with the transducer 214b. The filter 216i can be configured to preferably attenuate a predetermined frequency range output by the transducer 214b to improve the sound quality and perceived acoustic stage collectively output by the transducers 214. However, in some embodiments, the playback device 210 omits the filter 216i. In other embodiments, the playback device 210 includes one or more additional filters aligned with the transducer 214b and / or at least another one of the transducers 214.

[0074] Figures 3A and 3B are, respectively, a front view and a right isometric side view of an NMD320 configured according to an embodiment of the disclosed technology. Figure 3C is an exploded view of the NMD320. Figure 3D is an enlarged view of a portion of Figure 3B including the user interface 313 of the NMD320. Referring first to Figures 3A-3C, the NMD320 includes a housing 316 having an upper portion 316a, a lower portion 316b, and an intermediate portion 316c (e.g., a grill). A plurality of ports, holes, or openings 316d in the upper portion 316a allow sound to pass to one or more microphones 315 (Figure 3C) disposed within the housing 316. The one or more microphones 316 are configured to receive sound via the openings 316d and generate an electrical signal based on the received sound. In the illustrated embodiment, the frame 316e (Figure 3C) of the housing 316 surrounds cavities 316f and 316g configured to house a first transducer 314a (e.g., a tweeter) and a second transducer 314b (e.g., a midwoofer, midrange speaker, woofer), respectively. However, in other embodiments, the NMD320 includes a single transducer, or three or more (e.g., 2, 5, 6) transducers. In certain embodiments, the NMD320 completely omits the transducers 314a and 314b.

[0075] The electronic device 312 (Figure 3C) is configured to drive the transducers 314a and 314b and further includes components configured to analyze audio data corresponding to the electrical signals generated by the one or more microphones 315. In some embodiments, for example, the electronic device 312 includes many or all of the components of the electronic device 112 described above with respect to Figure 1C. In certain embodiments, the electronic device 312 includes the components described above with respect to Figure 1F, such as, for example, one or more processors 112a, a memory 112b, software components 112c, a network interface 112d. In some embodiments, the electronic device 312 includes additional suitable components (e.g., proximity or other sensors).

[0076] Referring to FIG. 3D, the user interface 313 includes a plurality of control surfaces (e.g., buttons, knobs, capacitive surfaces) including a first control surface 313a (e.g., previous control), a second control surface 313b (e.g., next control), and a third control surface 313c (e.g., play and / or pause control). A fourth control surface 313d is configured to receive touch-based input corresponding to activation and deactivation of one or more microphones 315. A first indicator 313e (e.g., one or more light-emitting diodes (LEDs) or another suitable lighting device) may be configured to light only when one or more microphones 315 are activated. A second indicator 313f (e.g., one or more LEDs) may be configured to remain lit during normal operation and blink or otherwise change from lit to indicate detection of voice activity. In some embodiments, the user interface 313 includes additional or fewer control surfaces and lighting devices. In one embodiment, for example, the user interface 313 includes the first indicator 313e without the second indicator 313f. Further, in certain embodiments, the NMD 320 includes a playback device and a control device, and the user interface 313 includes the user interface of the control device.

[0077] Referring to FIGS. 3A - 3D together, NMD320 is configured to receive voice commands from one or more adjacent users via one or more microphones 315. As described above with respect to FIG. 1B, one or more microphones 315 can acquire, capture, or record sounds in the vicinity (e.g., an area within 10 m from NMD320) and transmit an electrical signal corresponding to the recorded sound to the electronic device 312. The electronic device 312 can process the electrical signal and analyze the resulting audio data to determine the presence of one or more voice commands (e.g., one or more activation words). In some embodiments, for example, after detecting one or more appropriate voice commands, NMD320 is configured to transmit a portion of the recorded audio data to another device and / or a remote server (e.g., one or more of the computing devices 106 of FIG. 1B) for further analysis. The remote server can analyze the audio data, determine an appropriate action based on the voice command, and transmit a message to NMD320 to execute the appropriate action. For example, a user can say "Sonos, play Michael Jackson." NMD320 can record the user's voice utterance via one or more microphones 315, determine the presence of a voice command, and transmit the audio data having the voice command to a remote server (e.g., one or more of the remote computing devices 106 of FIG. 1B, one or more servers of VAS, and / or another appropriate service). The remote server can analyze the audio data and determine an action corresponding to the command. The remote server can then transmit a command to NMD320 to execute the determined action (e.g., play audio content related to Michael Jackson). NMD320 can receive this command and play the audio content related to Michael Jackson from the media content source.As described above with respect to FIG. 1B, suitable content sources can include devices or storage communicatively coupled to the NMD320 via a LAN (e.g., network 104 of FIG. 1B), a remote server (e.g., one or more of the remote computing devices 106 of FIG. 1B), etc. However, in certain embodiments, the NMD320 determines and / or executes one or more actions corresponding to one or more voice commands without the intervention or involvement of an external device, computer, or server.

[0078] Figures 4A - 4D are schematic diagrams of a control device 430 (e.g., control device 130a of FIG. 1H, smartphone, tablet, dedicated control device, IoT device, and / or another suitable device) showing corresponding user interface displays in various operating states. The first user interface display 431a (FIG. 4A) includes a display name 433a (i.e., "Room"). In the selected group area 433b, audio content information (e.g., artist name, track name, album art) of the audio content played in the selected group and / or zone is displayed. The group areas 433c and 433d display the corresponding group and / or zone names, as well as the audio content information of the audio content to be played or played next in the playback queue of each group or zone, and the audio content. The audio content area 433e includes information regarding the audio content within the selected group and / or zone (i.e., the group and / or zone shown in the selected group area 433b). The lower display area 433f is configured to receive touch input and display one or more other user interface displays. For example, when the user selects "Browse" in the lower display area 433f, the control device 430 can be configured to output a second user interface display 431b (FIG. 4B) with a plurality of music services 433g (e.g., Spotify, Radio by TuneIn, Apple Music, Pandora, Amazon, TV, Local Music, Line In), and the user can browse media content for playback via one or more playback devices (e.g., one of the playback devices 110 of FIG. 1A) from this display and also select media content for playback. Alternatively, when the user selects "My Sonos" within the lower display area 433f, the control device 430 can be configured to output a third user interface display 431c (FIG. 4C).The first media content area 433h can include a graphical representation (e.g., album art) corresponding to an individual album, station, or playlist. The second media content area 433i can include a graphical representation (e.g., album art) corresponding to an individual song, track, or other media content. When the user selects the graphical representation 433j (Figure 4C), the control device 430 can be configured to start playing the audio content corresponding to the graphical representation 433j and output a fourth user interface display 431d that includes an enlarged version of the graphical representation 433j, media content information 433k (e.g., track name, artist, album), transport control 433m (e.g., play, rewind, fast forward, pause, volume), and a display 433n of the currently selected group and / or zone name.

[0079] Figure 5 is a schematic diagram of a control device 530 (e.g., a laptop computer, a desktop computer). The control device 530 includes a transducer 534, a microphone 535, and a camera 536. The user interface 531 includes a transport control area 533a, a playback status area 533b, a playback zone area 533c, a playback queue area 533d, and a media content source area 533e. The transport control area includes one or more controls for controlling media playback, including, for example, volume, forward, play / pause, next, repeat, shuffle, track position, crossfade, equalization, etc. The audio content source area 533e includes a list of one or more media content sources from which the user can select media items for playback and / or addition to the playback queue.

[0080] The playback zone area 533b can include a representation of a playback zone within the media playback system 100 (FIGS. 1A and 1B). In some embodiments, the graphical representation of the playback zone may be selectable to display additional selectable icons for managing or configuring the playback zones in the media playback system, such as creating combined zones, creating zone groups, separating zone groups, renaming zone groups, etc. In the illustrated embodiment, a "group" icon is provided within each of the graphical representations of the playback zones. The "group" icon provided within the graphical representation of a particular zone may be selectable to display an option for selecting one or more other zones within the media playback system to be grouped with the particular zone. When grouped, the playback devices within the zone or zones grouped with the particular zone can be configured to play audio content in synchronization with the playback devices within the particular zone. Similarly, a "group" icon can be provided within the graphical representation of the zone group. In the illustrated embodiment, the "group" icon can be made selectable to display an option for deselecting one or more zones within the zone group that are to be removed from the zone group. In some embodiments, the control device 530 includes other interactions and implementations for grouping and ungrouping zones via the user interface 531. In a particular embodiment, the representation of the playback zones within the playback zone area 533b can be dynamically updated when the playback zone or zone group configuration is changed.

[0081] The playback status area 533c includes a graphical representation of audio content that is currently playing, previously played, or scheduled to play next in the selected playback zone or zone group. The selected playback zone or zone group may be visually distinguished in the user interface, such as within the playback zone area 533b and / or the playback queue area 533d. The graphical representation may include the track title, artist name, album name, album year, track length, and other relevant information that may be useful for the user to know when controlling the media playback system 100 via the user interface 531.

[0082] The playback queue area 533d includes a graphical representation of audio content within a playback queue associated with a selected playback zone or zone group. In some embodiments, each playback zone or zone group may be associated with a playback queue that includes information corresponding to zero or more audio items for playback by the playback zone or zone group. For example, each audio item within the playback queue can comprise a Uniform Resource Identifier (URI), a Uniform Resource Locator (URL), or some other identifier that can be used by a playback device within the playback zone or zone group to discover and / or retrieve the audio item from a local audio content source or a networked audio content source for playback by the playback device, as the case may be. In some embodiments, for example, a playlist can be added to the playback queue and information corresponding to each audio item within the playlist can be added to the playback queue. In some embodiments, the audio items within the playback queue may be saved as a playlist. In certain embodiments, the playback queue may be empty or pre-set but "unused" when the playback zone or zone group is continuously streaming playback of audio content such as Internet radio that can be played continuously until stopped rather than individual audio items having a playback duration. In some embodiments, the playback queue can include Internet radio and / or other streaming audio content items and can be "in use" when the playback zone or zone group is playing those items.

[0083] When a playback zone or zone group is "grouped" or "ungrouped", the playback queue associated with the affected playback zone or zone group can be cleared or re-associated. For example, if a first playback zone containing a first playback queue is grouped with a second playback zone containing a second playback queue, the established zone group can have a playback queue associated with audio items from the first playback queue (such as when the second playback zone is added to the first playback zone), which was initially empty, audio items from the second playback queue (such as when the first playback zone is added to the second playback zone), or a combination of audio items from both the first and second playback queues. Subsequently, when the established zone group is ungrouped, the resulting first playback zone may be re-associated with the previous first playback queue, or, prior to the established zone group being ungrouped, may be associated with a new playback queue that is empty or contains audio items from the playback queue associated with the established zone group. Similarly, the resulting second playback zone may be re-associated with the previous second playback queue, or may be associated with a new playback queue that is empty or contains audio items from the playback queue associated with the established zone group prior to the established zone group being ungrouped.

[0084] FIG. 6 is a flow diagram of messages showing data exchange between devices of the media playback system 100 (FIGS. 1A - 1M).

[0085] In step 650a, the media playback system 100 receives a display of selected media content (e.g., one or more songs, albums, playlists, Podcasts, videos, stations) via the control device 130a. The selected media content can include, for example, media items locally stored on one or more devices (e.g., the audio source 105 of FIG. 1C) connected to the media playback system and / or media items stored on one or more media service servers (one or more of the remote computing devices 106 of FIG. 1B). In response to receiving the display of the selected media content, the control device 130a sends a message 651a to the playback device 110a (FIGS. 1A-1C) to add the selected media content to the playback queue of the playback device 110a.

[0086] In step 650b, the playback device 110a receives the message 651a and adds the selected media content for playback to the playback queue.

[0087] In step 650c, the control device 130a receives an input corresponding to a command to play the selected media content. In response to receiving the input corresponding to the command to play the selected media content, the control device 130a sends a message 651b to the playback device 110a to cause the playback device 110a to play the selected media content. In response to receiving the message 651b, the playback device 110a sends a message 651c to the computing device 106a to request the selected media content. In response to receiving the message 651c, the computing device 106a sends a message 651d containing data (e.g., audio data, video data, URL, URI) corresponding to the requested media content.

[0088] In step 650d, the playback device 110a receives a message 651d having data corresponding to the requested media content and plays the associated media content.

[0089] In step 650e, the playback device 110a optionally causes one or more other devices to play the selected media content. In one example, the playback device 110a is one of the combined zones of two or more players (FIG. 1M). The playback device 110a can receive the selected media content and transmit all or part of the media content to other devices within the combined zone. In another example, the playback device 110a is a group coordinator and is configured to transmit and receive timing information from one or more other devices within the group. One or more other devices within the group can receive the selected media content from the computing device 106a and can start playing the selected media content in response to a message from the playback device 110a, whereby all devices within the group play the selected media content synchronously.

[0090] IV. Exemplary Synchronous Grouping Techniques Examples of contemporaneous techniques include a group coordinator providing audio content and timing information to one or more group members to facilitate synchronous playback between the group coordinator and the group members. In some embodiments, at least some aspects of the technical solution are derived from the technical structure and configuration of audio information, playback timing, and clock timing information used by playback devices to play audio content from an audio source in synchronization with each other, where different playback devices generate playback timing based on clock timing (local clock timing or remote clock timing), and play the audio content based on the playback timing (generated locally or remotely) and the clock timing (generated locally or remotely). Accordingly, to aid in the understanding of certain aspects of the disclosed technical solution, specific technical details of the audio information, playback timing, and clock timing information, as well as how the playback timing and clock timing for playing audio content with different configurations of the playback devices are generated and / or used, are described below.

[0091] a. Audio content The audio content may be any type of audio content known currently or developed later. For example, in some embodiments, the audio content is (i) streaming music or other audio obtained from a streaming media service, such as Spotify, Pandora, or other streaming media services; (ii) streaming music or other audio from a local music library, such as a music library stored on the user's laptop computer, desktop computer, smartphone, tablet, home server, or other computing device known currently or developed later; (iii) audio content related to video content, such as audio related to a TV program or movie received from any of a TV, set-top box, digital video recorder, digital video disc player, streaming video service, or any other source of audio-visual media content known currently or developed in the future; (iv) text-to-speech or other audible content from a voice assistant service (VAS), such as Amazon's Alexa or other VAS services known currently or developed in the future; (v) audio content from a doorbell or intercom system, such as Nest, Ring, or other doorbell or intercom systems known currently or developed in the future; and / or (vi) audio content from any one or more of a telephone, videophone, video / telephone conference system, or other application configured such that users can communicate with each other via audio and / or video.

[0092] In operation, the "source" playback device refers to a playback device that captures, via an interface, any of the aforementioned types of audio content from an audio source, where the interface is, for example, a network interface of the source playback device, a "line-connected" analog interface, a digital audio interface, or any one of the interfaces suitable for receiving audio content in digital or analog formats currently known or developed in the future.

[0093] An audio source is any system, device, or application that generates, provides, or makes available any of the aforementioned audio content to the playback device. For example, in some embodiments, the audio source includes any one or more of a streaming media (audio, video) service, a digital media server or other computing system, a VAS service, a television, a cable set-top box, a streaming media player (e.g., Apple TV, Roku, game console), a CD / DVD player, a doorbell, an intercom, a phone, a tablet, or any other source of digital audio content.

[0094] A playback device that receives or obtains audio content from an audio source and plays it and / or receives or obtains it and distributes it to other playback devices is referred to herein as a "source" playback device, a "master" playback device, or a "group coordinator". One function of the "source" playback device is to process and play the received audio content and / or distribute it to other playback devices. In some embodiments, the source playback device transmits the processed audio content to all playback devices configured to play that audio content. In some embodiments, the source playback device transmits the processed audio content to a multicast network address, and all other playback devices configured to play the audio content receive the audio content via that multicast address. In some embodiments, the source playback device alternatively transmits the processed audio content to the unicast network address of each other playback device configured to play the audio content, and each other playback device configured to play the audio content receives the audio content via that unicast address.

[0095] In some embodiments, the "source" playback device receives audio content in digital form, e.g., as a stream of packets, from an audio source. In some embodiments, individual packets within the packet stream have a sequence number or other identifier that specifies the order of the packets. Since packets transmitted via a data packet network (e.g., Ethernet, WiFi, or other packet network) may arrive out of order, the source playback device uses the sequence number or other identifier to reassemble the packet stream in the correct order before performing further packet processing. In some embodiments, the sequence number or other identifier that specifies the order of the packets is a timestamp that indicates the time at which the packet was created, or at least includes it. The packet creation time can be used as a sequence number based on the assumption that the packets are created in the order in which they are to be played back next.

[0096] In some embodiments, the source playback device does not change the sequence number or identifier of received packets during packet processing. In some embodiments, the source playback device rearranges at least a first set of packets within the packet stream based on the sequence identifier of each packet, extracts audio content from the received packets, reassembles the bitstream of the audio content from the received packets, and then repackages the reassembled bitstream into a second set of packets, where the packets within the second set of packets have a sequence number different from the sequence number of the packets within the first set of packets. In some embodiments, the individual packets within the second set of packets are of a different length (i.e., shorter or longer) than the individual packets within the first set of packets. In some embodiments, by reassembling the bitstream from the incoming packets and then repackaging the reassembled bitstream into a different set of packets, uniform processing and / or transmission of the audio content by the source playback device and other playback devices receiving the audio content from the source playback device is facilitated. However, for some audio content that is susceptible to some delays, reassembly and repackaging may not be desirable, and thus, in some embodiments, the source playback device may not perform reassembly and repackaging for some (or all) of the audio content received before playing the audio content and / or before transmitting the audio content to other playback devices.

[0097] In some embodiments, the audio source provides digital-form audio content to the source playback device via, for example, a digital line connection interface. In such embodiments, the source playback device packets the digital audio into packets of the audio content before transmitting the audio content to other playback devices. In some embodiments, the individual packets of the audio content include a sequence number or other identifier such that when the other playback devices receive the audio content, the received packets can be reliably arranged in the correct order before those other playback devices perform further packet processing.

[0098] In some embodiments, the audio source provides analog-form audio content to the source playback device via, for example, an analog line connection interface. In such embodiments, the source playback device converts the received analog audio to digital audio and packets the digital audio into packets of the audio content before transmitting the audio content to other playback devices. In some embodiments, the individual packets of the audio content include a sequence number or other identifier such that when the other playback devices receive the audio content, the received packets can be reliably arranged in the correct order before those other playback devices perform further packet processing.

[0099] After obtaining audio content from the audio source or another playback device, in some embodiments, the playback device performs one or more of: (i) playing the audio content individually, (ii) playing the content in synchronization with one or more additional playback devices, and / or (iii) transmitting the audio content to one or more other playback devices.

[0100] b. Playback timing The playback devices disclosed and described herein use playback timing to play audio content in synchronization with each other. Each individual playback device can generate playback timing and / or playback audio content according to the playback timing based on the configuration of the playback devices in the media playback network. Also, the source playback device that generated the playback timing of the audio content transmits the generated playback timing to all playback devices configured to play the audio content. In some embodiments, the source playback device transmits the playback timing to a multicast network address, and all other playback devices configured to play the audio content receive the playback timing via that multicast address. In some embodiments, the source playback device alternatively transmits the playback timing to the unicast network address of each other playback device configured to play the audio content, and each other playback device configured to play the audio content receives the playback timing via that unicast address.

[0101] In operation, a playback device (or a computing device associated with the playback device) generates the playback timing of the audio content based on a clock timing (described below) that can be a "local" clock timing (i.e., the clock timing generated by the source playback device) or a "remote" clock timing received from a different playback device (or a different computing device).

[0102] In some embodiments, the playback timing is generated for individual frames (or packets) of the audio content. As described above, in some embodiments, the audio content is packaged into a series of frames (or packets) where the individual frames (or packets) contain a portion of the audio content. In some embodiments, the playback timing of the audio content includes the playback time of each frame (or packet) of the audio content. In some embodiments, the playback timing of an individual frame (or packet) is included within the frame (or packet), for example, in the header of the frame (or packet), the extended header of the frame (or packet), and / or the payload portion of the frame (or packet).

[0103] In some embodiments, the playback time of an individual frame (or packet) is identified within a timestamp or other indication. In such embodiments, the timestamp (or other indication) represents the point in time at which the audio content within that individual frame (or packet) is to be played. In operation, when the playback timing of an individual frame (or packet) is generated, the playback timing of that individual frame (or packet) is a future time relative to the current clock time of the reference clock at the time the playback timing of that individual frame (or packet) was generated. The reference clock can be a "local" clock in the playback device or a separate network device, for example, a "remote" clock in another playback device, a computing device, or another network device configured to provide clock timing for the playback device to use in generating playback timing and / or playback audio content.

[0104] In operation, a playback device responsible for playing a specific audio content plays a part of the specific audio content within an individual frame (or packet) at the playback time specified at the playback timing of that individual frame (or packet). However, as will be described in more detail below, an adjustment is made to adapt the clock timing difference between the source playback device and the playback device responsible for playing the audio content.

[0105] c. Clock Timing The playback devices disclosed and described in this specification use clock timing to generate the playback timing of audio content and play the audio content based on the generated playback timing. In some embodiments, the source playback device uses the clock timing from a reference clock (e.g., a device clock, a digital - to - audio converter clock, a playback time reference clock, or any other clock) to generate the playback timing of the audio content that the source playback device receives from an audio source. The reference clock of an individual playback device uses the "local" clock in the playback device or the "remote" clock in a separate network device, e.g., another playback device, a computing device, or another network device configured to provide the timing of a clock for the playback device to use for generating playback timing and / or the playback audio content.

[0106] In some embodiments, all of the playback devices responsible for playing a specific audio content synchronously use the same clock timing to play that specific audio content. In some embodiments, all playback devices use the same clock timing to play the audio content that was used to generate the playback timing of the audio content.

[0107] In operation, a network device that generates clock timing transmits the clock timing to all playback devices in the network that need to use the clock timing for generating playback timing and / or playing audio content. In some embodiments, the network device that generates clock timing transmits the clock timing to a multicast network address, and all other playback devices configured to generate playback timing and / or play audio content receive the clock timing via that multicast address. In some embodiments, the network device alternatively transmits the clock timing to each of the other playback devices configured to play audio content at a unicast network address, and each of the other playback devices configured to play audio content receives the clock timing via that unicast address.

[0108] d. Generation of Playback Timing Using Clock Timing from a Local Clock In some embodiments, a source playback device (i) generates playback timing for audio content based on clock timing from a local clock in the source playback device, and (ii) transmits the generated playback timing to all other playback devices configured to play the audio content. In operation, when generating the playback timing for an individual frame (or packet), the "source" playback device adds a "timing advance" to the current clock time of the local clock of the source playback device that the source playback device is using to generate the playback timing.

[0109] In some embodiments, the "timing advance amount" is determined based on an amount of time that is greater than the sum of (i) the network transmission time, which is the time required for a frame and / or packet containing audio content to be transmitted from the source playback device and reach all other playback devices configured to use the playback timing to synchronously play the audio content, and (ii) the time required for playback, which is the time in all other playback devices for processing the frame / packet received from the source playback device using that playback timing for synchronous playback.

[0110] In some embodiments, the source playback device determines the timing advance amount by transmitting one or more test packets to one or more (or perhaps all) of the other playback devices configured to play the audio content being transmitted by the source device, and then receiving test response packets returning from those one or more of the other playback devices. In some embodiments, the source playback device and one or more other playback devices determine the timing advance amount through negotiation (mutual interaction) via a plurality of test and response messages. In some embodiments having three or more additional playback devices, the source playback device exchanges test and response messages with all playback devices and then determines the timing advance amount by setting a timing advance amount sufficient for the playback device with the longest total network transmission time and packet processing time.

[0111] In some embodiments, the timing advance amount is less than about 50 milliseconds. In some embodiments, the timing advance amount is less than about 20 to 30 milliseconds. Further, in additional embodiments, the timing advance amount is less than about 10 milliseconds. In some embodiments, the timing advance amount remains constant after being determined. In other embodiments, the playback device that generates the playback timing can change the timing advance amount in response to a request from a receiving device indicating that a larger timing advance amount is needed (e.g., because the receiving device has not received a packet containing a portion of the audio content until after another device has already played that portion of the audio content), or that a shorter timing advance amount is sufficient (e.g., because the receiving device has buffered more packets containing portions of the audio content than are required to provide consistent and reliable playback).

[0112] As will be described in more detail below, all playback devices configured to play audio content synchronously use playback timing and clock timing to play the audio content in synchronization with each other.

[0113] e. Playback of audio content using local playback timing and local clock timing In some embodiments, the source playback device is configured to play audio content in synchronization with one or more other playback devices. Also, if the source playback device uses clock timing from a local clock in the source playback device to generate the playback timing, the source playback device plays the audio content using the locally generated playback timing and the locally generated clock timing. In operation, the source playback device plays an individual frame (or packet) containing a portion of the audio content when the local clock used by the source playback device to generate the playback timing reaches the time specified in the playback timing of that individual frame (or packet).

[0114] For example, as described above, when the source playback device generates the playback timing of individual frames (or packets), it adds a "timing advance amount" to the current clock time of the reference clock used to generate the playback timing. In this case, the reference clock used to generate the playback timing is the local clock in the source playback device. Therefore, when the timing advance amount of an individual frame is, for example, 30 milliseconds, the source playback device plays back the audio content portion (e.g., samples or a set of samples) of the individual frame (or packet) 30 milliseconds after generating the playback timing of the individual frame (or packet).

[0115] In this way, the source playback device plays back the audio content using the locally generated playback timing and the clock timing from the local reference clock. As will be further described below, when the clock time of the local reference clock reaches the playback timing of an individual frame or packet, the audio content portion of the individual frame and / or packet is played back, but the source playback device plays back that portion of the audio content of the individual frame and / or packet in synchronization with other playback devices.

[0116] f. Playback of Audio Content Using Remote Playback Timing and Remote Clock Timing As described above, in some embodiments, the source playback device transmits the audio content and the playback timing of the audio content to one or more other playback devices. Also, in some embodiments, the network device that provides the clock timing can be a device different from the source playback device. The playback device that receives the audio content, the playback timing, and the clock timing from the other playback devices is configured to play the audio content using the playback timing from the source playback device (i.e., the remote playback timing) and the clock timing from the clock of the other playback device (i.e., the remote clock timing). In this way, the receiving-side playback device in this example plays the audio content using the remote playback timing and the remote clock timing.

[0117] The receiving playback device tasked with playing audio content in synchronization with all other playback devices receives (i) frames (or packets) containing portions of the audio content from the source playback device to play the individual frames (or packets) of the audio content, (ii) the playback timing of the audio content (e.g., in the frame header and / or packet header of the frame and / or packet containing the portion of the audio content, or in some cases in a location separate from the frame and / or packet containing the portion of the audio content) from the source playback device, (iii) clock timing from another network device, e.g., another playback device, a computing device, or another network device configured to provide clock timing for use by the playback device to generate the playback timing and / or the playback audio content, and (iv) plays the portion of the audio content of the individual frame (or packet) when the local clock used by the receiving playback device for playing the audio content reaches the playback time specified by the playback timing of the individual frame (or packet), adjusted by the "timing offset" received from the source playback device.

[0118] In operation, after a receiving playback device receives clock timing from another network device, the receiving playback device determines a "timing offset" for the receiving playback device. This "timing offset" includes (or at least corresponds to) the difference between a "reference" clock in the network device used by the network device to generate the clock timing and a "local" clock in the receiving playback device used by the receiving playback device to play the audio content. In operation, each playback device that receives clock timing from another network device calculates its own "timing offset" based on the difference between its own local clock and the clock timing. Thus, the "timing offset" determined by each playback device is unique to that playback device.

[0119] In some embodiments, when playing audio content, the receiving playback device generates a new playback timing (unique to the receiving playback device) for individual frames (or packets) of the audio content by adding the previously determined "timing offset" to the playback timing of each frame (or packet) received from the source playback device. In this approach, the receiving playback device converts the playback timing of the audio content received from the source playback device to the "local" playback timing of the receiving playback device. Since each receiving playback device calculates its own "timing offset", the "local" playback timing determined for individual frames is unique to that playback device.

[0120] Also, when the "local" clock used by the receiving-side playback device to play the audio content reaches the "local" playback time of each individual frame (or packet), the receiving-side playback device plays the audio content (or a portion thereof) associated with that individual frame (or packet). As described above, in some embodiments, the playback timing of a particular frame (or packet) is in the header of the frame (or packet). In other embodiments, the playback timing of each individual frame (or packet) is transmitted separately from the frame (or packet) containing the audio content.

[0121] The receiving-side playback device plays the frame (or packet) containing the portion of the audio content according to the playback timing adjusted by the "timing offset" with respect to the clock timing, and the source playback generates the playback timing of those frames (or packets) with respect to the clock timing, and plays the same frame (or packet) containing the portion of the audio content according to the playback timing and the determined "timing offset". Therefore, the receiving-side playback device and the source playback device synchronize, that is, play the same frame (or packet) containing the same portion of the audio content at the same time or substantially at the same time.

[0122] Further details regarding audio playback synchronization between playback devices and / or zones are disclosed, for example, in U.S. Patent No. 8,234,395 entitled "System and method for synchronizing operations among a plurality of independently clocked digital data processing devices", the entire disclosure of which is incorporated herein by reference.

[0123] V. Exemplary Portable Playback Device As described above, implementations of certain playback devices may be configured for portable use. These portable implementations include portable devices designed for a single user to privately listen to loud audio at a time, and wearable playback devices such as headphones and earbuds. FIG. 7A is a partial cutaway view of a media playback system 100 including one or more portable playback devices 710 (individually identified as portable playback devices 710a, 710b, and 710c). The portable playback device 710 is similar to the playback device 110 but is configured for portability. Although shown within a home in FIG. 7A, the portable playback device 710 is configured to play audio content within the home as well as "on the go".

[0124] As shown in the block diagram of FIG. 7B, the portable playback device 710a includes the same or similar components as the playback device 110a. However, to facilitate portable use, the playback device 710a may be implemented in a specific form factor (e.g., headphones or earbuds) and includes one or more batteries in power 712i to supply portable power.

[0125] Referring to FIG. 7B, the portable playback device 710a includes an input / output 711 that can include analog I / O 711a and / or digital I / O 711b similar to the components of the playback device 110. To facilitate portable use, the input / output 711 of the portable playback device 710a can include an interface (such as a Bluetooth interface) to facilitate connection to a bridge device (e.g., a mobile device), and the portable playback device 710a can be used to stream audio content via the bridge device or communicate with the bridge device.

[0126] The playback device 710a further includes an electronic device 712, a user interface 713 (e.g., one or more buttons, knobs, dials, touch-sensitive surfaces, displays, touchscreens), and one or more transducers 714 (hereinafter referred to as "transducer 714"). The electronic device 712 is configured to receive audio from an audio source via the input / output 711, receive audio from one or more of the computing devices 106a-c via the network 104 (FIG. 1B), amplify the received audio, and output the amplified audio for playback via one or more of the transducers 714.

[0127] In some embodiments, the playback device 710a optionally includes one or more microphones 715 (e.g., a single microphone, multiple microphones, microphone array) (hereinafter referred to as "microphone 715"). In some examples, the microphone 715 can include one or more voice microphones to facilitate voice input for things such as calls. In certain embodiments, for example, the playback device 710a can operate as an NMD (similar to NMD 120 in FIG. 1F) configured to receive voice input from a user using the voice microphone and perform corresponding one or more operations based on the received voice input. In further examples, the microphone 715 can include one or more acoustic noise cancellation (ANC) microphones that capture ambient noise in the environment to facilitate cancellation of ambient noise by the playback device 710a during operation.

[0128] In the illustrated embodiment of FIG. 7B, the electronic device 712 includes one or more processors 712a (hereinafter referred to as "processor 112a"), a memory 712b, software components 712c, a network interface 712d, one or more audio processing components 712g (hereinafter referred to as "audio component 712g"), one or more audio amplifiers 712h (hereinafter referred to as "amplifier 712h"), and power 712i (e.g., one or more power supplies, power cables, power receptacles, batteries, induction coils, Power over Ethernet (POE) interfaces, and / or other suitable power sources). In some embodiments, the electronic device 712 optionally includes one or more other components 712j (e.g., one or more sensors, video displays, touchscreens).

[0129] The network interface 712d is configured to facilitate the transmission of data between the playback device 710a and one or more other devices of a data network such as, for example, link 103 and / or network 104 (FIG. 1B). The network interface 712d is configured to transmit and receive data corresponding to other signals (e.g., non-transitory signals) including media content (e.g., audio content, video content, text, photos), as well as digital packet data including an Internet Protocol (IP)-based source address and / or an IP-based destination address. The network interface 712d can analyze digital packet data so that the electronic device 712 can appropriately receive and process data destined for the playback device 110a.

[0130] In the embodiment shown in FIG. 7B, network interface 712d includes one or more wireless interfaces 712e (hereinafter referred to as "wireless interface 712e"). The wireless interface 712e (e.g., a suitable interface including one or more antennas) is communicatively coupled to network 104 (FIG. 1B) according to a suitable wireless communication protocol (e.g., WiFi, Bluetooth®, LTE) to one or more other devices (e.g., playback device 110, NMD 120, control device 130, other portable playback device 710, and one or more of other devices disclosed herein such as a bridge device) so as to wirelessly communicate. In some embodiments, network interface 712d optionally includes a wired interface 712f (e.g., an interface or receptacle configured to receive a network cable such as Ethernet, USB-A, USB-C, and / or Thunderbolt cable) configured to communicate with other devices via a wired connection according to a suitable wired communication protocol. In some embodiments, electronic device 712 completely excludes network interface 712d and transmits and receives media content and / or other data via another communication path (e.g., input / output 711).

[0131] The audio component 712g is configured to process and / or filter data including media content received by the electronic device 712 (e.g., via the input / output 711 and / or the network interface 712d) to generate an output audio signal. In some embodiments, the audio processing component 712g includes, for example, one or more digital-to-analog converters (DACs), audio preprocessing components, audio enhancement components, digital signal processors (DSPs), and / or other suitable audio processing components, modules, circuits, etc. In certain embodiments, one or more of the audio processing components 712g can include one or more sub-components of the processor 712a. In some embodiments, the electronic device 712 omits the audio processing component 712g. In some aspects, for example, the processor 712a executes instructions stored in the memory 712b to perform audio processing operations to generate an output audio signal.

[0132] Amplifier 712h is configured to receive and amplify an audio output signal generated by audio processing component 712g and / or processor 712a. Amplifier 7712h can comprise an electronic device and / or component configured to amplify the audio signal to a level sufficient to drive one or more of transducers 714. In some embodiments, for example, amplifier 712h includes one or more switching or class-D power amplifiers. However, in other embodiments, the amplifier includes one or more other types of power amplifiers (e.g., linear gain power amplifiers, class-A amplifiers, class-B amplifiers, class-AB amplifiers, class-C amplifiers, class-D amplifiers, class-E amplifiers, class-F amplifiers, class-G amplifiers and / or class-H amplifiers, and / or another suitable type of power amplifier). In certain embodiments, amplifier 712h includes a suitable combination of two or more of the aforementioned types of power amplifiers. Further, in some embodiments, individual ones of amplifier 712h correspond to individual ones of transducers 714. However, in other embodiments, electronic device 712 includes a single amplifier among those of amplifier 712h configured to output the amplified audio signal to a plurality of transducers 714.

[0133] The transducer 714 (e.g., one or more speakers and / or speaker drivers) receives the amplified audio signal from the amplifier 712h and renders or outputs the amplified audio signal as sound (e.g., audible sound waves having frequencies from about 20 Hertz (Hz) to 20 kilohertz (kHz)). In some embodiments, the transducer 714 can include a single transducer. However, in other embodiments, the transducer 714 includes a plurality of audio transducers. In some embodiments, the transducer 714 includes a plurality of types of transducers. For example, the transducer 714 can include one or more low-frequency transducers (e.g., subwoofers, woofers), mid-range frequency transducers (e.g., mid-range transducers, mid-woofers), and one or more high-frequency transducers (e.g., one or more tweeters).

[0134] FIG. 7C is a front isometric view of a portable playback device 710a configured according to aspects of the disclosed technology. As shown in FIG. 7C, the portable playback device 710a is implemented as headphones to facilitate more private playback compared to the loud audio playback of the playback device 110. As shown, the portable playback device 710a (also referred to as headphones 710a) includes a housing 716a for supporting a pair of transducers 714a over the user's head or around the user's ear across the user's ear.

[0135] The headset 710a also includes a user interface 713a having a touch-sensing area for facilitating playback controls such as transport and / or volume control. The touch-sensing area of the user interface 713a can support gesture control. For example, swiping forward or backward across the touch-sensing area can skip forward or backward, respectively. Other gestures can include touch-and-hold and touch-and-continue-hold that can correspond to various swap and grouping functions, as will be described in more detail below. In some implementations, the user interface 713a can include respective touch-sensing areas on the outside of each earcup.

[0136] FIG. 7D is a front isometric view of a portable playback device 710b configured according to aspects of the disclosed technology. As shown in FIG. 7D, the portable playback device 710b, similar to the headset 710a, is implemented as an earbud for facilitating more private playback compared to the loudspeaker playback of the playback device 110. As illustrated, the portable playback device 710b (also referred to as earbud 710b) includes a housing 716b for supporting a pair of transducers 714b within the user's ear. The earbud 710b also includes a user interface 713b having a touch-sensing area for facilitating playback controls such as transport and / or volume control. The earbud 9710b can be in the form of a wired, wireless, or true wireless earbud.

[0137] FIG. 7E is a front isometric view of a portable playback device 710c. Compared to the headphones 710a and earbuds 710b, the portable playback device 710c includes one or more larger transducers to facilitate the playback of loud voice audio content. A speaker grill 716a covers the transducer. Relative to the playback device 110, the portable playback device 710c can include a less powerful amplifier and / or smaller transducers to balance the battery life, audio output capabilities, and form factor (i.e., size, shape, and weight) of the portable playback device 710c. The portable playback device 710c includes a user interface 713c having a touch-sensing area to facilitate playback controls such as transport and / or volume control.

[0138] Some portable playback devices 710 are configured to be disposed on a device base 718. For illustration purposes, FIG. 7F is a front isometric view of a portable playback device 710d configured to be disposed on a device base 718a. Similar to the portable playback device 710c, compared to the headphones 710a and earbuds 710b, the portable playback device 710d includes one or more larger transducers to facilitate the playback of loud voice audio content. A speaker grill 716b covers the transducer. The portable playback device 710c includes a user interface 713d having a touch-sensing area to facilitate playback controls such as transport and / or volume control.

[0139] The device base 718a includes protrusions 719a and 719b that align with recesses 717a and 717b of the portable playback device 710c. Such protrusions and recesses can facilitate the placement of the portable playback device 710c on the device base 718a and can improve the stability of the playback device while it is disposed on the device base 718a.

[0140] In an exemplary embodiment, the portable playback device 710c is rotatable about the device base 718a to control the volume of the portable playback device 710c. For example, the portable playback device 710c may rotate relative to the device base 718a, which may generate a volume control signal to a sensor of the portable playback device 710c and / or the device base 718a. In another example, a first portion of the device base 718a is rotatable relative to a second portion of the device base 718a. Rotation of these two portions generates a volume control signal to a sensor of the device base 718a that controls the volume of the portable playback device 710c when the portable playback device 710c is placed on the device base 718a.

[0141] The device base 718a includes a device charging system. When the playback device 710c is placed on the device base 718a, the playback device 710c can draw current from the charging system to charge one or more of its batteries. In some examples, the charging system of the device base 718a includes an inductive charging circuit (e.g., a coil that induces current to a corresponding coil within the playback device 710c that wirelessly charges one or more batteries of the playback device 710c). Alternatively, the charging system of the device base 718a includes conductive terminals through which the playback device 710c can draw current from the device base 718.

[0142] In an example, the device base 718a carries an identifier that distinguishes the device base 718a from at least some other device bases (e.g., other device bases of the media playback system 100, or perhaps more generally other device bases). In some implementations, the device base 718a can passively communicate this identifier to the playback device 710c when placed on the device base 718a. For example, the charging circuit of the device base 718 can include a unique current or voltage signature (i.e., pattern) compared to other device bases. The playback device 710c can use this unique signature to identify the device base 718. Alternatively, the charging circuit can superimpose a signal on the current supplied from the device base 718a (e.g., the current from the device base 718a can include a higher frequency signal that carries the identifier of the device base 718a). In a further example, the device base 718a includes an RFID tag, a QR code (registered trademark), or other identification component that can be read by the playback device 710c when the playback device 710c is placed on the device base 718a).

[0143] In some implementations, the device bases 718 of the media playback system 100 are associated with respective zones. When a portable playback device 710 is placed on a device base, the device base joins the associated zone. Further details regarding the device bases can be found, for example, in U.S. Patent No. 9,544,701, entitled "Base Properties in a Media Playback System", which is hereby incorporated by reference in its entirety.

[0144] In some implementations, the device base 718a includes a control system. An exemplary control system of the device base 718a includes one or more processors and memory. The processor may be a clock-driven computing component that processes input data according to instructions stored in the memory. Exemplary operations include, among other examples, communicating with a playback device 710c (e.g., causing the playback device 710c to receive one or more instructions via a communication interface (e.g., a BLUETOOTH® interface) to a relevant zone) and causing a charging system to supply current to the playback device 710c.

[0145] In an exemplary embodiment, the playback device 710 may operate in one of a first mode and a second mode. Generally, the playback device 710 operates in the first mode while in physical proximity to the playback devices 110a - n of the media playback system 100 (e.g., while at home, while connected to the network 104) to facilitate interoperability with the playback devices 110a - n of the media playback system 100, and operates in the second mode while "on the move", although the playback device 710 may also be operable in the second mode while in physical proximity to the media playback system 100. The portable playback device 710 may switch modes manually (e.g., via user input to the user interface 713) or automatically (e.g., based on proximity to one or more playback devices 110a - n, based on connection to the network 104, and / or based on the location of the mobile device).

[0146] The playback device 710 may operate in a first mode while connected to a wireless local area network (e.g., network 104). Through the connection to the wireless local area network, the playback device 710 may stream audio content from one or more audio sources including local and remote (e.g., cloud) network locations. Further, in the first mode, the portable playback device 710 may interface with other devices of the media playback system 100. For example, the portable playback device 710 may form a synchronization group or other arrangement with playback devices 110a - n and / or other portable playback devices 710 in the first mode. Further, in the first mode, the portable playback device 710 may be controlled by the control device 130 in the same or a similar manner as the playback device 110.

[0147] The playback device 710 may operate in a second mode when connected to a mobile device via BLUETOOTH (802.15). In some aspects, in the second mode, the portable device operates similarly to a conventional BLUETOOTH speaker or a wearable device. That is, the playback device 710 may pair with a mobile device such as a smartphone or a tablet, and the user may play the audio output of the mobile device. Similarly, the microphone 715a of the portable playback device 710 may provide audio input to the mobile device. As described above, this mode can be used "on the go" to facilitate playback outside the range of, for example, the home network, away from the media playback system 100. Further, this mode can be used in proximity to the media playback system 100, thereby facilitating a more private use of the portable playback device 710a or providing convenient access to the content of the mobile device for playback.

[0148] FIG. 7G shows an exemplary pairing configuration between the headphones 710a and a mobile device configured as the control device 130a. As described above, the mobile device can become the control device 130 through the installation of control application software, and the control device 130a can further provide a bridging function to facilitate its operation as an interface between the headphones 710a and the media playback system 100.

[0149] The control device 130a can include a communication interface, processing capabilities, and / or other features that are not necessarily implemented in the portable playback device 710a. By "pairing" the portable playback device 710a with the control device 130a, the portable playback device 710 can utilize some of these features. This arrangement can enable, among other possible advantages, the portable playback device 710a to be smaller, more portable, consume less power, and / or be less expensive.

[0150] For example, in various embodiments, the portable playback device 710a may or may not be implemented using a communication interface (e.g., a cellular data connection) for connecting to the Internet "on the go". By pairing the portable playback device 710a with the control device 130a via a personal area connection such as Bluetooth® (IEEE802.15) or a wireless local area network connection (IEEE802.11), the portable playback device 710a can stream music through the control device 130a's Internet connection and the pairing connection. In embodiments that include a wireless local area network interface, the portable playback device 710a may directly connect to a wireless local area network (e.g., network 104 (FIG. 1B)) if available.

[0151] Similarly, in various embodiments, the portable playback device 710a may be implemented with or without using a wireless local area network interface. By pairing the portable playback device 710 with the control device 130a via a personal area connection such as Bluetooth (R) (IEEE802.15), the portable playback device 710a can stream music via the Internet connection and the pairing connection of the control device 130a. In this example, the Internet connection of the bridge device 860 may be a wireless local area network having a gateway to the Internet or via a cellular data connection.

[0152] In an exemplary embodiment, the control device 130a is coupled or default configured to a particular playback device (e.g., playback device 110c), a combined zone of playback devices (e.g., playback devices 110l and 110m) or a group of playback devices, e.g., a group of "kitchen + dining room"). Alternatively, when a home graph hierarchy is utilized, the control device 130a can be coupled to or default coupled to a particular set, room, or area. At this time, in this configuration, the control of the coupled playback device 110 via the NMD120 or the control device 130 also controls the paired portable playback device 710a.

[0153] Alternatively, the control device 130a itself may form a zone or a set. For example, in one example, the control device 130a may be configured as an "Ann's portable" zone or an "Ann's headphones" set. By configuring the control device 130a as a zone or a set, the control of the paired headphones 710a by the NMD120 and / or the control device 130 of the media playback system 100 is facilitated.

[0154] In an alternative implementation, the portable playback device 710a can interface independently as its own zone or set with the media playback system 100. Such an implementation of the portable playback device 710a can include a cellular data connection to facilitate portable streaming (i.e., streaming away from the media playback system 100 and / or the network 104). In this example, the portable playback device 710a can join the media playback system 100 as a zone or set when connected to the network 104 or when in proximity to the playback device 110.

[0155] VI. Exemplary Swap Techniques As described above, the exemplary techniques described herein relate to the transfer (or “swap”) of a playback session between the portable playback device 710 and one or more playback devices 110. During a playback session swap, the playback of the audio content stops at the “source” playback device and starts at the “target” playback device at the same or substantially the same offset within the audio content. For example, the media playback system 100 may swap playback between a “source” portable playback device 710 and one or more “target” playback devices 110. In a further example, the media playback system 100 can swap playback between one or more “source” playback devices 110 and a “target” portable playback device 710.

[0156] For example, the user can start listening to audio content via the headphones 710a or earbuds 710b while "out", and then swap the playback of the audio content to one or more playback devices 110a - n to continue listening to the audio content at a loud volume at home. In another example, the user can start listening to audio content via the headphones 710a or earbuds 710b at home (presumably so as not to disturb another person who may be at home), and then connect to one or more playback devices 110a - n to continue listening to the audio content at a loud volume. In a third example, the user can start listening to the audio content at a loud volume via the portable playback device 710c, and then swap to one or more playback devices 110a - n, which may be because the target playback device can have a greater acoustic output capacity (e.g., due to a more powerful amplifier and / or a larger transducer), can be located in another room, can be part of a synchronous group, or for any other reason.

[0157] Similarly, the user can listen to audio content via one or more playback devices 110a - n and swap the playback of the audio content to the portable playback device 710. For example, the user can be listening to TV audio in the den 101d (including playback devices 110h, 110i, 110j, and 110k), and then swap the playback to the earbuds 710b for more personal listening. As another example, the user can be listening to an Internet radio station in the kitchen 101h (including playback device 110b), and then swap the playback to the headphones 710a to continue listening while out. As a third example, the user can be listening to music in the bedroom 101c (including playback device 110g), and swap the playback to the portable playback device 710c so as to be able to get the music even outside in the yard.

[0158] A playback device in which a playback session is in progress can maintain its state or access playback session data that defines and / or identifies the playback session. The playback session data can include data representing a source of the audio content (e.g., a URI or URL indicating the location of the audio content) and an offset indicating a position within the audio content to start playback. In various ways, the offset can be defined as time from the start of the audio track (e.g., in milliseconds) or as the number of samples. In an exemplary implementation, the offset can be set to the playback position in the audio content of the current playback position to give the target device the time to start buffering the audio content. At this time, the source playback device stops playing the audio content at the offset, and the target playback device starts playing the audio content at the offset.

[0159] The playback session data can further include data representing a source of the audio content (e.g., a URI or URL indicating the location of the audio content) and an offset indicating a position within the audio content to start playback. The offset can be defined, among other examples, as time from the start of the audio track (e.g., in milliseconds) or as a number of samples.

[0160] The playback session data can further include data representing the playback state. The playback state can include the playback state of the session (e.g., playing, paused, or stopped). If the playback session implements a playback queue, the playback session data can include the playback queue state such as the current playback position within the queue.

[0161] The playback queue state can also include a queue version. For example, in an embodiment of the cloud queue, the cloud queue server and the media playback system 100 can use the queue version to maintain consistency. The queue version can be incremented each time the queue is changed to indicate the latest version of the queue and then shared between the media playback system 100 and the cloud queue server.

[0162] Furthermore, the playback session data can also include authentication data such as one or more keys and / or tokens. Such authentication data can include a token associated with the user's account. During a playback session swap, the media playback system 100 can verify that the token is permitted on both the source and target playback devices. The authentication data can further include a token associated with a streaming audio service, which can enable the target playback device to access the audio content at the source. Additionally, the authentication data can include a token associated with the playback session that enables the target playback device to access the session. Other exemplary authentication data is also contemplated.

[0163] In some implementations, the swap is triggered by an input to the playback device. This input may be referred to as a "playback session swap input". In some examples, the playback session swap input may be provided to a user interface of the playback device, such as the user interface 313 of the playback device 320 (FIG. 7D) or the user interface 713a of the headphones 710 (FIG. 7B). Alternatively, the playback session swap input may be provided to a user interface of a control device 130, such as the user interface 430 (FIGS. 4A-4D), when the user interface 430 is controlling a particular playback device (e.g., a zone or zone group).

[0164] A playback device that accepts a playback session swap input may be referred to as a "leading playback device". In an example, the leading playback device is either the source or the target of the swap. When the portable playback device 710 has an ongoing playback session (e.g., the portable playback device is actively playing audio content or has an active but paused playback session) and receives a playback session swap input, the portable playback device 710 can assume that the user wants to "push (hand over and release)" the playback session to a nearby playback device 110. Thus, the portable playback device 710 is identified as the source (handover origin) of the swap, and the nearby playback device 110 is identified as the target (handover destination).

[0165] To explain, FIG. 8A is a schematic diagram showing an exemplary push swap between the headphones 710a (FIG. 7C) and the playback device 110b in the kitchen 110h zone (FIG. 7A). As shown in FIG. 8A, in the initial state, the headphones 710a are continuously running a playback session. At this time, the user gives a playback session swap gesture to the headphones 710a. The playback session of the headphones 710a is pushed (handed over and released) to the playback device 110b. After the push, the kitchen 110h zone receives information regarding the playback session and continues to cause the playback device 110b to execute the playback of the playback session.

[0166] Conversely, when the portable playback device 710 is not executing a playback session and receives a playback session swap input, the portable playback device 710 determines that the user wants to "pull (take over)" the playback session from a nearby playback device 110. Here, the portable playback device 710 is identified as the swap target (takeover destination), and the nearby playback device 110 is identified as the source (takeover origin). To explain, FIG. 8B is a schematic diagram showing an exemplary pull swap between the headphones 710a (FIG. 7C) and the playback device 110b in the kitchen 110h zone (FIG. 7A). As shown in FIG. 8B, in the initial state, the playback device 110b is continuously executing a playback session. At this time, the user gives a playback session swap gesture to the headphones 710a. Then, the playback session of the playback device 110b is pushed (released for takeover) to the headphones 710a. After the push, the headphones 710a start the playback session.

[0167] If both the portable playback device 710 and a nearby playback device 110 have an ongoing playback session, it may be unclear whether the user wants to push (transfer and release) the playback session of the portable playback device 710 to the nearby playback device 110 or pull (transfer and import) the playback session of the nearby playback device 110 to the portable playback device 710. In some implementations, the portable playback device 710 can determine that the user wants to "push (transfer and release)" the playback session to the nearby playback device 110. To explain, FIG. 8C is a schematic diagram showing an exemplary push swap between the headphones 710a (FIG. 7C) and the playback device 110b in the kitchen 110h zone (FIG. 7A). As shown in FIG. 8C, in the initial state, both the headphones 710a and the playback device 110b are continuing the playback session. At this time, the user gives a playback session swap gesture to the headphones 710a. Then, the playback session of the headphones 710a is pushed (transferred and released) to the playback device 110b. After the push, the playback device 110b in the kitchen 110h zone takes over the playback session being executed on the headphones 710a. Conversely, if the user wants to "pull (transfer and import)" the playback session of the nearby playback device 110, the user can first stop the playback session of the portable playback device 710 and then give a playback session swap to the portable playback device 710 side. In another embodiment, the portable playback device 710 may be configured to perform the exact opposite operation.

[0168] In the example of FIGS. 8A-8C, the leading device is the headset 710a. In other examples, the user can perform a playback session swap input on any of the playback devices 110, such as the playback device 110b. Even in this scenario, a similar determination can be applied when specifying the source (transfer origin) and target (transfer destination) of the swap. In particular, when the playback device 110b is executing a playback session and receives a playback session swap input, the playback device 110b can determine that the user wants to "push (release transfer)" the playback session to a nearby portable playback device 710. Conversely, when the playback device 110b is not continuing the playback session and receives a playback session swap input, the playback device 110b determines that the user wants to "pull (transfer in)" the playback session from a nearby portable playback device 710.

[0169] In an example, the leading playback device that initiates the swap can cause another playback device in the vicinity of the leading playback device to be identified as the swap target. That is, the leading playback device can identify one or more nearby playback devices as the target of a push swap from the leading playback device or as the source of a pull swap to the leading playback device. After receiving or based on a playback session swap input, the leading playback device can automatically identify such nearby playback devices (i.e., without necessarily receiving further user input from the playback session swap input).

[0170] Some exemplary techniques for identifying nearby playback devices include audio-based identification. In an exemplary audio-based identification technique, the leading playback device requests that a playback device eligible for the swap emit an identifiable sound (such as an audio chirp), and this sound is detected by one or more microphones provided in the leading playback device. Thereafter, the leading playback device identifies the nearby playback device based on the characteristics of the detected sound.

[0171] To explain, FIG. 9 is a schematic diagram showing an audio-based identification technique using an audio chirp. The audio chirp includes acoustic characteristics (e.g., one or more tones) that enable the identification of the playback device that transmits the audio chirp. In FIG. 9, the user starts a swap with the portable playback device 710 (here, the headphones 710a). As described above, when the playback session is in progress on the headphones 710a, the headphones 710a assume that the user wants to push the playback session to one or more nearby playback devices. Or, the headphones 710a assume that the user wants to pull the playback session from one or more nearby playback devices to the headphones 710a.

[0172] After receiving or based on receiving a playback session swap input, the headphones 710a may identify a playback device eligible for the swap within the media playback system 100. In the case of a push swap, the set of playback devices eligible for the swap includes playback devices of a specific type or assigned a specific role within the media playback system 100. Other portable playback devices may be considered ineligible for the swap. As another example, only the master within a combined zone (e.g., a stereo pair or a surround sound configuration) may be considered eligible for the swap. In the case of a pull swap, the set of playback devices eligible for the swap includes playback devices having an ongoing playback session. This set can be further narrowed based on other factors as described above.

[0173] As described above in Section II, the playback device 110 in the media playback system 100 can maintain or access the state variables of the playback device, and the same applies to other configuration information. This state information is updated on an event basis (e.g., when the status changes), either periodically or via subscriptions to specific types of events or statuses (e.g., playback events, grouping events, topology change events, player volume events, group volume events, playback metadata events) and notifications of specific events. The protocol used for subscriptions may be uPnP-based or a proprietary controller protocol or API. The portable playback device 710 including the headphones 710a and earbuds 719b can similarly maintain or access these state variables and determine a set of playback devices eligible for swap based on the information within the state variables. The state variables may be received from another playback device of the media playback system and / or from state information stored in a remote computing system within the cloud. In the example of FIG. 9, the headphones 710a identify the playback device 110b, the playback device 110g, and the playback device 100g as playback devices eligible for swap.

[0174] After identifying a plurality of playback devices eligible for swap, the headphones 710a cause each of the plurality of playback devices eligible for swap to emit its respective audio chirp as the leading playback device within the swap. For example, the headphones 710a may send commands to the playback device 110b, the playback device 110g, and the playback device 100g to cause these plurality of playback devices eligible for swap to emit unique audio chirps. In some examples, the audio chirps may be ultrasonic (e.g., above 20 kHz) or near-ultrasonic (e.g., 19 - 20 kHz) in order to avoid the propagation of the audio chirps from reaching outside the vicinity of the emitting playback device and / or to avoid discomfort to the user.

[0175] Each audio chirp can include data in the form of an encoding identifier. Each encoding identifier may be different and may be encoded as a set of tones recognized by the lead playback device. Audio chirps from a plurality of playback devices eligible for swap can be transmitted immediately, simultaneously, sequentially, or when a particular playback device receives an instruction to transmit an audio chirp. In some examples, a device of a media playback system can provide timing information regarding when to transmit an audio chirp for each of the playback devices.

[0176] After instructing a plurality of playback devices eligible for swap to emit an audio chirp, the lead playback device for swap attempts to detect the emitted audio chirp via one or more microphones (e.g., microphone 715). For example, headphones 710a may attempt to detect an emitted audio chirp via one or more voice microphones within the housing of headphones 710a. Alternatively, headphones 710a may attempt to detect an emitted audio chirp via one or more ANC microphones within the housing of headphones 710a. In some cases, a particular microphone (ANC or voice) may be selected or adjusted to be sensitive to ultrasonic or near-ultrasonic ranges such that these microphones are particularly suitable for receiving audio chirps. Other examples are similarly possible.

[0177] To identify a "nearby" playback device, the leading playback device can compare detected audio chirps. For example, headphones 710a can compare various measurement criteria such as the sound pressure and signal-to-noise ratio of the detected audio chirps to identify the "loudest" audio chirp that can be assumed to be emitted by the playback device physically closest to the leading playback device. In an exemplary embodiment, the leading playback device can list or rank playback devices eligible for swapping by relative signal strength (e.g., SNR), and then select the highest-ranked playback device eligible for swapping as the source or target of the swap.

[0178] As shown in FIG. 9, headphones 710a detect audio chirps from each of playback devices 110n and 110g in bathroom 101a and bedroom 101c, respectively. However, headphones 710a did not detect an audio chirp from playback device 110b. This is probably because the audio chirp from kitchen 101h, which is on a different floor of the house than the other zones, could not propagate to headphones 710a. In this example, by comparing the metrics of the audio chirp emitted by playback device 110n and the audio chirp emitted by playback device 110g, it was determined that the audio chirp emitted by playback device 110n was the "loudest", and thus playback device 110n was determined to be the closest playback device.

[0179] To facilitate comparison between detected audio chirps, a plurality of playback devices eligible for swapping can emit audio chirps at the same or substantially the same volume level. In some cases, the command to emit an audio chirp includes a command to change to a specific volume level. Since different playback devices have different types of transducers and / or amplifiers, the volume level of each playback device that emits a chirp can vary based on the type of device. Alternatively, the playback device may be preconfigured to emit an audio chirp at a specific volume level.

[0180] The playback session swap input can take various forms. For example, a specific input to the user interface 713a of the headphones 710 (FIG. 7B), such as a tap or gesture to a touch-sensing area (or a part thereof), may trigger the swap. In a further example, the portable playback device 710 may include a physical button to trigger the swap. Still further, a pattern of touch inputs (e.g., short, long, short) or a tracking pattern (e.g., a shape such as a zigzag or a triangle) can trigger the swap. Other types of inputs are also conceivable.

[0181] In some specific examples, a touch-and-hold (long touch) or a continuous touch-and-hold on a specific area of the touch-sensing area (e.g., the play / pause area) triggers the swap. To explain, FIG. 10 is a chart showing exemplary control schemes for the portable playback device 710c, the playback device 110, and the headphones 710a. As shown in FIG. 10, the user can provide a pressing input (also known as a touch) to the touch-sensing area to perform a primary operation (i.e., play or pause). If a physical button is available for swapping, the user can keep pressing the physical button to invoke the swap.

[0182] For example, if the user continues to hold a press input (touch and hold, long touch), a secondary operation is executed. In the case of the portable playback device 710c and the playback device 110, the secondary operation instructs to group with nearby playback devices. That is, in the case of the leading playback device (i.e., the portable playback device 710c or the playback device 110), a synchronization group is formed with nearby playback devices. Separately, in the case of the headphones 710a, the secondary operation is to execute a push swap or a pull swap as described in relation to FIGS. 8A - 8C. With this configuration, when the user uses the headphones 710a, they can access the swap function more quickly. Since the wearable playback device is designed to listen relatively privately compared to the portable playback device 710c and the playback device 110, the user is less likely to want to group the headphones for synchronous playback with these types of devices. Other exemplary implementations may change this control method.

[0183] If the user continues to hold the press input further (touch - and - continued - hold, continued hold of a long touch while touching), a tertiary operation is executed. In the case of the portable playback device 710c and the playback device 110, the tertiary operation is to execute a push swap or a pull swap with nearby playback devices. For the headphones 710a, the tertiary operation is not configured. Other exemplary control methods may configure the tertiary operation for the headphones 710a. In some examples, holding the touch after the last action in the chain can cancel the input.

[0184] For the user, this control scheme provides audible feedback for the swap operation. When the user provides a playback session swap input to the first playback device, the user is confident that the first playback device is the source or target of the swap (depending on whether the first playback device has an ongoing playback session) when the trigger input is provided to the first playback device. However, the user may have less confidence that the leading playback device accurately identifies the user's desired target (in the case of a push swap) or source (in the case of a pull swap). In particular, when using the exemplary audio-based identification techniques described above, the leading playback device may identify a playback device different from what the user intended as the source or target due to the inherent acoustic characteristics of the environment that cause the audio chirp emitted from a more distant playback device to appear closest.

[0185] By using this control method, when a push-and-hold input is applied to the portable playback device 710c or the playback device 110 (in the case of a long press that the user continues to hold), as a possibility, a grouping may occur between the source side and the target side as a result of the swap, causing synchronized loud audio playback between the source side and the target side after the swap. In particular, when the leading playback device has an ongoing playback session, a push group is executed, whereby the leading playback device and nearby playback devices play the ongoing playback session synchronously. Conversely, when the leading playback device does not have an ongoing playback session, a pull group is executed, whereby the leading playback device and nearby playback devices play the ongoing playback session of the nearby playback device synchronously. This synchronized playback of the loud audio provides the user with a preview for the source side and the target side of the swap that occurs when the user continues to hold the input. If the "previewed" playback devices within the group are different from the user's desired swap source or target, the user can cancel the group or provide an input to cancel the swap action.

[0186] Furthermore, in some implementations, the control scheme can facilitate a user to select a desired source or target for the swap by taking additional inputs. In particular, in some examples, by performing one or more additional press-and-hold inputs (long presses) within a threshold period before the next input, the user can sequentially cycle through multiple playback devices eligible for the swap. As described above, the leading playback device can list multiple playback devices eligible for the swap by signal strength. In an example, a second press-and-hold input (long press) following the first press-and-hold input (long press) selects the second playback device eligible for the swap in the list. Similarly, a third press-and-hold input (long press) following the first press-and-hold input (long press) selects the third playback device eligible for the swap in the list. Subsequent inputs continue to cycle through the list (if there are more playback devices eligible for the swap listed).

[0187] In some examples, the portable playback device 710c can similarly traverse (reject) a list of group-eligible playback devices via consecutive touch-and-hold inputs. The group-eligible playback devices may be the same as the playback devices eligible for the swap or may be identified using the same or similar audio-based identification techniques. For example, to push / pull a group with the nearest playback device 110, the user may perform a first touch-and-hold input on the playback device 710c. To push / pull a group with the next nearest playback device 110, the user may provide a second touch-and-hold input to the playback device 710c within a threshold time from the first input. Subsequent touch-and-hold inputs can further traverse (reject) the ranked list of swap and / or group-eligible playback devices in ranked order from the nearest to the farthest. After the threshold period, the user needs to start the input sequence again to perform the grouping.

[0188] If a push-swap gesture is performed on the portable playback device 710c while the portable playback device 710c is already grouped with the nearest playback device 110, instead of performing a push-swap, the portable playback device 710c may be configured to instead perform a push-ungrouping.

[0189] To assist the user in understanding the control scheme, the source and / or target playback device can provide feedback, including audio and / or visual feedback. To illustrate, FIGS. 11 and 10 are charts showing exemplary feedback schemes for the portable playback device 710c and the playback device 110. As shown in FIG. 11, at each stage of the control scheme, for each operation, in this example the source leading playback device (portable playback device 710c) provides audio and / or visual feedback. Further, when performing group and swap operations, the target playback device also provides audio and / or visual feedback. For example, when grouping the portable playback device 710c and the playback device 110, each playback device provides its respective tone feedback (shown as two different tones, "Marco" and "Polo" in FIG. 11), and the source playback device provides visual feedback. When swapping the portable playback device 710c and the playback device 110, each playback device provides tone and visual feedback, or only the portable playback device 710c provides tone and visual feedback.

[0190] After identifying the source or target playback device for pull or push swap respectively, the leading playback device transfers the playback session from the source playback device to the target playback device. In an exemplary embodiment, the swap includes forming a synchronization group that includes the source playback device and the target playback device. Exemplary synchronization grouping is described in more detail in Sections III and IV above. When forming the synchronization group, the target playback device starts playing the audio content in synchronization with the source playback device. The source playback device may then be removed from the synchronization group that completes the swap. The source playback device can be removed or ungrouped from the synchronization group by sending a command to the target device to ungroup from the source playback device.

[0191] In another exemplary embodiment, in a pull swap, the target device can send a request for playback session information to the source playback device. The playback session information includes playback state information such as the current playlist, track, offset, etc. In yet another exemplary implementation, in a push swap, the leading device can send a command to start playback, playback state information, etc. The target playback device can use the playback state information to continue playing the playback session without grouping and ungrouping with the source playback device.

[0192] Referring again to the example of FIG. 8A, to push the playback session from the headphones 710a to the playback device 110b, the headphones 710a form a synchronization group that includes the headphones 710a and the playback device 110b, thereby synchronously playing the playback session on the headphones 710a and the playback device 110b. To end the push swap, the headphones 710a leave the synchronization group.

[0193] In the example of FIG. 8A, since the playback session starts with the headphones 710a, the headphones 710a may initially operate as the source device of the synchronization group. As described above, the source device or group coordinator obtains the audio of the synchronization group. After the headphones 710a leave the synchronization group, the playback device 110b may assume the role of the source device.

[0194] In some examples, to avoid the user being confused by the audio playback during the swap, the playback may be controlled by the source or target playback device. For example, the playback session may be paused simultaneously with the generation of the synchronization group and then resumed after the headphones 710a leave the synchronization group. In other examples, either the headphones 710a or the playback device 110b, or both, may be muted until the swap is completed. In yet another example, the headphones 710a may continue to play for x seconds (e.g., 1, 2, 3 seconds, etc.) before pausing to allow for any delay when transferring the playback session to the target playback device. Other examples are possible as well.

[0195] Referring again to the example of FIG. 8B, to pull the playback session from the playback device 110b to the headphones 710a, the headphones 710a form a synchronization group including the headphones 710a and the playback device 110b, thereby synchronizing and playing the playback session on the headphones 710a and the playback device 110b. To end the push swap, the playback device 110b leaves the synchronization group.

[0196] In the example of FIG. 8B, since the playback session starts with the playback device 110b, the playback device 110b may initially operate as the source device of the synchronization group. As described above, the source device or group coordinator obtains the audio of the synchronization group. After the playback device 110b leaves the synchronization group, the headphones 710a may assume the role of the source device.

[0197] In an alternative embodiment, instead of leaving the synchronization group to complete the swap, the source playback device remains in the synchronization group as the source device. As a result, typically, the source playback device and the target playback device play the content synchronously, but in these examples, the source playback device is placed in a muted state. Since the source playback device is muted, the playback session appears to the user as if it has been swapped. This may be a true mute that disables or places in a low-power state certain components such as an audio amplifier, reducing power consumption compared to loud audio playback when not in the muted state.

[0198] VII. Exemplary Home Theater Swap Techniques In some examples, the user may wish to migrate the playback session from a soundbar-type playback device to a wearable playback device to enable more private listening of audio from a television or other home theater source. Exemplary soundbar-type playback devices include playback device 110h (FIGS. 1K and 1J). The soundbar-type playback device can receive audio from a television, a media player (e.g., a set-top box, a streaming media playback device, a computer), or other home theater sources via an audio input interface. Further, the soundbar-type playback device can operate as a source device for a combined zone that includes one or more satellites that can play a specific channel (e.g., playback devices 110j and 110k) and / or a specific frequency range (e.g., playback device 110i), as shown in FIGS. 1K and 1J showing den 101d. The soundbar playback device implements a bar-shaped housing and linearly arranges a plurality of audio drivers along the front, but the soundbar-type playback device does not necessarily have to have a bar-shaped housing.

[0199] An exemplary soundbar playback device can be considered to operate in one of two modes for receiving audio content, referred to herein as a home theater mode and a music mode. In the home theater mode, the soundbar-type playback device receives audio from a source (e.g., a TV) physically connected via an audio input interface. When streaming audio via a network interface, the soundbar-type playback device can be considered to be in the music mode. Note that the streaming audio does not necessarily have to be music, and can be, for example, other types of streaming audio content such as podcasts or news programs. When streaming audio content in the music mode, the soundbar-type playback device can perform a swap in the same or a similar manner as described in Section VI.

[0200] While in the home theater mode, to perform a swap, the soundbar-type playback device can enter another mode referred to herein as the "home theater swap mode" or simply the "swap mode". When using the swap mode to perform a swap operation with a wearable playback device, the wearable playback device effectively becomes a satellite of the soundbar-type playback device. In the swap mode, the soundbar-type playback device functions as a source device and, in this case, plays the audio from the audio input interface as if operating in the home theater mode. The wearable playback device then functions as a target playback device for receiving and playing the audio from the audio input interface. Conversely, if the wearable playback device is already playing the audio from the audio input interface in the swap mode, the soundbar-type playback device functions as the target playback device.

[0201] In some cases, the wearable playback device initiates the swap mode. FIG. 12A is an exemplary message flow diagram showing commands exchanged between the headphones 710a, the sound bar type playback device 110h, one or more satellite satellites (den 101d) within a combined zone including the sound bar type playback device 110h (shown as playback devices 110j, 110k, and 110i as shown in FIG. 1K), and one or more group members in an exemplary swap mode initiated by the headphones 710a (if the combined zone is within a zone group including any additional zones).

[0202] Before entering the swap mode, at 1281a, the sound bar type playback device 110h is playing audio from an audio input interface in the home theater mode. The sound bar type playback device 110h distributes audio to the satellites according to its role in the combined zone in the home theater mode as the source device of the combined zone including the satellites. Also, when the den 101d belongs to a zone group having one or more other zones, the sound bar type playback device 110h distributes full-range audio content to the group members of the zone group as the source device of the zone group.

[0203] At 1282b, the headphones 710a receive a playback session swap input, which can be, among other examples described in relation to Section VI, a touch-and-hold input. In this example, the headphones then identify the sound bar type playback device 110h as the source of the swap (e.g., based on determining that the sound bar type playback device 110h is the playback device that is physically closest using, for example, audio-based identification techniques).

[0204] Next, in 1283a, the headphones 710a transmit data representing an instruction to shift to the swap mode, received by the sound bar type playback device 110h, to the sound bar type playback device 110h. The headphones 710a and the sound bar type playback device 110h can transmit and receive data representing the instruction via their respective 802.11 compliant network interfaces. The headphones 710a may transmit this data based on receiving a playback session swap input.

[0205] Based on receiving data representing an instruction to enter the swap mode, the sound bar type playback device 110h shifts from the home theater mode to the swap mode. More specifically, in 1284a, the sound bar type playback device 110h adds the headphones 710a to the combined zone. This can be the same combined zone as the den 101d or a new combined zone.

[0206] In some examples, in the home theater mode, the sound bar type playback device 110h and the satellites operate as nodes within a mesh network. As described above in connection with FIG. 1B, in some implementations, the network 104 can include a dedicated communication network implemented as a mesh network. In the home theater mode, the sound bar type playback device 110h distributes playback timing information and audio to the satellites using the mesh network.

[0207] To facilitate adding the headphones 710a to the combined zone, the sound bar type playback device 110h shifts its 802.11 compliant network interface from operating as a node in a mesh network to operating as an access point. The access point forms a first wireless local area network (LAN) in a first radio frequency band (e.g., 5 GHz band). At that time, the sound bar type playback device 110h transmits data representing the service set identifier (SSID) of the first wireless LAN and a certificate for the first wireless LAN to the first wearable playback device via the 802.11 compliant network interface, thereby enabling the headphones 710a to connect to the first wireless LAN. After the first wearable playback device connects to the first wireless LAN formed by the sound bar type playback device, the sound bar type playback device 110h forms a combined zone including the sound bar type playback device 110h and the headphones 710a. This may be considered the same combined zone as the cabinet 101d or a new combined zone. In 1285a, after connecting to the first wireless LAN, the headphones 710a transmit a message to the sound bar type playback device 110h to start streaming an HT audio stream.

[0208] Furthermore, in some examples, while in swap mode, the headphones 710b effectively become satellites of the soundbar-type playback device 110h. In this way, since the satellite playback devices 110j, 110k, and 110i are not playing audio, the soundbar-type playback device 110h "parks" the satellite playback devices 110j, 110k, and 110i on a second wireless local area network in a second radio frequency band (e.g., the 2.4 Ghz band). By parking the satellites on the second LAN, the satellites remain communicable (e.g., to ultimately reform the combined zone when transitioning back to, for example, the home theater mode) and can receive updates (e.g., state variable events) regarding the state of the media playback system 100. The soundbar-type playback device 110h can configure this second wireless LAN using its 802.11 compliant network interface.

[0209] In 1286a, the soundbar-type playback device 110h stops streaming the HT audio stream to the satellites (e.g., 110j, 110k, and 110i). This may be performed as part of or in relation to parking the satellite playback devices 110j, 110k, and 110i on the second wireless LAN. Similarly, in 1287a, the soundbar-type playback device 110h can stop streaming the HT audio stream to the group members, if any. By forming a new combined zone in 1284a, the soundbar-type playback device 110h can be removed from any existing zone group, thereby stopping the group members from receiving the HT audio stream.

[0210] In 1288a, the soundbar type playback device 110h streams an HT audio stream to the headphones 710a for playback. In connection with the headphones 710a receiving the stream and playing the audio, the soundbar type playback device 110h mutes to complete the swap. When muted, the soundbar type playback device 110h can continue to process the audio data for playback in synchronization with the headphones 710a. The HT audio stream may include data representing the combined zone and playback timing information for the audio. In some examples, the audio is multi-channel audio such as a surround sound track. In such examples, the soundbar type playback device 110h can downmix the surround sound audio track to an audio track having fewer channels such as a stereo audio track. The surround sound audio track can be downmixed to include the same number of channels as supported by a wearable device or a portable playback device.

[0211] During the swap mode, the soundbar type playback device 110h can detect an event representing a trigger to transition from operation in the swap mode to operation in the home theater mode. Such an event may include receiving data from the headphones 710a representing a command to transition to the home theater mode (e.g., to end the swap mode), which the headphones 710a may send while in the swap mode after receiving a playback session swap input. As another example, the soundbar type playback device 110h can detect that the headphones 710a have been disconnected from the first wireless LAN (no longer operating as a satellite) or have been paused for x amount of time. Based on the detection of an event or the like, the soundbar type playback device 110h can transition to the home theater mode.

[0212] Transitioning from the swap mode to the home theater mode may include the sound bar type playback device 110h transitioning its 802.11 compliant network interface from operating as an access point to operating as a node of a mesh network. Also, the sound bar type playback device 110h may connect a satellite playback device to the mesh network. Additionally, the sound bar type playback device 110h can reform a combined zone including the sound bar type playback device 110h and the satellite playback devices 110j, 110k, and 110i.

[0213] Furthermore, while in the swap mode, additional wearable playback devices can be connected to the sound bar type playback device 110h as satellites. Thereby, for example, two partners can listen to TV audio using individual wearable devices in the den 101h without waking up a child sleeping in an adjacent bedroom 101c. The user can cause a second wearable playback device (e.g., earbud 710b) to join the swap mode by providing a playback session swap input (e.g., touch and hold) to the second wearable device, thereby causing the second wearable playback device to send data representing an instruction to transition to the swap mode to the sound bar type playback device 110h. Next, the sound bar type playback device 110h joins the second wearable device using the technique shown in FIG. 12A.

[0214] In some cases, the control device initiates the swap mode. FIG. 12B is an exemplary message flow diagram showing commands exchanged between the control device 130a, the headphones 710a, the sound bar type playback device 110h, and one or more satellites of a combined zone (den 101d) of the sound bar type playback device 110h in an exemplary swap mode initiated by the control device 130a.

[0215] Before entering the swap mode, at 1281b, the sound bar type playback device 110h is playing audio from the audio input interface in the home theater mode. The sound bar type playback device 110h is the master device that distributes audio to the satellite according to its role in the combined zone in the home theater mode, as the source device of the combined zone including the satellite. Also, when the den 101d belongs to a zone group having one or more other zones, the sound bar type playback device 110h distributes full-range audio content to the group members of the zone group as the source device of the zone group.

[0216] At 1282b, the control device 130a receives a playback session swap input. The control device 130 may receive the playback session swap input via a user interface such as the user interface 430. More specifically, a specific user interface 430 may control the headphones 430a and may include one or more controls corresponding to the playback session swap input when selected.

[0217] Next, at 1283b, the control device 130a sends a swap command to the headphones, and the headphones send a command to the sound bar type playback device to shift to the swap mode. Alternatively, the control device 130a sends data representing a command to shift to the swap mode to the sound bar type playback device 110h, which is received by the sound bar type playback device 110h. The control device 130a and the sound bar type playback device 110h can transmit and receive data representing commands via their respective 802.11 compliant network interfaces. The control device 130a may send this data based on the reception of the playback session swap input.

[0218] Based on receiving data representing an instruction to enter the swap mode, the sound bar type playback device 110h transitions from the home theater mode to the swap mode. More specifically, in 1284b, the sound bar type playback device 110h adds the headphones 710a to a coupling zone that may be the same coupling zone as the den 101d (e.g., "den") or a new coupling zone (e.g., identified as "den + ben's headphones").

[0219] Similar to the example of FIG. 12A, in some examples, in the home theater mode, the sound bar type playback device 110h and the satellite operate as nodes of a mesh network. To facilitate adding the headphones 710a to the coupling zone, the sound bar type playback device 110h transitions its 802.11 compliant network interface from operating as a node in the mesh network to operating as an access point. The access point forms a first wireless local area network (LAN) in a first radio frequency band (e.g., 5Ghz band). At that time, the sound bar type playback device 110h transmits data representing the service set identifier (SSID) of the first wireless LAN and the (ii) certificate for the first wireless LAN to the first wearable playback device via the 802.11 compliant network interface, thereby enabling the headphones 710a to connect to the first wireless LAN.

[0220] After the first wearable playback device connects to the first wireless LAN formed by the soundbar-type playback device, the soundbar-type playback device 110h forms a combined zone including the soundbar-type playback device 110h and the headphones 710a. This may be considered the same combined zone as the zone 101d, or it may be considered a new combined zone. At 1285b, after connecting to the first wireless LAN, the headphones 710a send a message to the soundbar-type playback device 110h to start streaming the HT audio stream. At 1286c, the control device receives data indicating that the headphones 710a are ready to receive audio from the soundbar-type playback device 110h.

[0221] Furthermore, in some examples, while in the swap mode, the headphones 710b effectively become satellites of the soundbar-type playback device 110h. Thus, since the headphones 710b are using the first wireless LAN of the first wireless band, the soundbar-type playback device 110h "parks" the satellite playback devices 110j, 110k, and 110i on the second wireless LAN of the second radio frequency band (e.g., 2.4 GHz band). By parking the satellites on the second LAN, the satellites remain communicable (e.g., to eventually reform the combined zone when transitioning back to the home theater mode) and can receive updates regarding the state of the media playback system 100 (e.g., state variable events). The soundbar-type playback device 110h may configure this second wireless LAN using its 802.11 compliant network interface.

[0222] At 1287b, the soundbar-type playback device 110h stops streaming the HT audio stream to the satellites. This may be performed as part of or in relation to parking the satellite playback devices 110j, 110k, and 110i on the second wireless LAN.

[0223] In 1288b, the soundbar-type playback device 110h streams an HT audio stream to the headphones 710a for playback. In connection with the headphones 710a receiving the stream and playing the audio, the soundbar-type playback device 110h mutes to complete the swap. The HT audio stream may include data representing playback timing information for the combined zone and the audio. In some examples, the audio is multi-channel audio such as a surround sound track. In such examples, the soundbar-type playback device 110h can downmix the surround sound audio track to an audio track having fewer channels such as a stereo audio track.

[0224] VIII. Exemplary Swap Method The methods 1300A, 1300B, 1400, and 1500 shown in FIGS. 13A, 13B, 14, and 15 present exemplary swap techniques according to the exemplary embodiments described herein. These exemplary techniques can be implemented within an operating environment that includes, for example, the media playback system 100 of FIG. 7A, one or more of the playback devices 110a - n, one or more of the NMDs 130, one or more of the control devices 130, one or more of the portable playback devices 710, and other devices and / or other suitable devices described herein. Further, the operations exemplified as being performed by the media playback system can be performed by any suitable device, such as a playback device or a control device of the media playback system. The methods 1300A, 1300B, 1400, and 1500 can include one or more operations, functions, or actions as represented by one or more of the blocks shown in FIGS. 13A, 13B, 14, and 15. Although the blocks are shown in a sequential order, these blocks may also be executed in parallel and / or in an order different from the order described herein. Also, various blocks may be combined into fewer blocks, divided into additional blocks, and / or removed based on the desired implementation.

[0225] Furthermore, for the embodiments disclosed herein, the flowchart shows the functions and operations of one possible embodiment of this embodiment. In this regard, each block can represent a module, segment, or part of program code that includes one or more instructions executable by a processor to perform a specific logical function or step in the process. The program code can be stored in any type of computer-readable medium, such as a storage device including a disk or hard drive. The computer-readable medium can include non-transitory computer-readable media such as computer-readable media for storing short-term data such as register memory, processor cache, and random access memory (RAM). The computer-readable medium can also include non-transitory media such as secondary or persistent long-term storage devices such as read-only memory (ROM), optical or magnetic disks, and compact disc read-only memory (CD-ROM). The computer-readable medium can also be any other volatile or non-volatile memory system. The computer-readable medium can be considered, for example, a computer-readable storage medium or a tangible storage device. Additionally, in the embodiments disclosed herein, each block can represent a circuit wired to perform a specific logical function in the process.

[0226] a. Exemplary method of pulling a swap Method 1300A shows an exemplary pull-swap technique. A portable playback device, such as headphones 710a, earbuds 710b, or portable playback device 710c, can execute the pull-swap technique to pull audio content in the playback session of playback device 110 to the portable playback device.

[0227] In block 1302A, method 1300A includes receiving a playback session swap input. For example, portable playback device 710 may receive data representing a first playback session swap input. As described in connection with Section VI, when portable playback device 710 is not currently playing audio content, the playback session swap input can initiate a pull swap between portable playback device 710 and one or more source playback devices. In some examples, portable playback device 710 receives the playback session swap input via a user interface. For example, as described in connection with FIG. 10, headphones 710a may receive a touch-and-hold input. Alternatively, portable playback device 710c may receive a continuous touch-and-hold input. In further examples, a control device can receive the playback session swap input and instruct a particular wearable or portable playback device to initiate a playback session swap.

[0228] In block 1304A, method 1300A includes identifying one or more source playback devices within a media playback system. For example, portable playback device 710 may identify one or more eligible playback devices 110 as source playback devices. Eligible source playback devices for a pull swap include playback devices 110 that are connected to a first wireless LAN (e.g., network 104 of FIG. 1B) and that play audio content in a playback session. As described in Section VI, the set of eligible source playback devices may be filtered using various other factors such as the type or role of the playback device.

[0229] In some examples, the portable playback device 710 identifies one or more source playback devices via audio-based identification techniques as described in Section VI. In such examples, identifying one or more source playback devices can include identifying a set of playback devices eligible for swap within the media playback system and then transmitting, to the set of playback devices eligible for swap, respective audio chirps that identify the playback devices eligible for transmission. The portable playback device 710 can then detect, via one or more microphones, the audio chirps emitted by one or more playback devices eligible for swap and select, from among the one or more playback devices eligible for swap, one or more source playback devices based on the audio chirps from the one or more source playback devices indicating that the one or more source playback devices are physically closest to the portable playback device 710 among the one or more playback devices eligible for swap. Selecting one or more source playback devices can include comparing one or more respective metrics of the detected audio chirps emitted and detected by one or more playback devices eligible for swap to determine that the one or more source playback devices are physically closest to the portable playback device 710 among the one or more playback devices eligible for swap.

[0230] In block 1306A, method 1300A includes swapping a playback session from a source playback device to a portable playback device. For example, the portable playback device 710 can transfer the playback session from the determined one or more source playback devices to the portable playback device 710. Transferring the playback session can include forming a first synchronization group that includes the portable playback device 710 and the one or more source playback devices. By forming the first synchronization group, the portable playback device 710 begins playback of a particular audio content of the playback session.

[0231] Transferring a playback session can further include stopping the playback of specific audio content on one or more source playback devices. In some examples, the playback of specific audio content on one or more source playback devices is stopped by one or more source playback devices leaving the first synchronization group. Alternatively, the playback of specific audio content on one or more source playback devices is stopped by muting one or more source playback devices. Other examples are possible as well.

[0232] b. Exemplary Method of Pushing a Swap Method 1300B illustrates an exemplary push swap technique. A portable playback device, such as headphones 710a, earbuds 710b, or a portable playback device 710c, may execute a push swap technique to push audio content in the playback session of the portable playback device to a nearby playback device 110.

[0233] In block 1302B, method 1300B includes receiving a playback session swap input. For example, portable playback device 710 may receive data representing a first playback session swap input. As described in connection with Section VI, if portable playback device 710 is currently playing audio content, the playback session swap input can initiate a push swap between portable playback device 710 and one or more target playback devices. In some examples, portable playback device 710 receives the playback session swap input via a user interface. For example, as described in connection with FIG. 10, headphones 710a may receive a touch-and-hold input. Alternatively, portable playback device 710c may receive a continuous touch-and-hold input. In further examples, a control device can receive the playback session swap input and instruct a particular wearable or portable playback device to initiate a playback session swap.

[0234] In block 1304B, method 1300B includes identifying one or more source playback devices within a media playback system. For example, portable playback device 710 may identify one or more eligible playback devices 110 as target playback devices. Eligible target playback devices for a pull swap include playback devices 110 that are connected to a first wireless local area network (e.g., network 104 of FIG. 1B) and that also play audio content in a playback session. As described in Section VI, the set of eligible target playback devices may be filtered using various other factors such as the type or role of the playback device.

[0235] In some examples, the portable playback device 710 identifies one or more target playback devices via an audio-based identification technique as described in Section VI. In such examples, identifying one or more target playback devices can include identifying a set of playback devices eligible for a swap within the media playback system and then transmitting, to the set of playback devices eligible for a swap, respective audio chirps that identify the playback device eligible for the swap that is transmitting. The portable playback device 710 can then detect, via one or more microphones, the audio chirps emitted by one or more playback devices eligible for a swap and select, from among the one or more playback devices eligible for a swap, one or more target playback devices based on the audio chirps from the one or more source playback devices indicating that the one or more target playback devices are physically closest to the portable playback device 710 among the one or more playback devices eligible for a swap. Selecting one or more target playback devices can include comparing one or more respective metrics of the audio chirps emitted and detected by one or more playback devices eligible for a swap to determine that the one or more target playback devices are physically closest to the portable playback device 710 among the one or more playback devices eligible for a swap. The comparison can be performed by any device within the media playback system and / or the remote computing system.

[0236] In block 1306B, method 1300B includes swapping a playback session from a portable playback device to one or more target playback devices. For example, the portable playback device 710 may transfer its playback session to one or more target playback devices. Transferring the playback session may include forming a first synchronization group that includes the portable playback device 710 and the one or more target playback devices. By forming the first synchronization group, the one or more target playback devices begin playback of a particular audio content of the playback session.

[0237] Transferring the playback session can further include stopping the playback of specific audio content on the portable playback device 710. In some examples, the playback of specific audio content on one or more source playback devices is stopped by removing the portable playback device 710 from the first synchronization group. Other examples are possible as well.

[0238] c. Exemplary Home Theater Swap Method Method 1400 illustrates an exemplary home theater swap technique. A soundbar-type playback device can execute the home theater swap technique to cause a wearable playback device or a portable playback device to play audio received by the soundbar-type playback device and transmitted to the swap target device.

[0239] In block 1402, method 1400 includes playing audio while in the home theater mode. For example, a soundbar-type playback device can play audio while in the home theater mode. In some examples, the soundbar-type playback device is the master device of the first synchronization group. For example, an exemplary soundbar type is playback device 110h, which can operate as the source device of the coupling zone of the den 101d. This coupling zone includes playback devices 110j and 110k and / or playback device 110i, as shown in FIGS. 1K and 1J.

[0240] In block 1404, method 1400 includes receiving an instruction to transition to the swap mode. For example, as shown in FIG. 12A, playback device 110h may receive data representing an instruction to transition to the swap mode from a wearable playback device such as headset 710a. As another example, as shown in FIG. 12B, playback device 110h may receive data representing an instruction to transition to the swap mode from control device 130.

[0241] In block 1406, method 1400 includes transitioning from a home theater mode to a swap mode. The soundbar type playback device can transition from the home theater mode to the swap mode based on receiving data representing an instruction to enter the swap mode.

[0242] As described in connection with FIGS. 12A and 12B, the transition from the home theater mode to the swap mode can include various steps. For example, to facilitate connecting the wearable playback device as a satellite to playback device 110h, playback device 110h can transition its 802.11 compliant network interface from operating as a node in a mesh network to operating as an access point forming a first wireless local area network (LAN) in a first radio frequency band. Further, playback device 110h can transmit data representing the service set identifier (SSID) of the first wireless LAN and a certificate for the first wireless LAN that can be used by the wearable playback device to connect to the first wireless LAN to the wearable playback device via the 802.11 compliant network interface.

[0243] Transitioning from the home theater mode to the swap mode can further include forming a second synchronization group including a sound bar type playback device and a wearable playback device. For example, the playback device 110h and the headphones 710a may form a second coupling zone after the headphones 710a are connected to the first wireless LAN. After forming the second coupling zone, the playback device 110h may operate as a source device for the second coupling zone. In this role, the playback device 110h transmits data representing the second synchronization group and the audio playback timing information to the headphones 710a. The headphones 710a play the audio according to the timing information as described in Section IV. After forming the second synchronization group, the playback device 110h mutes the audio playback while the headphones 710a are playing the audio.

[0244] Transitioning from the home theater mode to the swap mode can further include parking one or more satellite playback devices on the second wireless LAN. For example, the playback device 110h may connect the playback devices 110j and 110k and / or the playback device 110i to the second wireless LAN in the second radio frequency band and move them away from the first synchronization group.

[0245] In a further example, the sound bar type playback device can add one or more additional wearable playback devices to the swap mode at the same time as the first wearable playback device. For example, while in the swap mode, the playback device 110h may receive data representing an instruction to transition to the swap mode from a second wearable playback device such as the earbuds 710b or in other situations the headphones 710a. Based on receiving the data representing the instruction to enter the swap mode, the playback device 110h causes the second wearable playback device to join the second synchronization group.

[0246] Causing the second wearable playback device to join the second synchronization group can include transmitting data representing the SSID of the first wireless LAN and the certificate for the first wireless LAN to the second wearable playback device. For example, after the second wearable playback device connects to the first wireless LAN formed by the playback device 110h, the playback device 110h receives a display from the second playback device indicating that the second playback device is ready for playback, and adds the second wearable playback device to the second synchronization group including the playback device 110h and the headphones 710b. At that time, the playback device 110h transmits data representing the second synchronization group and the audio playback timing information to the second wearable playback device. The second wearable playback device plays back audio in synchronization with the first wearable playback device based on the playback timing information, as described in Section VI.

[0247] d. Exemplary Swap Method Method 1500 shows another exemplary swap method.

[0248] In block 1502, method 1500 includes detecting a swap trigger. The swap trigger can initiate a playback session swap between one or more source playback devices and one or more target playback devices. In various embodiments, a source playback device or a target playback device detects the swap trigger and initiates the playback session swap. Alternatively, another related device such as the control device 130 or the bridge device 860 detects the trigger and initiates the playback session swap.

[0249] As described herein, some exemplary swap triggers include detecting a user action such as a user input. For example, a source playback device (e.g., the portable playback device 710) can detect a specific input that represents a swap command and initiate a playback session swap based on the detection of the specific input. As another example, the control device 130 can detect a specific input that represents a swap command and initiate a playback session swap based on the detection of the specific input. Various other examples are possible.

[0250] Other exemplary swap triggers are based on proximity. For example, some exemplary swap triggers include detecting the proximity between a source playback device (or a paired device, such as the control device 130a) and a target playback device. Further exemplary swap triggers include detecting the proximity of a source playback device (or a paired device, such as the control device 130a) to a specific location, such as the location of the home of the media playback system 100. Other exemplary swap triggers are described throughout, and various other suitable swap triggers are possible.

[0251] In block 1504, the method 1500 includes determining one or more source playback devices and one or more target playback devices. As described above, an exemplary implementation includes swapping playback between one or more portable playback devices 710 and one or more playback devices 110. The portable playback device 710 may operate as a source playback device or a target playback device depending on the context. The playback device 110 may similarly participate in a playback session swap as a source playback device or a target playback device.

[0252] In an example, the source playback device is determined based on context. For example, if playback device 710 detects a specific input representing a swap command, playback device 710 can initiate a playback session swap as the source playback device based on the detection of this specific input. In another example, if control device 130 detects a specific input representing a command to swap playback from playback device 110, control device 130 may initiate a playback session swap with playback device 110 as the source playback device, or may send data indicating the command to playback device 110 to cause playback device 110 to initiate a playback session swap as the source playback device.

[0253] In a further example, the context is based on proximity. For example, if portable playback device 710 detects the proximity of one or more potential target playback devices 110, portable playback device 710 can initiate a playback session swap with portable playback device 710 as the source playback device. As another example, if paired control device 130 or bridge device 860 detects the proximity of one or more potential target playback devices 110 and the paired portable playback device 710 is playing audio content, paired control device 130 or bridge device 860 may initiate a playback session swap with paired portable playback device 710 as the source playback device, or may send data indicating the proximity of playback device 110 to paired portable playback device 710 to cause paired portable playback device 710 to initiate a playback session swap as the source playback device.

[0254] As described above in Section V, in some examples, one or more target devices are determined based on a predetermined swap pair with the source playback device. For example, as shown in FIG. 11A, kitchen 101h is designated as a predetermined swap pair with headphones 710a. As described above, the swap pair can be configured and / or reconfigured via control device 130 or other suitable devices.

[0255] Alternatively, as described above in Section V, one or more target devices are determined based on proximity to the source playback device. The proximity between the source playback device and one or more target devices can be determined using any suitable proximity detection technique, including the proximity detection techniques described above in Section V. Further, as described above, "proximity" can be defined in one or more scopes such as location (e.g., home), zone, area, or individual device.

[0256] Furthermore, in other examples, one or more target devices are determined based on context. For example, one or more playback devices can detect a specific input indicating a command to designate one or more playback devices as target playback devices. In a further example, one or more target playback devices are determined based on an association between the target playback device and a device base. For example, if device base 718a is associated with kitchen 101h, placing portable playback device 710c on device base 718a may trigger a playback session swap between portable playback device 710c and playback device 110b.

[0257] When the first playback device 110 is determined as a source or a target based on the context, one or more additional playback devices 110 may be determined based on synchronization grouping between the first playback device 110 and the one or more additional playback devices 110. For example, when the playback device 110l in the master bedroom 101b is determined as the target device, based on the combined pair configuration of the playback device 110m and the playback device 110l, the playback device 110m is also determined as the source playback device. In another example, when a kitchen + dining room zone group is configured and the playback device 110d in the dining room receives a swap input, the playback device 110b is also determined as the source playback device. This facilitates session swapping from all playback devices 110 participating in the playback session.

[0258] In block 1506, method 1500 includes swapping a playback session from one or more source playback devices to one or more target playback devices. In an embodiment, method 1500 can implement any suitable technique for swapping a playback session, such as the exemplary messaging, cloud queue, and grouping techniques described in Section V. Other examples are also conceivable.

[0259] IX. Exemplary Bridge Device In some exemplary implementations, a portable playback device such as headphones 710a, earbuds 710b, or a portable playback device 710c can interface with the media playback system 100 via a bridge device 860. FIG. 16A shows an exemplary pairing configuration between headphones 710a and a bridge device 860a. In contrast to a general-purpose smartphone or tablet configured as a control device 130 and including bridge features, the bridge device 860a is configured using hardware and software for interfacing a portable playback device 710a with the media playback system 100. The bridge device 860a can also include other features for supporting or extending the media playback system 100.

[0260] Similar to the control device 130a, the bridge device 860a can include a communication interface, processing capabilities, and / or other features not necessarily implemented in the portable playback device 710a. When the "portable playback device 710a is 'paired' with the bridge device 860a", the portable playback device 710a can utilize some of these features. This arrangement can enable, among other possible advantages, the portable playback device 710a to be smaller, more portable, consume less power, and / or be less expensive. For example, similar to the control device 130a, the bridge device 860a can include additional communication interfaces compared to the portable playback device 710a. For example, the headphones 710a may connect to the Internet using the cellular data connection of the bridge device 860a. As another example, the headphones 710a may utilize the wireless network interface of the bridge device 860a to connect to the playback device 110 via the network 104 or to connect to the Internet.

[0261] In a further example, the portable playback device 710 can be paired with both a mobile device (e.g., a smartphone or tablet, which can implement the control device 130 via installation of a controller application software) and a bridging device 860. In such an implementation, the portable playback device 710a can stream audio content from the mobile device via a first network interface (e.g., a Bluetooth® network interface) and connect to the bridging device 860 via a second network interface (e.g., a wireless local area network interface). In this configuration, the mobile device has an internet connection to facilitate audio streaming, and the bridging device 860 functions as an interface to the media playback system 100.

[0262] In an exemplary embodiment, the bridging device 860a is coupled to a specific playback device (e.g., playback device 110c), a combined zone of playback devices (e.g., playback devices 110l and 110m), or a group of playback devices, such as a "kitchen + dining room" group). Alternatively, if a home graph hierarchy is utilized, the bridging device 860a may be coupled to a specific set, room, or area. At this time, the control of the playback device 110 coupled to the bridging device 860a via the NMD120 or the control device 130 also controls the paired portable playback device 710a.

[0263] Alternatively, the bridging device 860a itself may form a zone or a set. For example, in one example, the bridging device 860a may be configured as a "Ben's headphones" zone or a "Ben's headphones" set. By configuring the bridging device 860a, the control between the paired headphones 710a and the NMD120 and / or the control device 130 of the media playback system 100 is facilitated.

[0264] FIG. 16B is a block diagram of a bridge device 860a with an input / output 811. The input / output 811 can include analog I / O 811a (e.g., one or more wires, cables, and / or other suitable communication links configured to carry analog signals) and / or digital I / O 811b. The bridge device 860a further includes an electronic device 812 and a user interface 813 (e.g., one or more buttons, knobs, dials, touch-sensitive surfaces, displays, touchscreens). The bridge device 860a optionally implements an NMD 820 and can include one or more microphones 815 (e.g., a single microphone, multiple microphones, microphone array) (hereinafter referred to as "microphone 815") to facilitate voice input.

[0265] In the illustrated embodiment of FIG. 16B, the electronic device 812 includes one or more processors 812a (hereinafter referred to as "processor 812a"), a memory 812b, software components 812c, a network interface 812d, and power 812i. In some embodiments, the electronic device 112 optionally includes one or more other components 812j (e.g., one or more sensors, video displays, touchscreens).

[0266] In some examples, the electronic device 812 includes one or more audio processing components 812g (hereinafter referred to as "audio component 812g"), one or more audio amplifiers 812h (hereinafter referred to as "amplifier 812h"), and one or more transducers 814 to facilitate an audio response from the NMD 820. However, audio playback is not an intended purpose of the bridging device, and thus, the audio playback capabilities are generally very limited compared to the playback device 110 and the portable playback device 710.

[0267] Processor 812a can include a clock-driven computing component configured to process data, and memory 812b can include a computer-readable medium (e.g., a tangible non-transitory computer-readable medium loaded with one or more of software components 812c, data storage) configured to store instructions for performing various operations and / or functions. Processor 812a is configured to execute instructions stored in memory 112b to perform one or more of the operations. The operations can include, for example, pairing with a particular portable playback device 710 and related functions.

[0268] Network interface 812d is configured to facilitate transmission of data between bridging device 860a and one or more other devices of a data network such as, for example, link 103 and / or network 104 (FIG. 1B). In the illustrated embodiment of FIG. 16B, network interface 812d includes one or more wireless interfaces 812e (hereinafter referred to as "wireless interface 812e"). Wireless interface 812e (e.g., a suitable interface including one or more antennas) can be configured to wirelessly communicate with one or more other devices (e.g., playback device 110, NMD 120, control device 130, and / or portable playback device 710) communicatively coupled to network 104 (FIG. 1B) according to a suitable wireless communication protocol (e.g., WiFi, Bluetooth, LTE). In some examples, wireless interface 812e forms an ad hoc network with the paired portable playback device 710. In some embodiments, network interface 812d optionally includes a wired interface 812f (e.g., an interface or receptacle configured to receive a network cable such as Ethernet, USB-A, USB-C, and / or Thunderbolt cable) configured to communicate with other devices via a wired connection according to a suitable wired communication protocol.

[0269] Figure 16C is a front isometric view of a bridge device 860a configured according to an aspect of the technology disclosed as a command device 862a of the media playback system 100. To configure the bridge device 860a as the command device 862a, the user interface 813a of the bridge device 860a includes playback control. Examples of playback control include, among other examples, transport (e.g., play / pause, fast forward / rewind skip) and volume control. Similar to the control device 130, inputs to these playback controls are converted into playback commands via the software component 812c and transmitted to one or more playback devices 110 and / or 710 via the network interface 812d to control playback.

[0270] In an exemplary embodiment, the command device is configured to control only paired and / or coupled playback devices, generally not the playback devices 110a - n of the media playback system 100, as compared to the control device 130. For example, in the example of FIG. 16A where the bridge device 860a is paired with the portable playback device 710a, the playback commands issued by the command device 862a are executed on the portable playback device 710a. Further, when the bridge device 860a is coupled to one or more playback devices 110, the playback commands issued by the command device 862a are also executed on the coupled playback devices 110.

[0271] The user interface 813a of the bridge device 860a includes a dial 863a to facilitate volume control of the paired playback device 710 and / or the coupled playback device 110. In this example, the dial 863a is formed by a first portion of the housing 816a that rotates around the base of the housing 816a as shown in FIG. 16C. Clockwise and counterclockwise rotation of the dial 863a corresponds to vertical volume adjustment.

[0272] The user interface 813a of the bridge device 860a also includes a touch-sensing area 864a to facilitate the transport control of the paired playback device 710 and / or the coupled playback device 110, as shown in FIG. 16D. The touch-sensing area 864a is formed on the upper surface of the housing 816a, as shown in FIG. 16C. The touch-sensing area 864a may be implemented as a capacitive or resistive touch-sensing area, among other examples. In this example, a touch input to the center of the touch-sensing area 864a is interpreted as a play / pause toggle. The touch-sensing area 864a may also interpret specific inputs as fast-forward and rewind skips. For example, touch inputs to the right and left sides of the touch-sensing area 864a may be interpreted as a fast-forward skip and a rewind skip, respectively. Alternatively, a left-to-right swipe gesture on the touch-sensing area 864a may be interpreted as a fast-forward skip, and a right-to-left swipe gesture may be interpreted as a fast-forward skip.

[0273] In certain embodiments, the user interface 813a of the bridge device 813a is intentionally limited to a specific subset of playback commands as compared to "full-feature" control supported by the control device 130. As shown in FIGS. 16C and 16D, such a subset can include volume control and transport control (and perhaps only certain transport controls). Such a simplified minimal user interface can improve the user experience of the paired playback device 710 or the coupled playback device 110 by reducing annoyance, among other possible advantages.

[0274] In an embodiment of the command device 862a that excludes a library and / or search control for selecting audio content for playback, starting playback via the command device 862a can initiate a storage location for a particular audio. The storage location for a particular audio may be preconfigured by the user via the control device 130 or may be automatically selected by the media playback system. Exemplary storage locations for audio include playlists, Internet radio stations, albums, and podcasts.

[0275] FIG. 16E is a front view of an exemplary bridge device 860b. In contrast to the circular housing 816a of the bridge device 860a, the housing 816b of the bridge device 860b is more rectangular. The user interface 813b of the bridge device 860b includes a dial 863b on the front of the housing 816b, a touch-sensing area 864b on the top of the housing 816b, and buttons 865a-d on the front of the housing 816b. Similar to the dial 863a, the dial 863b facilitates volume control of the portable playback device 710 paired with the bridge device 860b and / or the playback device 110 coupled to the bridge device 860b. Further, the touch-sensing area 864b, similar to the touch-sensing area 864a, facilitates transport control of the paired portable playback device 710 and / or the coupled playback device 110.

[0276] The buttons 865a-d each correspond to a storage location for an audio. The storage location for a particular audio may be preconfigured by the user via the control device 130 or may be automatically selected by the media playback system (e.g., based on user-specified favorites or listening frequency). Selecting a particular button 865 causes the paired playback device 710 and / or the coupled playback device 110 to start playback of the corresponding storage location, in a manner similar to tuning a radio to the corresponding radio station for a radio preset.

[0277] For example, when button 865a is selected, bridge device 860b causes paired playback device 710 to send one or more instructions to play the storage location of the audio corresponding to button 865a. The one or more instructions may include a URI indicating the location of the storage location of the audio in computing device 106 (e.g., a content server of a streaming audio service). Next, the paired playback device 710 streams the storage location of the audio from the computing device 106 and plays the storage location of the audio.

[0278] In some implementations, bridge device 860 can include a graphical display. In such an example, user interface 813 of bridge device 860 can include a graphical user interface displayed on a touch-sensitive graphical display. In some examples, the graphical display is touch-sensitive to facilitate touch input to the graphical user interface. Further, the graphical user interface can reduce, among other possible advantages, the discomfort caused by the presence of the graphical display and can have limited playback control compared to control devices 430 and 530.

[0279] To illustrate, FIG. 17A presents a first user interface display 1770a configured to be displayed on a bridge device having a circular touch-sensitive graphical display. For example, an exemplary implementation of bridge device 860a can implement touch-sensitive area 864a as a circular touch-sensitive graphical display. Other shapes and arrangements of the touch-sensitive graphical display are also contemplated.

[0280] The first user interface display 1770a includes a plurality of regions 1771a - f similar to buttons 865a - d (FIG. 8F). In the first user interface display 1770a, regions 1770a - g are selectable via touch input to each region. Each region 1771 corresponds to a storage location for respective audio. The specific storage location for audio may be pre - configured by the user via the control device 130 or may be automatically selected by the media playback system (e.g., based on user - specified favorites or listening frequency). Exemplary storage locations for audio include Internet radio stations, playlists, albums, Podcasts, and other streaming audio content. Selecting a specific button 865 causes the paired playback device 710 and / or the coupled playback device 110 to start playback of the corresponding storage location.

[0281] Here, by way of example, region 1770a is shown at the central position of the first user interface display 1770a. Regions 1771b and 1771f are partially shown at the lower and upper positions of the first user interface display 1770a, respectively. By using an upward or downward swipe gesture to scroll the first user interface display 1770a upward or downward, regions 1771b or 1771f can be fully displayed. Similarly, regions 1771c - e can be displayed in a round - robin manner. To explain, FIG. 17B shows an upward swipe that moves region 1771b towards the central position. FIG. 17C shows region 1771b at the central position after the upward swipe of FIG. 17B. As shown in FIG. 17C, regions 1771a and 1771c are partially displayed when region 1771b is at the central position.

[0282] When a specific area 1771 (e.g., area 1771a) is selected, the bridge device 860 causes the paired playback device 710 and / or the coupled playback device 110 to start playing back the corresponding storage location. When area 1771a is selected again during the playback of the storage location, the bridge device 860 causes the paired playback device 710 and / or the coupled playback device 110 to stop playing back the corresponding storage location. Thus, area 1771 functions as a play / pause button.

[0283] Other transport controls may be implemented by a graphical user interface. For example, as shown in FIG. 17C, the swipe gesture on the first user interface display 1770a correlates to fast forward skips and rewind skips. In particular, a left swipe can cause a fast forward skip, while a right swipe can cause a rewind skip.

[0284] FIG. 17D presents a second user interface display 1770b that may be presented based on the selection of area 1771a. The second user interface display 1770b includes a graphical representation of the audio content being played back on the paired playback device 710 and / or the coupled playback device 110, as well as an area 1772 that includes media content information corresponding to the audio content. For example, if the storage location of the selected audio is playing an audio track, the metadata corresponding to the audio track is displayed in area 1772.

[0285] The second user interface display 1770b may also include one or more transport controls. Specifically, the second user interface display 1770b includes a jump fast forward control 1773a and a jump rewind control 1773b. In various embodiments, the second user interface display 1770b may similarly include other transport controls. For example, a swipe gesture on the second user interface display 1770b may correlate with a fast forward skip and a rewind skip, similar to the first user interface display 1770a.

[0286] The second user interface display 1770b may further include navigation controls. As an example, the second user interface display 1770b includes navigation controls 1774a and 1774b. The navigation control 1774a causes the first user interface display 1770a to be displayed on the bridge device 860. The navigation control 1774b causes a third user interface display 1770c including a queue to be displayed on the bridge device 860.

[0287] Specifically, FIG. 17E presents a third user interface display 1770c that may be displayed based on the selection of the navigation control 1774b. As shown, the third user interface display 1770c includes an interface for browsing through an audio storage location. Selecting an individual audio track or other media item within the audio storage location causes that media item to be played. For example, if the selected audio storage location is a playlist, the third user interface display 1770c lists the audio tracks of the playlist. As another example, if the selected audio storage location is a Podcast, the third user interface display 1770c may display other available audio content (e.g., Podcast episodes) within that storage location.

[0288] In some implementations, the graphical user interface facilitates the selection of a portable playback device 710 for pairing with a bridge device 860 and / or a playback device 110 to couple with a command device 862. To explain, FIG. 17F presents a fourth user interface display 1770d having a plurality of toggle controls 1775 corresponding to respective portable playback devices 710 and zones. Toggling a toggle control 1775 pairs or couples the corresponding portable playback device 710 or playback device 110 with the bridge device. As shown, the toggle control 1775a corresponding to the headphones 710a is turned on so that the headphones 710a are paired with the bridge device 860.

[0289] Selecting a plurality of zone names forms a zone group between the zones (if not already formed), and the bridge device 860 is paired with the zone group (thereby controlling all playback devices 110 of the zone group). Selecting the "all" toggle causes the media playback system 100 to enter party mode (where all playback devices 110 play music in sync), and the bridge device 860 is paired with all playback devices 110 of the media playback system 100.

[0290] In an exemplary embodiment, the bridge device 860 charges one or more batteries via the placement of the device base 718. FIG. 18A shows the placement of the bridge device 860a on the device base 718b. The bridge device 860a can interact with the device base 718b in the same or a similar manner as the portable playback device 710c. For example, if the device base 718b is associated with a zone of the media playback system 100, placing the bridge device 860a on the device base 718b causes the bridge device 860a (and the paired portable device 710) to join the associated zone.

[0291] In an exemplary embodiment, the bridge device 860a is rotatable relative to the device base 718b to control the volume of the portable playback device 710 paired with the bridge device 860a. In some implementations, the rotation of the bridge device 860a relative to the device base 718b also controls the volume of the playback device 110 coupled to the bridge device 860a. Similar to the bridge device 718a, the bridge device 860a can rotate relative to the device base 718b and can generate a volume control signal in a sensor of the bridge device 860a and / or the device base 718b. In another example, a first portion of the device base 718b is rotatable relative to a second portion of the device base 718b. The rotation of these two portions generates a volume control signal in a sensor of the device base 718b that controls the volume of the playback device 710 paired when the bridge device 860a is placed on the device base 718b.

[0292] The bridge device 860 of the media playback system 100 may also have other features to support the portable device 710 of the media playback system. For example, the bridge device 860 can support charging of the portable device 170. To explain, FIG. 18B shows an exemplary stacked configuration including a device base 718b that charges the bridge device 860a and a bridge device 860a that charges the earbud 710b via a charging case 1080. Similar to the device base 718, the bridge device 860a can charge the earbud 710b via inductive charging or conductive terminals. In some implementations, the device base 718b may directly charge the earbud 710b by placing the charging case 1080 on the device base 718b. Other form factors of the charging case 1080 may be used to charge other form factors of the portable playback device 710 (e.g., headphones 710a).

[0293] FIG. 18C shows another exemplary stacked configuration for facilitating charging of a device. In this example, device base 718a charges portable playback device 710c. Portable playback device 710c charges bridge device 860a. Bridge device 860a charges earbuds 710b via charging case 1080. In this configuration, only device base 718a requires external power to charge various stacked devices.

[0294] X. Additional Swap Examples In some examples, the source and target of a swap are predefined. In a given swap pair, the source is playback device 710 or one or more playback devices 110 that are playing audio content, and the target is another playback device that is not playing audio content. A playback swap between the source and target playback devices is performed when a swap trigger action, such as a button press or other user input, is detected.

[0295] In some implementations, an input to the source device of a swap pair triggers the swap. For example, a specific input to user interface 713a of headphones 710 (FIG. 7B), such as a tap or gesture on a touch-sensing area (or a portion thereof), may trigger the swap. In a further example, portable playback device 710 may include a physical button for triggering the swap. Still further, a pattern of touch inputs (e.g., short, long, short) or a tracking pattern (e.g., a shape such as a zigzag or triangle) can trigger the swap. Other types of inputs are also conceivable.

[0296] Additionally or alternatively, an input to the target device triggers a swap. For example, a specific input to the user interface 113 of the playback device 110a (FIG. 1C) may trigger a swap. In a further example, the playback device 110 may include a physical button for triggering a swap. Operating the button (e.g., by selection, contact, slide, etc.) triggers a swap. Other types of inputs are also conceivable.

[0297] In an example, user interfaces such as the user interface 133 of the control device 130a or the user interface 813 of the bridge device 860a can facilitate the definition of pre-defined swap pairs. To explain, FIG. 19A presents a first user interface display 1931a for facilitating the definition of a swap pair for the headphones 710a (“Ben's headphones”). The first user interface display 1931a is configured to be displayed on, for example, the control device 430, but may be adapted to be displayed on other exemplary devices disclosed herein. The control device 430 may display the first user interface display 1931a during the setup procedure of the headphones 710a. Further, the user may display the first user interface 1931a via, among other examples, the settings user interface display.

[0298] As shown, the first user interface display 1931a includes a graphic display (i.e., zone name) of the zones within the media playback system 100 and a toggle control corresponding to each zone. When the toggle control is switched, the corresponding zone is configured as a swap pair with the headphones 710a. In this example, the kitchen 101h is defined as a swap pair with the headphones 710c. Although a toggle control is shown as an example, other types of control may be used in other embodiments. An exemplary user interface can include a functionally similar user interface display for defining swap pairs for other portable playback devices 710 of the media playback system 100 (e.g., earbuds 710b and / or portable playback device 710c). The predefined swap pairs may be stored in the control device 130, the playback device, and / or the data storage of the portable playback device 710, perhaps as one or more state variables shared between these devices.

[0299] Alternatively, if a home graph hierarchy is implemented, a similar user interface display can include a graphic display of the set of home graphs, rooms, and / or areas configured in the media playback system 100. This user interface display can include a toggle control or other similar control corresponding to each set, room, and / or area. In this example, the toggle control configures the corresponding set, room, and / or area as a swap pair with the headphones 710a.

[0300] In some implementations, the media playback system 100 can define two or more swap pairs for a portable playback device. To explain, FIG. 19B presents a second user interface display 1931b to facilitate the definition of multiple swap pairs for the earbuds 710b. As shown, each predefined swap pair corresponds to a different input (e.g., a different gesture). Performing an input corresponding to a particular predefined swap pair triggers the swap of that swap pair.

[0301] The user can define a custom input corresponding to a predefined swap pair. To explain, FIG. 19C presents a third user interface display 1931c to facilitate the definition of a custom gesture. As shown, the third user interface display 1931c includes a prompt for providing a custom gesture. After pressing starts, the earbuds 710b of the swap pair and the playback devices 110l and 110m monitor their respective user interfaces 713b and 113 to detect the custom input and then store the custom input in the data storage.

[0302] In a further example, placing a portable playback device 710 on a charging base triggers a swap. For example, placing the portable playback device 710c on the device base 718a (FIG. 7F) can trigger a swap. In some implementations, the swap target is predefined for the portable playback device 710c.

[0303] Alternatively, the device base 718a may be coupled to one or more specific zones. Then, when the portable playback device 710c is placed on the device base 718a, a swap to one or more specific zones is triggered. Further details regarding the coupled zones to the device base can be found, for example, in U.S. Patent No. 9,544,701, entitled "Base Properties in a Media Playback System", which is hereby incorporated by reference in its entirety as described above.

[0304] In a further example, an input to the user interface of the device base 718a can trigger a swap. Exemplary inputs include button presses (or other operations) or touch inputs to a touch-sensing area, similar to the exemplary inputs described above. For example, a specific gesture may be interpreted by the device base 718a as a swap trigger.

[0305] In a further example, an input to the user interface 113 of the NMD120a triggers a swap. For example, the user can utter a voice input such as "Swap to the kitchen". As described above in connection with FIGS. 3A-3D, the user can activate a voice assistance service to process voice input by a wake word or button press (e.g., push-to-talk). This voice input includes a first command indicating an action ("Swap") and a second command indicating the target playback device of the action ("Kitchen"). Here, as described above in connection with FIGS. 3A-3D, the voice input is sent to and processed by the voice assistance service. In some cases, the instructions corresponding to the processed voice command are sent back to the source playback device or the target playback device to effect a playback session swap. Alternatively, the instructions corresponding to the processed voice command are transferred to the server to effect a playback session swap, as will be described in more detail below in connection with FIGS. 12B and 12C. The NMD120a can verbally confirm the swap by a voice response such as "<Audio content name> is now playing in the kitchen" following the swap.

[0306] In some cases, both the source playback device and the target playback device are playing audio content when a swap trigger is detected. In such an example, the respective playback sessions of the source playback device and the target playback device can be swapped such that the source playback device starts playing the audio content that the target had previously played, and the target starts playing the audio content that the source had previously played. Alternatively, the playback session of the source playback device is swapped to the target playback device and playback at the target is stopped.

[0307] In an exemplary embodiment, the source playback device can facilitate the swap by sending playback session data to the target device. The playback session data can include data representing a source of the audio content (e.g., a URI or URL indicating the location of the audio content), and an offset indicating a position within the audio content to start playback. The offset can be defined, among other examples, as the time from the start of the audio track (e.g., in milliseconds) or as a number of samples. In an exemplary implementation, the offset can be set to the playback position in the audio content of the current playback position to enable the target device to start buffering the audio content. At this time, the source playback device stops playing the audio content at the offset, and the target playback device starts playing the audio content at the offset.

[0308] The playback session data can further include one or more identifiers corresponding to the playback session. For example, the playback session data can include a session identifier that distinguishes the playback session from other playback sessions. The playback session data can also include an application identifier that identifies the media playback system controller application software that controls the playback session. Additionally, the playback session data can include a streaming audio service identifier that identifies the streaming audio service hosting the audio content at the source, as well as an audio item identifier (e.g., a unique identifier used by the streaming audio service to identify the audio content). As another example, a home identifier can be included in the playback session data to distinguish the media playback system 100 from other media playback systems. As a further example, a group identifier can identify devices in a zone, combined zone, or zone group.

[0309] The playback session data can further include data representing the playback state. The playback state can include the playback state of the session (e.g., playing, pausing, or stopped). If the playback session implements a playback queue, the playback session data can include the playback queue state such as the current playback position within the queue.

[0310] The playback queue state can also include the queue version. For example, in an embodiment of the cloud queue, the cloud queue server and the media playback system 100 can use the queue version to maintain consistency. The queue version can be incremented each time the queue is changed to indicate the latest version of the queue and then shared between the media playback system 100 and the cloud queue server.

[0311] Furthermore, the playback session data can also include authentication data such as one or more keys and / or tokens. Such authentication data can include tokens associated with the user's account. During a playback session swap, the media playback system 100 can verify that the token is permitted on both the source and target playback devices. The authentication data can further include a token associated with a streaming audio service, which can enable the target playback device to access the audio content at the source. Additionally, the authentication data can include a token associated with the playback session that enables the target playback device to access the session. Other exemplary authentication data is also contemplated.

[0312] To explain, FIG. 20A is an exemplary message flow diagram showing commands exchanged between a source playback device, a target playback device, and a content server during an exemplary swap of a playback session. Such messages are representative and can include additional or fewer messages. In some implementations, the messages are sent not from the portable playback device 710 (as the source or target playback device), but from the paired control device 130a (FIG. 7G) or the paired bridge device 860a (FIG. 16A).

[0313] In 2081a, the source playback device starts a playback session. The playback session may be started, among other examples, by the source playback device, the control device 130, or the bridge device 860. In some cases, the playback session can include one or more additional playback devices that play back in synchronization with the source playback device as part of a group.

[0314] In 2082a, the source playback device detects a swap trigger, such as any of the exemplary swap triggers described above, among other examples. In some cases, another device (e.g., the target playback device, the control device 130, the device base 718, or the bridge device 860) detects the swap trigger and sends data indicating that the swap trigger has been detected to the source playback device.

[0315] In 2083a, the source playback device sends playback session data to the target playback device. As shown by way of example, the playback session data includes data representing a URI indicating the source of the audio content currently being played in the session (e.g., the currently playing audio track). Also, the playback session data includes data representing an offset of the audio content indicating the position at which to start playback. Additionally, if the source playback device is playing audio content from a queue, the playback session data can further include data representing the queue, which can include URIs corresponding to each media item in the queue, as well as the order of the media items queued. Further, the playback session data includes one or more identifiers as described above.

[0316] In 2084a, the target playback device sends a fetch message to the content server to request a stream of audio content from the content server. The fetch message can include a URI indicating the source of the audio content at the content server. The fetch message can further include an offset. The fetch message can also include other data such as one or more identifiers and / or authentication data.

[0317] Based on this fetch message, in 2085a, the content server streams the audio content to the target playback device for playback. The content service can start the stream at the offset of the audio content. At this time, the target playback device starts playback of the audio content at the offset of the audio content.

[0318] In 2086a, after receiving the playback session data, the target playback device transmits an affirmative response message to the source playback device. In an exemplary implementation, the source playback device may not need to stop the playback session until it receives an affirmative response message from the target playback device. The affirmative response message can indicate that the swap was successful.

[0319] Other exemplary implementations utilize a cloud queue to facilitate the playback session swap. In contrast to the queue of the data storage of the playback device 110 (i.e., the local queue), the cloud queue of the playback session is maintained within the cloud of the computing device 106. In this implementation, instead of locally controlling the playback devices 110a - n via the network 104, the control device 130a controls the playback devices 110a - n via the computing device 106 by operating on the cloud queue of the computing device 106. The computing device 106 synchronizes the cloud queue (or a portion thereof) with the playback devices 110 participating in the playback session.

[0320] To explain, FIG. 20B is an exemplary message flow diagram showing the commands exchanged between the source playback device and between the cloud queue server, the target playback device, and the content server during an exemplary swap of a playback session. Such messages are representative and can include additional or fewer messages. In some implementations, the messages are transmitted not from the portable playback device 710 (as the source or target playback device), but from the paired control device 130a (FIG. 7G) or the paired bridge device 860a (FIG. 16A).

[0321] In 2081b, the source playback device starts a playback session. The playback session may be started, among other examples, by the source playback device, the control device 130, or the bridge device 860. In some cases, the playback session can include one or more additional playback devices that play back in synchronization with the source playback device as part of a group.

[0322] In 2082b, the source playback device detects a swap trigger, among other examples, such as any of the exemplary swap triggers described above. In some cases, another device (e.g., the target playback device, the control device 130, the device base 718, or the bridge device 860) detects the swap trigger and sends data indicating that the swap trigger has been detected to the source playback device.

[0323] In 2087, the source playback device sends a swap session message including playback session data to the cloud cue server. The swap session message can indicate the target playback device via one or more identifiers. In some examples, such as pre-defined swap pairs, the cloud cue server can maintain pre-defined swap pairs for the media playback system 100. The swap session message can also include data representing an offset within the audio content indicating the position of the audio content to start playback. In an example, the cloud cue server can also track the playback position in the playback session and use the position in the swap session message to verify the playback position. Additionally, the swap session message can include a home identifier that identifies the media playback system 100 (to distinguish it from other media playback systems in other homes), as well as one or more player identifiers for identifying the source and / or target playback devices.

[0324] Based on receiving a swap session message, the cloud queue server re-targets the session from the source device to the target device. For example, the cloud queue server can identify the cloud queue of the media playback system 100 using the home identifier of the playback session data, and then can identify the cloud queue used in the playback session using the group identifier (or queue identifier). The cloud queue server can swap this session for the target playback device to change the cloud queue data to associate the cloud queue with the target playback device. Alternatively, the cloud queue server can mirror the cloud queue of the source device with the cloud queue of the target playback device, and then set the playback state of this cloud queue to match the playback state indicated in the playback session data.

[0325] For example, in 2088, the cloud queue server sends the playback session data to the target playback device. The playback session data includes data representing a URI indicating the source of the audio content currently being played in the session (e.g., the currently playing audio track). Also, the playback session data includes data representing an offset of the audio content indicating the position at which to start playback. Additionally, if the source playback device is playing audio content from a cloud queue having multiple audios, the playback session data can further include data representing a window from the cloud queue. The window can indicate media items after the currently playing audio content, and in some cases, media items before the currently playing audio content. The target playback device can queue this window to the local queue to facilitate further playback of the cloud queue in the transferred session.

[0326] In 2084b, the target playback device sends a fetch message to the content server to request a stream of audio content from the content server. Based on this fetch message, in 2085b, the content server streams the audio content to the target playback device for playback. At this time, the target playback device starts playing the audio content at the offset of the audio content.

[0327] FIG. 20C is an exemplary message flow diagram showing commands exchanged between a source playback device, a target playback device, and one or more servers (e.g., a cloud queue server and / or a content server that can be implemented by one or more cloud servers) during another exemplary swap of a playback session. Such messages are representative and can include additional or fewer messages. In some implementations, the messages are sent not from the portable playback device 710 (as the source or target playback device), but from the paired control device 130a (FIG. 7G) or the paired bridge device 860a (FIG. 16A).

[0328] In 2081c, the source playback device starts a playback session. The playback session may be started, among other examples, by the source playback device, the control device 130, or the bridge device 860. In some cases, the playback session can include one or more additional playback devices that play in synchronization with the source playback device as part of a group.

[0329] In 2082c, the source playback device detects a swap trigger, for example, any of the exemplary swap triggers described above, among other examples. In some cases, another device (e.g., the target playback device, the control device 130, the device base 718, or the bridge device 860) detects the swap trigger and sends data indicating that the swap trigger has been detected to the source playback device.

[0330] In 2083b, the source playback device sends playback session data to the target playback device. The playback session data includes one or more identifiers such as a playback session identifier and a queue identifier. The playback session data can also include a URI indicating the source of the audio content and an offset within that content.

[0331] In 2089, the target playback device sends a swap session request to one or more servers. In an implementation of cloud queue, the swap session request may be in the form of a load queue request indicating an instruction to load the current cloud queue state of the cloud queue being played back by the source playback device into the target playback device. To facilitate such a request, the swap session request includes one or more identifiers corresponding to the playback session (e.g., a home identifier, a playback device identifier of the target device, a queue identifier, a playback session identifier).

[0332] Upon receiving the swap session request, one or more servers facilitate the streaming of audio content to the target playback device. For example, one or more servers (content servers) can create a new session on the target playback device, such as by instructing the cloud queue server to create a new session on the target playback device. This request can include a home identifier, an application identifier, and a user account, as well as other identifiers. The playback session data may be used to mirror the playback session of the source playback device in the new session of the target playback device.

[0333] In 2085c, the content server streams audio content to the target playback device for playback. The content service can start the stream at an offset of the audio content. At this time, the target playback device starts playing the audio content at the offset of the audio content.

[0334] In 2086b, after receiving the playback session data, the target playback device transmits an affirmative response message to the source playback device. In an exemplary implementation, the source playback device may not need to stop the playback session until it receives an affirmative response message from the target playback device. The affirmative response message can indicate that the swap was successful.

[0335] In a further example, the source and target playback devices perform the swap by forming a synchronization group. As described above, the exemplary playback device 110 and / or the playback device 710 may dynamically form and transform a synchronization group. As described above, further details regarding audio playback synchronization among playback devices and / or zones can be found, for example, in U.S. Patent No. 8,234,395, entitled "System and method for synchronizing operations among a plurality of independently clocked digital data processing devices", which is hereby incorporated by reference in its entirety.

[0336] In some implementations, the source playback device forms a synchronization group with the target playback device and then mutes its output. Once the synchronization group is formed, the target playback device starts playing the audio content of a given session in synchronization with the source device. To complete the "swap", the source device is muted. From the user's perspective, the playback session appears to be swapped even though both the source and target playback devices are participating in the session. This mute can be a hidden (e.g., system) mute different from the mute command via the user interface. The hidden mute may be performed by lowering the volume or setting the volume to zero on the source device while indicating to the user interface that the source device is not muted and the playback is paused.

[0337] To swap playback to the source playback device, the target playback device is removed from the synchronization group. A possible advantage of this implementation is that the swap can return the session to the source device with relatively little latency since the audio content does not need to be re-buffered. Another possible advantage of this implementation is that the source playback device maintains control of the audio stream.

[0338] In a further example, detecting proximity between the source playback device and the target playback device triggers the swap. For example, detecting that a source playback device and a target playback device of a given swap pair are in proximity can initiate a swap of the playback session between the source playback device and the target playback device. In some implementations, the source and target playback devices for the swap are defined by the proximity between the source playback device and the target playback device. Exemplary proximity detection may be performed in one or more ranges such as proximity to the media playback system 100 (i.e., home or some other known location), proximity to a zone, or proximity to a playback device.

[0339] For example, in some implementations, the proximity of the portable playback device 710 to the media playback system 100 initiates a playback session swap with one or more target playback devices 110 within the home. In the example, when the user returns home with the portable playback device 710, the paired control device 130a (FIG. 7G), or the paired bridge device 860 (FIG. 16A), the proximity of the portable playback device 710 to the media playback system 100 is detected via a sensor or wireless communication interface of the portable playback device 710, the paired control device 130a (FIG. 7G), or the paired bridge device 860 (FIG. 16A). This detection of proximity initiates a playback session swap between the portable playback device 710 and one or more target playback devices 110 within the home.

[0340] To explain, in an exemplary implementation, the paired control device 130a (FIG. 7G) detects a wireless signal indicating the proximity of the portable playback device 710 to the playback device 110. For example, the paired control device 130a (FIG. 7G) can detect (e.g., connect to) an 802.11 network (e.g., network 104) within the home via the network interface 132d. Since the playback devices 110a - n are connected to the network 104, the detection of this network indicates that the paired control device 130a (and, by proxy, the paired portable playback device 710) is in proximity to the home. Other exemplary wireless signals include near - field communication (NFC) and 802.15 (Bluetooth®, Bluetooth® low energy) signals that can be transmitted by the playback devices 110a - n within the home. In other examples, the paired bridge device 860 (FIG. 16A) may detect such signals, or the portable playback device 710 may directly detect the signals via their respective network interfaces.

[0341] Alternatively, the paired control device 130a (FIG. 7G) detects proximity to the playback devices 110a-n via one or more sensors. For example, the paired control device 130a includes a GPS sensor and compares the current GPS coordinates to the stored GPS coordinates of the home (or other known location of the playback devices 110a-n) to determine whether the paired control device 130a is in proximity to the stored location. In a further example, the paired control device 130a can detect proximity by using a microphone to detect ultrasonic tones (or other signals) emitted by one or more of the playback devices 110a-n. Alternatively, the paired control device 130a can utilize a camera to detect known objects or signals within the home. Other examples are possible as well.

[0342] In some examples, verification from the user is required before performing a playback session swap based on proximity. In some examples, the verification is performed via an input to the user interface of the source portable playback device 710 (or the paired control device 130 or bridge device 860a). For example, the verification may be performed by a push notification (or other prompt such as a widget) displayed on the paired control device 130a. To illustrate, FIG. 21A presents a first user interface display 2131a that includes an exemplary push notification 2191a. The paired control device 130a may display the first user interface display 2131a based on detection of proximity to the playback devices 110a-n.

[0343] As shown in FIG. 21A, the push notification 2191a of the first user interface display 2131a includes a plurality of selectable controls. The first selectable control (“swap”) causes the paired control device 130a to execute a playback session swap between the headphones 710a (“Ben's headphones”) and the kitchen 101h, which can be, among other examples, a predefined swap pair (FIG. 11A) or the nearest playback device 110. The second selectable control (“cancel”) cancels the proximity-based swap.

[0344] FIG. 21A also shows selectable controls 2192a and 2193b. The selectable control 2192a causes the kitchen 101h to resume a stopped playback session (e.g., playing a Podcast), rather than transferring the ongoing playback session. In an exemplary embodiment, the selectable control 2192a can represent, among other examples, the last stopped playback session on the portable playback device 710a, the last stopped playback session in the kitchen 101h, or the last stopped playback session in the media playback system 100. Alternatively, the push notification 2191a can include a plurality of selectable controls 2192 for selecting different last stopped playback sessions.

[0345] The selectable control 2193a causes the kitchen 101h to start a new playback session that includes playing a given playlist. In various implementations, an exemplary push notification 2191 can include a selectable control 2193 for starting a new playback session at various storage locations of audio corresponding to the user. For example, each selectable control 2193 can start a new playback session for a favorite playlist, radio station, Podcast, album, or artist, similar to the button 865 (FIG. 16E) and / or the region 1771 (FIG. 17A), among other examples.

[0346] As further shown in FIG. 21A, a third selectable control of the push notification 2191a causes the display of the user interface to present different swap targets. To explain, FIG. 21B presents a second user interface display 2131b to facilitate the selection of swap targets. The user interface display 2131b includes a plurality of toggle controls corresponding to each zone of the media playback system 100 to facilitate the selection of one or more target playback devices 110n.

[0347] In some implementations, proximity to a zone of the portable playback device 710 initiates a playback session swap with a playback device 110 within that zone. Detecting that the portable playback device 710 is in proximity to a given zone may include detecting a signal (e.g., wireless, ultrasonic) emitted by a playback device within that zone. In some implementations, detection of a signal emitted by another smart device within the zone can indicate proximity.

[0348] For example, the paired control device 130a may determine a profile corresponding to one or more zones. For example, while in the kitchen 101h, the paired control device 130a can detect signals emitted by the playback device 110b, as well as other smart devices (e.g., smart oven, smart refrigerator, smart power outlet), and save these signals as markers for the kitchen 101h within the profile corresponding to the kitchen 101h. Also, the paired control device 130a may synthesize this signal data with other sensor data (such as altitude) acquired while in the kitchen 101h. Markers within a given profile can also be weighted (e.g., signals from playback devices in a given zone may be weighted more heavily than signals from other smart devices within that zone).

[0349] When a plurality of stored profiles of the media playback system 100 for a plurality of zones are provided, in order for the portable playback device 710 to detect whether it is close to a given zone, the paired control device 130a can compare the current signal and / or sensor data with the stored profile corresponding to the zone. For example, the paired control device 130a can determine the closest match in the current signal and / or sensor data by comparing how many markers in each profile are present in the current signal and / or sensor data. The paired control device 130a can also set a marker to a threshold by determining proximity to a specific zone when a predetermined number (or percentage) of markers of the stored profile of a specific zone are also present in the current signal and / or sensor data. Although these operations are illustratively described as being performed by the paired control device 130a, other devices such as the portable playback device 710 and / or the bridge device 860 can also determine the profile and / or detect proximity using the stored profile.

[0350] Additional techniques for facilitating determination of zone proximity can be found, for example, in U.S. Patent Application Publication No. 2016 / 0062606 A1, entitled "Zone Recognition", which is hereby incorporated by reference in its entirety.

[0351] Similar to proximity to the home, before performing a playback session swap to a zone based on proximity, the media playback system 100 can request verification that the user intends to perform the swap. To explain, FIG. 21C presents a third user interface display 2131c that includes an exemplary push notification 2191b. The paired control device 130a may display the third user interface display 2131c based on detection of proximity to the den 101d.

[0352] In a further example, proximity to a given zone is determined via user input to the playback device of that zone. For example, a specific user input to playback device 710 (or paired control device 130a or bridge device 860a) can initiate a playback session swap with playback device 710 as the source playback device. Next, a user input to a given playback device 110 selects that playback device (or associated zone) as the target playback device. The source and target playback devices may be configured to perform the swap if a second input is detected within a predetermined period (e.g., 5 seconds) after the first input, in order to indicate proximity between the source and target playback devices.

[0353] In a further example, another trigger such as a button press initiates a playback session swap to a target playback device proximate to the source playback device. To explain, FIG. 22A shows an exemplary playback session swap between portable playback device 710c and playback device 110e proximate to portable playback device 710c. As shown, a specific swap input (e.g., long pressing user interface 713c) triggers the playback session swap. In this example, the source playback device (i.e., portable playback device 710c) is identified via the specific swap input. The target playback device (i.e., playback device 110e) is identified via proximity detection by the portable playback device.

[0354] As another example, FIG. 14B shows an example of a playback session swap between headphones 710a and a playback device 110e proximate to the portable playback device 710a. As shown, a hold-close action triggers the playback session swap. In this example, both the source playback device (i.e., headphones 710a) and the target playback device (i.e., playback device 110e) are identified by the hold-close action, which results in a short-range wireless communication exchange between the headphones 710a and the playback device 110e. Since short-range wireless communication has a limited range (e.g., 4 cm), the short-range wireless communication exchange indicates the proximity of the headphones 710a and the playback device 110e.

[0355] As a further example, FIG. 22C shows an exemplary playback session swap between earbuds 710b and a playback device 110e. In this example, a hold-close action by the control device 130a (paired with the earbuds 710b) triggers the playback session swap. In this example, both the source playback device (i.e., earbuds 710b) and the target playback device (i.e., playback device 110e) are identified by the hold-close action, which results in a short-range wireless communication exchange between the paired control device 130a and the playback device 110e.

[0356] In another example, FIG. 22D shows another example of a playback session swap between earbuds 710b and a playback device 110e. In this example, a hold-close action by the bridge device 860a (paired with the earbuds 710b) triggers the playback session swap. In this example, both the source playback device (i.e., earbuds 710b) and the target playback device (i.e., playback device 110e) are identified by the hold-close action, which results in a short-range wireless communication exchange between the paired bridge device 860a and the playback device 110e.

[0357] In some cases, the target playback device is a member of a synchronization group such as a combined zone (e.g., a stereo pair such as the master bedroom 101b, or a surround sound configuration such as the den 101d) or a zone group (e.g., a zone group of "kitchen + dining room"). As described above, an example of synchronization technology includes the group coordinator providing audio content and timing information to one or more group members to facilitate synchronized playback between the group coordinator and the group members. In such an example, the target playback device may be the group coordinator (which provides audio content and timing information to the group members) or a group member (which receives audio content and timing information from the group coordinator).

[0358] In an exemplary embodiment, when the group coordinator is designated as the target playback device, as a result of the synchronized group arrangement, the group coordinator can automatically "take over" the group members during a playback session swap by providing the group members with audio content and timing information corresponding to the swapped playback session. That is, since the group members receive audio content and timing information from the group coordinator, when the group coordinator starts playing the swapped playback session, the group members also start playing the swapped playback session.

[0359] Generally, when starting a playback session swap via the GUI of control device 130a or the VUI of NMD 120a, the combined zone or zone group is targeted as a whole by referring to the name of the combined zone, zone group, or member zone. In a local implementation, control device 130a or NMD 120a can send one or more messages indicating the playback session swap to the group coordinator, and the group coordinator then executes the swap. In a cloud implementation, control device 130a or NMD 120a can send one or more messages indicating the playback session swap to the cloud queue server to cause the cloud queue server to execute the swap or to relay instructions to the group coordinator to execute the playback session swap.

[0360] In other cases, a group member is the target of the swap (e.g., by providing an input indicating the swap command to the user interface of the group member). In a local implementation, the group coordinator can send one or more messages indicating the swap command to the group coordinator, and then the group coordinator executes the playback session swap. In a cloud implementation, the group member can send one or more messages indicating the playback session swap to the cloud queue server to cause the cloud queue server to execute the swap or to relay instructions to the group coordinator to execute the playback session swap. Alternatively, the group member may send one or more messages indicating the playback session swap to the group coordinator, whereby the group coordinator sends a playback session swap request to the cloud server.

[0361] XI. Examples of Additional Portable Playback Devices FIG. 23A is a front isometric view of earbuds 2310 including earbud 2310a and earbud 2310b configured in accordance with an aspect of the disclosed technology. As shown, earbuds 2300 are carried within charging case 2380.

[0362] FIG. 23B is a bottom view of charging case 2380.

[0363] FIG. 23C is a top view of charging case 2380.

[0364] FIG. 23D is a first side view of charging case 2380.

[0365] FIG. 23E is a second side view of charging case 2380.

[0366] FIG. 23F is a front isometric view of earbud 2310a and earbud 2310b showing an exemplary arrangement with charging case 2380.

[0367] FIG. 23F is an isometric view of earbud 2310a.

[0368] FIG. 23H is a first side view of earbud 2310a.

[0369] FIG. 23I is a second side view of earbud 2310a.

[0370] FIG. 23J is a third side view of earbud 2310a.

[0371] FIG. 23K is a fourth side view of earbud 2310a.

[0372] FIG. 23L is a fifth side view of earbud 2310a.

[0373] FIG. 23M is a sixth side view of earbud 2310a.

[0374] FIG. 24A is a front isometric view of a portable playback device 2410 implemented as a handheld speaker configured according to an aspect of the disclosed technology.

[0375] FIG. 24B is a side view of the portable playback device 2410.

[0376] FIG. 24C is a top view of the portable playback device 2410.

[0377] FIG. 24D is a bottom view of the portable playback device 2410.

[0378] FIG. 24E is a front isometric view of the portable playback device 2410 showing an exemplary arrangement having a device base 2418.

[0379] FIG. 24F is a front isometric view of the portable playback device 2410 showing an exemplary user input to the portable playback device 2410.

[0380] FIG. 25A is a front view of headphones 2510 configured according to an aspect of the disclosed technology.

[0381] FIG. 25B is a first side view of the headphones 2510.

[0382] FIG. 25C is a second side view of the headphones 2510.

[0383] FIG. 26A is a front view of headphones 2610 configured according to an aspect of the disclosed technology.

[0384] FIG. 26B is a first side view of the headphones 2610.

[0385] FIG. 26C is a second side view of the headphones 2610.

[0386] XII. CONCLUSION The above descriptions regarding the portable playback device, playback device, control device, playback zone configuration, and media content source merely show some examples of the operating environments in which the functions and methods described below can be implemented. Other operating environments and configurations of media playback systems, playback devices, and network devices not explicitly described in this specification are also applicable and may be suitable for implementing the functions and methods.

[0387] Among other things, the above description discloses various exemplary systems, methods, devices, and articles of manufacture, including firmware and / or software executed on hardware. It is understood that such examples are merely illustrative and should not be considered limiting. For example, any or all of the aspects or components of firmware, hardware, and / or software may be embodied solely in hardware, solely in software, solely in firmware, or in any combination of hardware, software, and / or firmware. Thus, the examples provided are not the only way to implement such systems, methods, devices, and / or articles of manufacture.

[0388] Furthermore, references to "embodiments" in this specification mean that the particular functions, structures, or features described in connection with the embodiments may be included in at least one exemplary embodiment of the invention. This term appearing in various places in this specification does not necessarily refer to all the same embodiments, nor are separate embodiments or alternative embodiments mutually exclusive of other embodiments. Thus, the embodiments described in this specification can be combined with other embodiments, as will be understood explicitly or implicitly by those skilled in the art.

[0389] This specification is presented broadly from the perspective of exemplary environments, systems, procedures, steps, logical blocks, processes, and other symbolic representations that are directly or indirectly similar to the operation of a data processing device connected to a network. These process descriptions and representations are typically used by those skilled in the art to most effectively convey the substance of their work to other skilled artisans. Many specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be understood by those skilled in the art that specific embodiments of the present disclosure can be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits are not described in detail to avoid unnecessarily obscuring aspects of the embodiments. Accordingly, the scope of the present disclosure is defined by the appended claims rather than by the foregoing description of the embodiments.

[0390] If any of the appended claims is read to cover a pure software and / or firmware implementation, it is explicitly defined herein that at least one of at least one of the elements in at least one instance includes a tangible non-transitory medium such as a memory storing software and / or firmware, a DVD, a CD, a Blu-ray, or the like.

[0391] Example 1: A method, comprising detecting a playback session swap trigger corresponding to a playback session while a first playback device is playing audio content during the playback session, determining (a) one or more source playback devices comprising the first playback device and (b) one or more target playback devices comprising a second playback device, and migrating the playback session from the determined one or more source playback devices to the one or more target playback devices based on the playback session swap trigger.

[0392] Example 2: Transferring a playback session from one or more determined source playback devices to one or more target playback devices includes forming a synchronization group including a first playback device and a second playback device such that the first playback device and the second playback device synchronously play audio content, and muting the first playback device, the method according to Example 1.

[0393] Example 3: Transferring a playback session from one or more determined source playback devices to one or more target playback devices includes sending, to a cloud cue server, an instruction for transferring the playback session from a first playback device to a second playback device, the cloud cue server transferring the playback session to the second playback device based on the instruction, the method according to Example 1 or 2.

[0394] Example 4: Transferring a playback session from one or more determined source playback devices to one or more target playback devices includes sending, to a second playback device, (i) a uniform resource identifier (URI) indicating a source of audio content, and (ii) data representing an offset within the audio content, the second playback device streaming the audio content from the source of the audio content, starting at the offset and playing the audio content, and the first playback device stopping playback of the audio content at the offset, the method according to any of the preceding examples.

[0395] Example 5: The first playback device includes at least one processor; data storage; one or more amplifiers; one or more transducers; one or more batteries configured to drive the one or more amplifiers and the one or more transducers; and one or more housings carrying the at least one processor, the data storage, the one or more amplifiers, the one or more transducers, and the one or more batteries, wherein the one or more housings are formed in at least one of (a) headphones or (b) earbuds, and the method according to any of the preceding embodiments comprising the one or more housings.

[0396] Example 6: The first playback device is paired with a control device via a first type of wireless connection, and the first playback device is connected to a second playback device via the first type of wireless connection and a second type of wireless connection between the control device and the second playback device, and the method according to any of the preceding embodiments.

[0397] Example 7: Detecting a playback session swap trigger includes detecting an input representing a command to swap the playback session via a user interface of the control device, and the method according to any of the preceding embodiments.

[0398] Example 8: Detecting an input representing a command to swap the playback session includes detecting a touch-and-hold input on a touch-sensitive area of the first playback device, and the method according to any of the preceding embodiments, wherein the touch input performs a first action that is not a swap.

[0399] Example 9: Detecting an input representing a command to swap the playback session includes detecting a touch-and-continued-hold input on a touch-sensitive area of the first playback device, and the method according to any of the preceding embodiments, wherein the touch input performs a first action, the touch-and-hold performs a group action, and the first action is not a swap.

[0400] Example 10: The method according to any one of Examples 1 to 5, wherein the first playback device is paired with the bridge device via a first type of wireless connection, and the first playback device is connected to the second playback device via the first type of wireless connection and a second type of wireless connection between the bridge device and the second playback device.

[0401] Example 11: The method according to Example 10, wherein detecting a playback session swap trigger includes detecting an input representing a command for swapping the playback session via a user interface of the bridge device.

[0402] Example 12: The method according to Example 10 or 11, wherein the bridge device comprises a circular housing, and the method includes detecting rotation of the circular housing and adjusting the playback volume of the first playback device in proportion to the rotation.

[0403] Example 13: The method according to any one of Examples 1 to 12, wherein the first playback device comprises at least one processor; data storage; one or more amplifiers; one or more transducers; one or more batteries configured to drive the one or more amplifiers and the one or more transducers; and a housing carrying the at least one processor, the data storage, the one or more amplifiers, the one or more transducers, and the one or more batteries, the housing being formed as a handheld speaker.

[0404] Example 14: The method according to Example 13, wherein detecting a playback session swap trigger includes detecting that the housing is disposed within a device base.

[0405] Example 15: The method according to any preceding embodiment, wherein the second playback device excludes a battery and draws current from wall power.

[0406] Example 16: Detecting a playback session swap trigger comprises detecting the proximity of a second playback device to a first playback device, the method according to any of the preceding embodiments.

[0407] Example 17: Determining one or more target playback devices comprises detecting the proximity of a second playback device to a first playback device, the method according to any of the preceding embodiments.

[0408] Example 18: The one or more target playback devices further comprise a third playback device, and determining the one or more target playback devices further comprises determining that the third playback device is to be configured into a synchronization group with the second playback device, the method according to any of the preceding embodiments.

[0409] Example 19: A system configured to execute the method of any of Examples 1 to 18.

[0410] Example 20: A device configured to execute the method of any of Examples 1 to 18.

[0411] Example 21: A tangible non-transitory computer-readable medium storing instructions executable by one or more processors to execute the method of any of Examples 1 to 18.

[0412] Example 22: A portable playback device comprising at least one processor; a network interface; one or more amplifiers; one or more transducers; one or more batteries configured to drive the one or more amplifiers and the one or more transducers; and one or more housings formed as (a) earbuds or (b) headphones, the one or more housings carrying the at least one processor, the network interface, the one or more amplifiers, the one or more transducers, and the one or more batteries, and the data storage storing instructions executable by one or more processors to execute the method of any of Examples 1 to 18.

[0413] Example 23: A method including a wearable device, the method comprising receiving data representing a first playback session swap input; and based on the received data representing the first playback session swap input, identifying one or more source playback devices within a media playback system that (a) are connected to a first wireless local area network (LAN), and (b) are playing specific audio content in a playback session, wherein the wearable playback device is connected to the first wireless LAN via an 802.11 compliant network interface; and migrating the playback session from the identified one or more source playback devices to the wearable playback device, wherein migrating the playback session includes: (i) forming a first synchronization group including the wearable playback device and the one or more source playback devices, wherein forming the first synchronization group causes the wearable playback device to start playing the specific audio content of the playback session; and (ii) stopping the playback of the specific audio content by the one or more source playback devices.

[0414] Example 24: The method according to Example 23, wherein identifying one or more source playback devices includes identifying a set of playback devices eligible for swap in the media playback system; causing each of the playback devices eligible for swap in the set to emit an audio chirp identifying the playback device eligible for swap; detecting, via one or more microphones, the audio chirps emitted by the one or more playback devices eligible for swap; and selecting one or more source playback devices from among the one or more playback devices eligible for swap based on the audio chirps from the one or more source playback devices indicating that the one or more source playback devices are physically closest to the wearable playback device among the one or more playback devices eligible for swap.

[0415] Example 25: The method according to Example 24, wherein one or more microphones comprise one or more acoustic noise cancellation microphones carried on one or more outer surfaces of one or more wearable housings, and detecting an audio chirp emitted by a playback device eligible for one or more swaps comprises detecting, via the one or more acoustic noise cancellation microphones, an audio chirp emitted by a playback device eligible for one or more swaps.

[0416] Example 26: The method according to any of the preceding Examples 23 to 25, wherein selecting one or more source playback devices from among one or more playback devices eligible for one or more swaps comprises comparing one or more respective metrics of the detected audio chirps emitted by the one or more playback devices eligible for one or more swaps to determine that one or more source playback devices are physically closest to the wearable playback device among the one or more playback devices eligible for one or more swaps.

[0417] Example 27: Receiving data representative of a second playback session swap input while playing audio content in a migrated playback session; identifying one or more target playback devices within a media playback system connected to a first wireless LAN based on the second playback session swap input; and migrating the playback session from the determined one or more target playback devices to the wearable playback device, wherein migrating the playback session further comprises: (i) forming a second synchronization group comprising the wearable playback device and the one or more target playback devices, wherein forming the second synchronization group comprises causing the one or more target playback devices to begin playing a particular audio content of the playback session; and (ii) removing the wearable playback device from the second synchronization group.

[0418] Example 28: A method according to any one of the preceding Examples 23 to 27, wherein one or more wearable housings of the wearable playback device comprise a touch sensing area, and receiving data representing a playback session swap input includes receiving input data representing a touch-and-hold input on the touch sensing area.

[0419] Example 29: A method according to any one of the preceding Examples 23 to 28, wherein receiving data representing a playback session swap input includes receiving data representing an instruction for performing a playback session swap from a controller application of a mobile device via an 802.11 compliant network interface.

[0420] Example 30: A method according to any one of the preceding Examples 23 to 29, wherein stopping the playback of specific audio content on one or more source playback devices includes removing one or more source devices from a synchronization group after forming a synchronization group including the wearable playback device and the one or more source devices.

[0421] Example 31: One or more source devices include a master playback device configured to play multi-channel audio, and migrating a playback session includes: transmitting, via an 802.11 compliant network interface, data representing an instruction to enter a swap mode to the master playback device; transmitting, via an 802.11 compliant network interface, data representing an instruction to enter a swap mode to the master playback device; disconnecting from a first wireless LAN and connecting to a second wireless LAN via an 802.11 compliant network interface; and receiving, via an 802.11 compliant network interface, while connected to the second wireless LAN, (i) playback timing information of a first synchronization group and (ii) data representing multi-channel audio, a method according to any one of the preceding Examples 23 to 30.

[0422] Example 32: A wearable playback device includes one or more network interfaces, where the one or more network interfaces include an 802.11 compliant network interface; one or more transducers; one or more amplifiers configured to drive the one or more transducers; one or more batteries; one or more processors; and one or more wearable housings that carry the one or more network interfaces, the one or more transducers, the one or more amplifiers, the one or more batteries, the one or more processors, and a data storage storing instructions executable by the one or more processors to cause the wearable playback device to execute the method according to any one of Examples 23 to 31.

[0423] Example 33: The method according to Example 32, wherein one or more wearable housings of the wearable playback device are formed in one of (a) headphones or (b) one or more earbuds.

[0424] Example 34: A system configured to execute the method according to any one of Examples 23 to 32. ...

Claims

1. 1. A method comprising: detecting a playback session swap trigger corresponding to a playback session while a first playback device is playing audio content during the playback session; (a) determining one or more source playback devices, the source playback device including the first playback device; (b) determining one or more destination playback devices, the destination playback device including a second playback device; and Migrating the playback session from the determined one or more source playback devices to the one or more target playback devices based on the playback session swap trigger. A method comprising:

2. Migrating the playback session from the determined one or more source playback devices to the one or more target playback devices includes: forming a synchronization group including the first playback device and the second playback device, such that the first playback device and the second playback device synchronously play the audio content; and Muting the first playback device. The method of claim 1 , comprising:

3. Migrating the playback session from the determined one or more source playback devices to the one or more target playback devices includes: sending an instruction to a cloud queue server to transfer the playback session from the first playback device to the second playback device; wherein the cloud queue server transfers the playback session to the second playback device based on the instruction. The method of claim 1 or 2, comprising:

4. Migrating the playback session from the determined one or more source playback devices to the one or more target playback devices includes: sending to the second playback device (i) a uniform resource identifier (URI) indicating a source of the audio content, and (ii) data representing an offset within the audio content; wherein the second playback device streams the audio content from the source of the audio content and plays the audio content starting at the offset, and the first playback device stops playing the audio content at the offset. The method according to any one of claims 1 to 3, comprising:

5. The first playback device is at least one processor; Data storage; one or more amplifiers; one or more transducers; one or more batteries configured to power the one or more amplifiers and the one or more transducers; and one or more housings carrying the at least one processor, the data storage, the one or more amplifiers, the one or more transducers, and the one or more batteries; wherein the one or more housings are formed into at least one of: (a) headphones; or (b) earbuds. The method according to any one of claims 1 to 4, comprising:

6. The method according to any one of claims 1 to 5, wherein the first playback device is paired with a control device via a first type of wireless connection, and the first playback device is connected to the second playback device via the first type of wireless connection and a second type of wireless connection between the control device and the second playback device.

7. Detecting the playback session swap trigger includes: detecting an input via a user interface of the control device representing a command to swap the playback sessions; The method according to any one of claims 1 to 6, comprising:

8. Detecting the input representing the command to swap the playback sessions includes: Detecting a touch-and-hold input on a touch-sensitive area of ​​the first playback device; Note that a single touch input here performs a first action that is not a swap. The method according to any one of claims 1 to 7, comprising:

9. Detecting the input representing the command to swap the playback sessions includes: detecting a touch-and-continued-hold input to a touch-sensitive area of ​​the first playback device; Note that a single touch input executes a first action that is not a swap, and a touch and continued hold executes a group action. The method according to any one of claims 1 to 8, comprising:

10. 6. The method according to claim 1, wherein the first playback device is paired with a bridge device via a first type of wireless connection, and the first playback device is connected to the second playback device via the first type of wireless connection and a second type of wireless connection between the bridge device and the second playback device.

11. Detecting the playback session swap trigger includes: detecting an input via a user interface of the bridge device representing a command to swap the playback sessions; The method of claim 10, comprising:

12. The bridge device comprises a circular housing, and the method further comprises: detecting rotation of the circular housing; and adjusting the playback volume of the first playback device proportional to the rotation. The method of claim 10 or 11, comprising:

13. The first playback device is at least one processor; Data storage; one or more amplifiers; one or more transducers; one or more batteries configured to power the one or more amplifiers and the one or more transducers; and a housing carrying the at least one processor, the data storage, the one or more amplifiers, the one or more transducers, and the one or more batteries, the housing being formed into a handheld speaker. The method according to any one of claims 1 to 12, comprising:

14. Detecting the playback session swap trigger includes: Detecting that the housing is placed within a device base. The method of claim 13, comprising:

15. The method of any preceding claim, wherein the second regeneration device eliminates a battery and draws current from wall power.

16. Detecting the playback session swap trigger includes: Detecting proximity of the second playback device to the first playback device. The method according to any one of claims 1 to 15, comprising:

17. Determining the one or more target playback devices includes: Detecting proximity of the second playback device to the first playback device. The method according to any one of claims 1 to 16, comprising:

18. The one or more target playback devices further comprise a third playback device, and determining the one or more target playback devices further comprises: determining that the third playback device is configured into a synchronization group with the second playback device; The method of any one of claims 1 to 17, further comprising:

19. A system configured to carry out the method according to any of claims 1 to 18.

20. A device configured to carry out the method according to any of claims 1 to 18.

21. 19. A tangible, non-transitory computer readable medium having stored thereon instructions executable by one or more processors to perform the method of any of claims 1 to 18.

22. 1. A portable playback device, comprising: at least one processor; Network interface; one or more amplifiers; one or more transducers; one or more batteries configured to power the one or more amplifiers and the one or more transducers; and one or more housings formed into (a) earbuds or (b) headphones, carrying said at least one processor, said network interface, said one or more amplifiers, said one or more transducers, and said one or more batteries, and a data storage storing instructions executable by the one or more processors to perform a method according to any of claims 1 to 18; A portable playback device comprising:

Images