Playback transition between audio devices

Abstract

To provide a method for transitioning playback sessions between audio devices that facilitates playback continuity when transitioning playback sessions and further reduces a degree of user input (or other user involvement) associated with playback transitions.SOLUTION: A method includes 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 one or more source playback devices including the first playback device and determining one or more target playback devices including a second playback device, and transitioning a playback session from the determined one or more source playback devices to the one or more target playback devices on the basis of the playback session swap trigger.SELECTED DRAWING: Figure 13A

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, entitled "Playback Transitions," filed February 28, 2019, which is 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, or aspects thereof. [Background technology]

[0003] Options for accessing and listening to digital audio in out-loud settings were limited until 2002, when Sonos, Inc. began developing a new type of playback system. Sonos filed one of its first patent applications in 2003, titled "Method for Synchronizing Audio Playback between Multiple Networked Devices," and began selling its first media playback system in 2005. The Sonos Wireless Home Sound System allows people to experience music from many sources through one or more networked playback devices. Through a software control application installed on a controller (e.g., smartphone, tablet, computer, audio input device), people can play the music they want in any room equipped with a networked playback device. Media content (e.g., songs, podcasts, video sounds) is streamed to the playback device, allowing each room equipped with a playback device to play corresponding different media content. It is also possible to group multiple rooms for synchronous playback of the same media content and / or to listen to the same media content synchronously in all rooms. [Brief description of the drawings]

[0004] The features, aspects, and advantages of the technology disclosed herein may be better understood with reference to the following description, the appended claims, and the accompanying drawings, as set forth below. Those skilled in the art will appreciate that the features shown in the drawings are for illustrative purposes and that variations are possible, including different and / or additional features and arrangements thereof. [Figure 1A] 1 is a partial cross-sectional view of an environment including a media playback system configured in accordance with aspects of the disclosed technology. [Figure 1B] 1B is a schematic diagram of the media playback system and one or more networks of FIG. 1A. [Figure 1C] FIG. 2 is a block diagram of a playback device. [Figure 1D] FIG. 2 is a block diagram of a playback device. [Figure 1E] FIG. 2 is a block diagram of a network microphone device. [Figure 1F] FIG. 2 is a block diagram of a network microphone device. [Figure 1G] FIG. 2 is a block diagram of a playback device. [Figure 1H] FIG. 2 is a schematic partial view of a control device. [Figure 1I] 2 is a schematic diagram of a corresponding media playback system zone. [Figure 1J] 2 is a schematic diagram of a corresponding media playback system zone. [Figure 1K] 2 is a schematic diagram of a corresponding media playback system zone. [Figure 1L] 2 is a schematic diagram of a corresponding media playback system zone. [Figure 1M] FIG. 2 is a schematic diagram of a media playback system area. [Figure 2A] FIG. 1 is a front isometric view of a playback device configured in accordance with aspects of the disclosed technology. [Figure 2B] FIG. 3B is a front isometric view of the playback device of FIG. 3A without the grill. [Figure 2C] FIG. 2B is an exploded view of the playback device of FIG. 2A. [Figure 3A] 1 is a front view of a network microphone device configured in accordance with aspects of the disclosed technology. [Figure 3B] FIG. 3B is a side isometric view of the network microphone device of FIG. 3A. [Figure 3C] FIG. 3C is an exploded view of the network microphone device of FIGS. 3A and 3B. [Figure 3D] FIG. 3C is an enlarged view of a portion of FIG. 3B. [Figure 4A] 1A-1C are schematic diagrams of a control device at various stages of operation in accordance with aspects of the disclosed technology; [Figure 4B]1A-1C are schematic diagrams of a control device at various stages of operation in accordance with aspects of the disclosed technology; [Figure 4C] 1A-1C are schematic diagrams of a control device at various stages of operation in accordance with aspects of the disclosed technology; [Figure 4D] 1A-1C are schematic diagrams of a control device at various stages of operation in accordance with aspects of the disclosed technology; [Diagram 5] FIG. 2 is a front view of the control device. [Figure 6] FIG. 2 is a message flow diagram of the media playback system. [Figure 7A] 1 is a partial cutaway view of an environment having a media playback system configured in accordance with aspects of the disclosed technology. [Figure 7B] FIG. 1 is a block diagram of a portable playback device configured in accordance with aspects of the disclosed technology. [Figure 7C] FIG. 1 is a front isometric view of a portable playback device implemented as headphones configured in accordance with aspects of the disclosed technology. [Figure 7D] FIG. 1 is a front isometric view of a portable playback device implemented as earbuds configured in accordance with aspects of the disclosed technology. [Figure 7E] FIG. 1 is a front isometric view of a portable playback device configured in accordance with aspects of the disclosed technology. [Figure 7F] FIG. 1 is a front isometric view of a portable playback device having a device base configured in accordance with aspects of the disclosed technology. [Figure 7G] FIG. 2 is a schematic diagram illustrating an exemplary pairing configuration between a portable playback device and a control device. [Figure 8A] FIG. 1 is a schematic diagram illustrating an example push swap in accordance with aspects of the disclosed technology. [Figure 8B] FIG. 1 is a schematic diagram illustrating an example pull swap in accordance with aspects of the disclosed technology. [Figure 8C] FIG. 1 is a schematic diagram illustrating an example push swap in accordance with aspects of the disclosed technology. [Figure 9]FIG. 1 is a schematic diagram illustrating an exemplary voice-based identification technique in accordance with aspects of the disclosed technology. [Figure 10] FIG. 1 is a schematic diagram illustrating an exemplary control scheme in accordance with aspects of the disclosed technology. [Figure 11] FIG. 1 is a schematic diagram illustrating an example feedback technique in accordance with aspects of the disclosed technology. [Figure 12A] FIG. 13 is an exemplary messaging diagram to illustrate an exemplary playback session swap technique. [Figure 12B] FIG. 13 is an exemplary messaging diagram to illustrate an exemplary playback session swap technique. [Figure 13A] FIG. 1 is a method flow diagram illustrating an exemplary swap pull technique in accordance with aspects of the disclosed technology. [Figure 13B] FIG. 1 is a method flow diagram illustrating an exemplary swap push technique in accordance with aspects of the disclosed technology. [Figure 14] FIG. 1 is a method flow diagram illustrating an exemplary home theater swap technique in accordance with an aspect of the disclosed technology. [Figure 15] FIG. 1 is a method flow diagram illustrating a technique for facilitating playback session swapping in accordance with an aspect of the disclosed technology. [Figure 16A] 1 is a schematic diagram illustrating an exemplary pairing configuration between a portable playback device and a bridge device. [Figure 16B] FIG. 1 is a block diagram of a bridge device configured in accordance with an aspect of the disclosed technology. [Figure 16C] FIG. 1 is a front isometric view of a bridge device configured in accordance with aspects of the disclosed technology. [Figure 16D] 1 is a diagram of a touch sensitive area implemented in a bridge device configured in accordance with aspects of the disclosed technology. [Figure 16E] FIG. 1 is a front view of a bridge device configured in accordance with aspects of the disclosed technology. [Figure 17A] 1 is a schematic diagram of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17B]1 is a schematic diagram of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17C] 1 is a schematic diagram of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17D] 1 is a schematic diagram of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17E] 1 is a schematic diagram of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17F] 1 is a schematic diagram of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 18A] FIG. 2 is a diagram of an exemplary arrangement between a bridge device and a device base. [Figure 18B] A diagram of an exemplary arrangement between a portable playback device, a bridge device, and a device base. [Figure 18C] A diagram of an exemplary arrangement between a first portable playback device, a bridge device, a second portable playback device, and a device base. [Figure 19A] 1A-1C are schematic diagrams of a control device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 19B] 1A-1C are schematic diagrams of a control device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 19C] 1A-1C are schematic diagrams of a control device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 20A] FIG. 13 is an exemplary messaging diagram to illustrate an exemplary playback session swap technique. [Figure 20B] FIG. 13 is an exemplary messaging diagram to illustrate an exemplary playback session swap technique. [Figure 20C] FIG. 13 is an exemplary messaging diagram to illustrate an exemplary playback session swap technique. [Figure 21A] 1A-1C are schematic diagrams of a control device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 21B] 1A-1C are schematic diagrams of a control device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 21C] 1A-1C are schematic diagrams of a control device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 22A] FIG. 1 illustrates an example proximity-based playback session swap. [Figure 22B] FIG. 1 illustrates an example proximity-based playback session swap. [Figure 22C] FIG. 1 illustrates an example proximity-based playback session swap. [Figure 22D] FIG. 1 illustrates an example proximity-based playback session swap. [Figure 23A] FIG. 1 is a front isometric view of an earbud constructed in accordance with aspects of the disclosed technology. [Figure 23B] FIG. 1 is a bottom view of a charging case configured in accordance with aspects of the disclosed technology. [Figure 23C] FIG. 2 is a top view of the charging case. [Figure 23D] FIG. 2 is a first side view of the charging case. [Figure 23E] FIG. 2 is a second side view of the charging case. [Figure 23F] FIG. 2 is a front isometric view of the earbuds showing an exemplary arrangement with a charging case. [Figure 23G] FIG. 2 is an isometric view of the earbud. [Figure 23H] FIG. 2 is a first side view of the earbud. [Figure 23I] FIG. 2 is a second side view of the earbud. [Figure 23J] FIG. 4 is a third side view of the earbud. [Figure 23K] FIG. 4 is a fourth side view of the earbud. [Figure 23L] FIG. 5 is a fifth side view of the earbud. [Figure 23M] FIG. 6 is a sixth side view of the earbud. [Figure 24A] FIG. 1 is a front isometric view of a portable playback device implemented as a handheld speaker configured in accordance with aspects of the disclosed technology. [Figure 24B] FIG. 2 is a side view of a portable playback device. [Figure 24C] FIG. 2 is a top view of a portable playback device. [Figure 24D] FIG. 2 is a bottom view of the portable playback device. [Figure 24E] FIG. 1 is a front isometric view of a portable playback device showing an exemplary arrangement with a device base. [Figure 24F] FIG. 2 is a front isometric view of a portable playback device showing exemplary user inputs to the portable playback device. [Figure 25A] FIG. 1 is a front view of a headphone configured in accordance with aspects of the disclosed technology. [Figure 25B] FIG. 2 is a first side view of the headphones. [Figure 25C] FIG. 2 is a second side view of the headphones. [Figure 26A] FIG. 1 is a front view of a headphone configured in accordance with aspects of the disclosed technology. [Figure 26B] FIG. 2 is a first side view of the headphones. [Figure 26C] 2 is a second side view of the headphones. Although the drawings are intended to illustrate some exemplary embodiments, it will be understood by those skilled in the art that the technology disclosed herein is not limited to the arrangements and instrumentality shown in the drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] I. Overview Exemplary techniques described herein relate to transitioning playback sessions 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 transitioning playback sessions between portable (e.g., battery-powered, transportable) playback devices and playback devices of a zone-based media playback system. Such transitions are referred to herein as "swaps" or "playback session swaps." Such exemplary swapping techniques facilitate playback continuity when transitioning between locations (e.g., from home to on-the-go or vice versa) or listening paradigms (e.g., personal or out-of-the-box). Additionally, some exemplary techniques may reduce the degree of user input (or other user involvement) involved in playback transitions compared to some other techniques.

[0006] In an illustrative example, a user initiates a playback session on an illustrative headphone while on the go. For example, the user begins listening to KEXP Seattle using earbuds paired with a mobile device (e.g., a smartphone) over 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] Upon returning home, the user may wish to continue listening to KEXP Radio with audio. To initiate a playback session swap from the earbud to a playback device in the kitchen, the user may provide an input to the earbud. Since the earbud continues the playback session, this input designates the earbud as the source of the playback session swap. The target of the swap (i.e., the kitchen zone) may be pre-specified with a given swap pair with the earbud, or may be determined after the input using proximity detection techniques such as audio chirps, as described in more detail herein. The earbud and / or mobile device perform a playback session swap with the kitchen zone, and playback of KEXP Radio continues to audio continuously on the playback device in the kitchen.

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

[0009] While the curated meditation playlist is playing, the user's friend walks into the living room and suggests 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 the handheld speaker, the friend holds the smartphone near the handheld speaker to initiate 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 performs a playback session swap with the handheld speaker, and playback of the Childish Gambino track continues audibly uninterrupted on the handheld speaker.

[0010] To enjoy Childish Gambino tracks with a more powerful amplifier and / or larger transducer, the user initiates a playback session swap from the handheld speaker to the living room playback device by providing an input to 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 performs a playback session swap with the living room zone, and playback of Childish Gambino tracks continues uninterrupted at volume on the playback device in the living room.

[0011] In a third illustrative example, in the evening, a user may initiate a playback session in the bedroom on a soundbar device that is playing audio content from a television. Wanting to continue with the volume turned down so as not to disturb a partner who is trying to get an infant to sleep in an adjacent room, the user initiates a playback session swap from the soundbar device to a handheld speaker that the user has placed on the nightstand. Because the handheld speaker is physically closer to the user, the user can comfortably hear the audio from the television at a lower volume level.

[0012] After putting the baby to bed, the partner comes into the bedroom to find the user asleep. To initiate a playback session swap from the handheld speaker to the paired headphones, the partner may provide input to the headphones. This input specifies the headphones as the target of the playback session swap. The source of the swap (i.e., the handheld speaker) is determined based on the context (i.e., based on the active playback session). The handheld speaker performs a playback session swap with the headphones, and TV audio continues playing uninterrupted at volume on the headphones.

[0013] As mentioned above, the example techniques described herein include a playback session swap. An example implementation includes 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] Although some examples described herein may refer to functions performed by certain actors, such as "users," "listeners," and / or other entities, it should be understood that this is for purposes of illustration only, and the claims should not be construed as requiring action by such example actors unless expressly required by the language of the claims themselves.

[0015] Additionally, certain functions are described herein as being performed "based on" or "in response to" another element or function. "Based on" should be understood to mean that one element or function is related to another function or element. "In response to" should be understood to mean that one element or function is the necessary result of another function or element. For brevity, functions are generally described as being based on another function when a functional link exists. However, such disclosure should be understood as disclosing any type of functional relationship.

[0016] In the figures, identical reference numbers identify generally 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 are merely illustrative of particular embodiments of the disclosed technology. Thus, other embodiments can have other details, dimensions, angles, and features without departing from the spirit or scope of the present disclosure. Moreover, those skilled in the art will appreciate that further embodiments of the disclosed various technologies can be practiced without some of the details described below.

[0017] II. Optimal Operating Environment 1A is a partial cross-sectional view of a media playback system 100 disposed in an environment 101 (e.g., a home). 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" may generally refer to a network device configured to receive, process, and output data for a media playback system. For example, a playback device may be a network device configured to receive and process audio content. In some embodiments, a playback device includes one or more transducers or speakers powered by one or more amplifiers. However, in other embodiments, a playback device includes either a speaker and an amplifier (or neither). For example, a playback device may include one or more amplifiers configured to drive one or more speakers external to the playback device via corresponding wires or cables.

[0019] Additionally, as used herein, the term NMD (i.e., "network microphone device") may generally refer to a network device configured for audio detection. In some embodiments, the NMD is a standalone device configured primarily for audio detection. In other embodiments, the NMD is integrated into a playback device (or vice versa).

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

[0021] Each of the playback devices 110 is configured to receive audio signals 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 signals or data as sound. One or more of the NMDs 120 are configured to receive spoken word commands, and one or more of the control devices 130 are configured to receive user input. In response to the received spoken word commands 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 an associated trigger condition (e.g., detection of a user's presence in the kitchen, operation of a coffee machine) is detected. In some embodiments, for example, 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 playback device 110, NMD 120, and / or control device 130 of 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, environment 101 comprises a home having multiple rooms, spaces, and / or playback zones, including (clockwise from top left) master bathroom 101a, master bedroom 101b, second bedroom 101c, family room or den 101d, office 101e, living room 101f, dining room 101g, kitchen 101h, and outdoor patio 101i. Although certain embodiments and examples are described below in the context of a home environment, the techniques described herein may be implemented in other types of environments. In some embodiments, for example, media playback system 100 may be implemented in one or more commercial facilities (e.g., restaurants, malls, airports, hotels, retail stores or other businesses), one or more vehicles (e.g., sport utility vehicles, buses, automobiles, ships, boats, airplanes), multiple environments (e.g., a combination of home and vehicle environments), and / or another suitable environment where multi-zone audio may be desirable.

[0023] The media playback system 100 may be configured with one or more playback zones, some of which may correspond to rooms in the environment 101. The media playback system 100 may be formed with one or more playback zones, and then additional zones may be added or removed to form, for example, the configuration shown in FIG. 1A. Each zone may be given a name according 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 embodiments, a single playback zone may include multiple rooms or spaces. In certain embodiments, 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 multiple 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 multiple playback devices 110, as a combined playback zone, as an integrated playback device, and / or 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 multiple 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-1M.

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

[0026] a. Preferred Media Playback System 1B is a schematic diagram of a media playback system 100 and a cloud network 102. For ease of illustration, certain devices of the media playback system 100 and the cloud network 102 are omitted from FIG. 1B. One or more communication links 103 (hereinafter "links 103") are provided that communicatively couple the media playback system 100 and the cloud network 102.

[0027] Link 103 may comprise, 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 communications networks (e.g., one or more Global System For Mobiles (GSM) networks, Code Division Multiple Access (CDMA) networks, Long-Term Evolution (LTE) networks, 5G communications networks, and / or other suitable data transmission protocol networks), etc. Cloud network 102 is configured to deliver media content (e.g., audio content, video content, photos, social media content) to media playback system 100 in response to requests sent from media playback system 100 via link 103. In some embodiments, cloud network 102 is further configured to receive data (e.g., voice input data) from media playback system 100 and, in response, send commands and / or media content to media playback system 100.

[0028] Cloud network 102 is comprised of computing devices 106 (individually identified as a first computing device 106a, a second computing device 106b, and a third computing device 106c). Computing devices 106 may comprise individual computers or servers, such as media streaming service servers that store audio and / or other media content, voice service servers, social media servers, media playback system control servers, etc. In some embodiments, one or more of computing devices 106 comprise modules of a single computer or server. In particular embodiments, one or more of computing devices 106 comprise one or more modules, computers, and / or servers. Furthermore, while cloud network 102 has been described above in the context of a single cloud network, in some embodiments, cloud network 102 comprises multiple cloud networks comprising communicatively connected computing devices. Furthermore, while in FIG. 1B cloud network 102 is depicted as having three computing devices 106, in some embodiments cloud network 102 comprises fewer (or more) than three computing devices 106.

[0029] The media playback system 100 is configured to receive media content from the network 102 via the link 103. The received media content may be comprised of, for example, a Uniform Resource Identifier (URI) and / or a Uniform Resource Locator (URL). For example, in some examples, the media playback system 100 may stream, download, or otherwise obtain data from a URI or URL corresponding to the received media content. The network 104 communicatively couples the link 103 with at least some of the devices of the media playback system 100 (e.g., one or more of the playback device 110, the NMD 120, and / or the control device 130). The network 104 may include, for example, a wireless network (e.g., a WiFi network, Bluetooth, Z-Wave network, ZigBee, and / or other suitable wireless communication protocol network) and / or a wired network (e.g., a network consisting of Ethernet, Universal Serial Bus (USB), and / or other suitable wired communication). As used herein, and as would be understood by one of ordinary skill in the art, "WiFi" can refer to a number of different communication protocols, including, for example, 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, and the like, transmitted at 2.4 gigahertz (GHz), 5 GHz, and / or another suitable frequency.

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

[0031] However, in other embodiments, network 104 comprises an existing home communications network (e.g., a home WiFi network). In some embodiments, link 103 and network 104 comprise one or more of the same network. In some aspects, for example, link 103 and network 104 comprise a communications network (e.g., an LTE network, a 5G network). Furthermore, in some embodiments, media playback system 100 is implemented without network 104, and devices comprising media playback system 100 can communicate with each other, for example, via one or more direct connections, PANs, communications networks, and / or other suitable communications links.

[0032] In some embodiments, audio content sources may be periodically added or removed from media playback system 100. In some embodiments, for example, media playback system 100 performs media item indexing when one or more media content sources are updated, added, and / or removed from media playback system 100. Media playback system 100 may scan for identifiable media items in some or all folders and / or directories accessible to playback device 110 and generate or update a media content database that includes metadata (e.g., title, artist, album, track length) and other associated 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 playback device 110, network microphone device 120, and / or control device 130.

[0033] In the illustrated embodiment of FIG. 1B, the playback devices 110l, 110m constitute the group 107a. The playback devices 110l, 110m may be located in different rooms in a home and may be temporarily or permanently grouped into the group 107a based on user input received at the control device 130a and / or another control device 130 of the media playback system 100. Once arranged in the group 107a, the playback devices 110l, 110m may be configured to synchronously play the same or similar audio content from one or more audio content sources. In certain embodiments, for example, the group 107a includes a combining zone where the playback devices 110l, 110m respectively constitute the left and right audio channels of a multi-channel audio content, thereby creating or enhancing a stereo effect of the audio content. In some embodiments, the group 107a further includes the playback device 110. However, in other embodiments, the media playback system 100 omits the group 107a and / or other grouped arrangements of the playback devices 110. Further details regarding the arrangement of groups and other playback devices are described below with reference to Figures 1-I-IM.

[0034] The media playback system 100 includes NMDs 120a and 120d having one or more microphones configured to receive voice utterances from a user. In the illustrated embodiment of FIG. 1B, the NMD 120a is a standalone device and the NMD 120d is integrated into the playback device 110n. The NMD 120a is configured to receive voice input 121, for example, from a user 123. In some embodiments, the NMD 120a 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) transmit 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®). Computing device 106c may receive audio input data from NMD 120a via network 104 and link 103. In response to receiving the audio input data, computing device 106c processes the audio input data (e.g., "Play Hey Jude by The Beatles") and determines that the processed audio input includes a command to play a song (e.g., "Hey Jude"). Computing device 106c responsively transmits a command to media playback system 100 from an appropriate media service (e.g., via one or more of computing devices 106) to play "Hey Jude" by The Beatles on one or more of playback devices 110.

[0035] b. Preferred playback device 1C is a block diagram of a playback device 110a including 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 an audio line-in input connection, for example, constituting an auto-detecting 3.5mm 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®) interface and / or cable. In some embodiments, Digital I / O 111b includes one or more wireless communication links, e.g., comprising radio frequency (RF), infrared, WiFi, Bluetooth, or other suitable communication protocols. In certain embodiments, Analog I / O 111a and Digital 111b include interfaces (e.g., ports, plugs, jacks) that do not necessarily include cables but are configured to receive connectors of cables carrying analog and digital signals, respectively.

[0036] The playback device 110a may receive media content (e.g., audio content consisting of music and / or other sounds) from a local audio source 105, for example, via an input / output 111 (e.g., a cable, wired, wired, PAN, Bluetooth® connection, an ad-hoc wired or wireless communication network, and / or another suitable communication link). The local audio source 105 may 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 phonograph, a Blu-ray player, a memory that stores digital media files). In some aspects, the local audio source 105 comprises 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 omits the local audio source 105 entirely. In some embodiments, the playback device 110 a does not include an input / output 111 and receives all audio content over the network 104 .

[0037] The playback device 110a further includes electronics 112, a user interface 113 (e.g., one or more buttons, knobs, dials, touch-sensitive surfaces, displays, touch screens), and one or more transducers 114 (hereinafter referred to as “transducers 114”). The electronics 112 is configured to receive audio from an audio source (e.g., local audio source 105) via input / output 111, 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, a microphone array) (hereinafter referred to as “microphones 115”). In certain embodiments, for example, a playback device 110a having an optional one or more microphones 115 can operate as an NMD configured to receive audio input from a user and perform one or more corresponding operations based on the received audio input.

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

[0039] The processor 112a may comprise a clocked computing component configured to process data, and the memory 112b may include a computer-readable medium (e.g., a tangible, non-transitory computer-readable medium, a data storage device loaded with one or more of the software components 112c) configured to store instructions for performing various operations and / or functions. The processor 112a is configured to execute the instructions stored in the memory 112b to direct one or more operations. The instructions may include, for example, causing the playback device 110a to obtain audio data from an audio source (e.g., one or more of the computing devices 106a-c (FIG. 1B)) and / or to obtain audio data of another one of the playback devices 110. In some embodiments, the instructions may further include causing the playback device 110a to transmit the audio data to another one of the playback devices 110a and / or to another device (e.g., one of the NMDs 120). In certain embodiments, the playback device 110a further includes instructions that cause the playback device 110a to pair with one or more other playback devices 110 to enable a multi-channel audio environment (e.g., stereo pair, combined zones).

[0040] The processor 112a may be further configured to execute instructions that cause the playback device 110a to synchronize playback of the audio content with another of the one or more playback devices 110. As one skilled in the art would appreciate, during synchronized playback of audio content on multiple playback devices, a listener would preferably be unable to perceive a time difference between the playback of the audio content by the playback device 110a and the playback of the 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, 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 playback queues with which the playback device 110a (and / or another of the one or more playback devices) is associated. The stored data may include one or more state variables that are periodically updated and used to describe the state of the playback device 110a. The memory 112b may 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 among at least some of the devices of the media playback system 100 at predetermined intervals (e.g., every 5 seconds, every 10 seconds, every 60 seconds) such that one or more of the devices have up-to-date 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 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-transient 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 parse the digital packet data such that the electronic device 112 appropriately receives and processes the data intended for the playback device 110a.

[0043] In the illustrated embodiment of FIG. 1C, the 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 the other playback devices 110, the NMD 120, and / or the control device 130) communicatively coupled to the network 104 (FIG. 1B) according to a suitable wireless communication protocol (e.g., WiFi, Bluetooth, LTE). In some embodiments, the network interface 112d optionally includes a wired interface 112f (e.g., an interface or receptacle configured to receive a network cable such as an 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, the network interface 112d includes the wired interface 112f and excludes the wireless interface 112e. In some embodiments, the electronic device 112 omits the network interface 112d entirely and transmits and receives media content and / or other data via another communication path (eg, input / output 1111).

[0044] The audio processing component 112g is configured to process and / or filter data constituting 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-to-analog converters (DACs), audio pre-processing 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 may include one or more subcomponents 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 to generate the output audio signal.

[0045] The amplifier 112h is configured to receive and amplify the audio output signal generated by the audio processing component 112g and / or the processor 112a. The amplifier 112h may include electronic devices and / or components 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., a linear gain power amplifier, a class A amplifier, a class B amplifier, a class AB amplifier, a class C amplifier, a class D amplifier, a class E amplifier, a class F amplifier, a class G amplifier, and / or a class H amplifier, 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. Furthermore, in some embodiments, each amplifier 112h corresponds to each transducer 114. However, in other embodiments, the electronics 112 includes one amplifier 112h configured to output an amplified audio signal to the multiple transducers 114. In some other embodiments, the electronics 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 may comprise a single transducer. However, in other embodiments, the transducer 114 comprises multiple audio transducers. In some embodiments, the transducer 114 comprises one or more types of transducers. For example, the transducer 114 may include one or more low-frequency transducers (e.g., subwoofer, woofer), a mid-frequency transducer (e.g., mid-range transducer, mid-woofer), and one or more high-frequency transducers (e.g., one or more tweeters). As used herein, "low frequency" can generally refer to audio frequencies below about 500 Hz, "mid-range frequency" can generally refer to audio frequencies between about 500 Hz and about 2 kHz, and "high frequency" can generally refer to audio 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 mid-woofer transducer configured to output sound at frequencies between about 200 Hz and about 5 kHz.

[0047] For purposes of illustration, Sonos Incorporated currently offers (or has offered) certain playback devices for sale, 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. Moreover, one of ordinary skill in the art will appreciate that the playback devices are not limited to the exemplary embodiments described herein or to the Sonos product offerings. 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 earbuds). 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 integral with another device or component, such as a television, a lighting fixture, or some other device for indoor or outdoor use. 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 includes input / output 111 and electronics 112, but does not include user interface 113 or transducer 114.

[0048] FIG. 1E is a block diagram of a combined playback device 110q comprising a playback device 110q (FIG. 1C) that sonically couples a playback device 110a (FIG. 1C) with a playback device 110i (e.g., a subwoofer) (FIG. 1A). In the illustrated embodiment, the playback devices 110a and 110i are separate playback devices 110 housed in separate enclosures. However, in some embodiments, the combined playback device 110q comprises a single enclosure that houses both playback devices 110a and 110i. The combined playback device 110q can be configured to process and play sounds differently than the non-coupled playback devices (e.g., playback device 110a of FIG. 1C) and / or the 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 mid- and high-frequency components of a particular audio content when combined with a first playback device, and playback device 110i is configured to render low-frequency components 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 more detail below with respect to FIGS. 2A-3D.

[0049] c. Suitable Network Microphone Device (NMD) FIG. 1F is a block diagram of NMD 120a (FIGS. 1A and 1B). NMD 120a includes one or more audio processing components 124 (hereinafter "audio components 124") and the components described with respect to playback device 110a (FIG. 1C), including processor 112a, memory 112b, and microphone 115. NMD 120a optionally includes other components also included in playback device 110a (FIG. 1C), such as user interface 113 and / or transducer 114. In some embodiments, NMD 120a 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, NMD 120a 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, NMD 120a includes only microphone 115, audio processing 124, and some of the components of electronics 112 described above with respect to FIG. 1B. In some embodiments, for example, NMD 120a includes processor 112a and memory 112b (FIG. 1B), while omitting one or more other components of electronics 112. In some embodiments, NMD 120a includes additional components (e.g., one or more sensors, a camera, a thermometer, a barometer, a hygrometer).

[0050] In some embodiments, the NMD can be incorporated into the playback device. FIG. 1G is a block diagram of a playback device 110r that includes 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 a user interface (e.g., the user interface 113 of FIG. 1B) that is configured, for example, 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 acquire, capture, and / or receive sounds from the environment (e.g., environment 101 of FIG. 1A) and / or the room in which the NMD 120a is located. The received sounds may include, for example, vocalizations, audio played by the NMD 120a and / or another playback device, background voices, environmental sounds, etc. The microphone 115 converts the received sounds into electrical signals to generate microphone data. The audio processing 124 receives and analyzes the microphone data to determine whether audio input is present in the microphone data. The audio input may consist of, for example, an activation word followed by an activation word that includes a user request. As will be appreciated by those skilled in the art, an activation word is a word or other audio cue that signifies a user's voice input. For example, when querying the AMAZON® VAS, a user may speak the activation word "Alexa." Other examples include "OK, Google" to invoke the GOOGLE VAS and "Hey, Siri" to invoke the APPLE VAS.

[0052] After detecting the activation word, the voice processing 124 monitors the microphone data for a user request accompanying the voice input. The user request may include, for example, a command to control a network-enabled device such as a thermostat (e.g., a NEST® thermostat), a lighting device (e.g., a PHILIPS HUE® lighting device), or a media playback device (e.g., a Sonos® playback device). For example, a user may speak the activation word "Alexa" followed by "set the thermostat to 68 degrees" to set the temperature in a home (e.g., environment 101 of FIG. 1A). The user may speak the same activation word followed by "turn on the living room" to turn on lighting devices in the living room area of ​​the home. The user may similarly speak an activation word followed by a request to play a particular song, album, or playlist of music on a playback device in the home. Receiving and processing of voice input data is described in more detail with reference to FIGS. 3A-3F.

[0053] d. Suitable Control Device FIG. 1H is a partial schematic diagram 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 associated with media playback system 100 and, in response, cause one or more devices in media playback system 100 to perform an action or operation corresponding to the user input. In the illustrated embodiment, control device 130a comprises a smartphone (e.g., iPhone®, Android phone) having media playback system controller application software installed. In some embodiments, control device 130a comprises, for example, a tablet (e.g., iPad®), a computer (e.g., laptop computer, desktop computer), and / or other suitable device (e.g., television, automobile audio head unit, 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 in media playback system 100 (e.g., one or more of playback device 110, NMD 120, and / or other suitable devices configured to communicate over a network).

[0054] The control device 130a includes electronics 132, a user interface 133, one or more speakers 134, and one or more microphones 135. The electronics 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 perform functions related to facilitating access, control, and configuration of the media playback system 100 by a user. The memory 132b can include data storage into which one or more software components executable by the processor 302 can be loaded to perform 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] The network interface 132d is configured to facilitate network communication between the control device 130a and one or more other devices in the media playback system 100 and / or one or more remote devices. In some embodiments, the network interface 132 is configured to operate according to one or more appropriate 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). The network interface 132d can be configured to transmit and / or receive data to, for example, the playback device 110, the NMD 120, others of the control device 130, one of the computing devices 106 of FIG. 1B, one or more other devices constituting the media playback system, etc. The transmitted and / or received data can include, for example, control commands, state variables, playback zone and / or zone group configurations of the playback device. For example, based on user input received at user interface 133, network interface 132d can send 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 send and / or receive configuration changes, such as, for example, adding / removing one or more playback devices 100 to a zone, adding / removing one or more zones to a zone group, forming a combined or unified player, separating one or more playback devices from a combined or unified player, etc. Further details about zones and groups are shown in Figures 1-I-1M.

[0056] The user interface 133 is configured to receive user input and can facilitate control of the media playback system 100. The user interface 133 includes media content art 133a (e.g., album art, lyrics, video), playback status indicators 133b (e.g., elapsed and / or remaining time indicators), media content information area 133c, playback control area 133d, and zone indicators 133e. The media content information area 133c can include a display of relevant information (e.g., title, artist, album, genre, year of release) regarding the currently playing media content and / or media content in a queue or playlist. The playback control area 133d can include selectable (e.g., via touch input and / or via a cursor or another suitable selector) icons for causing one or more playback devices in a selected playback zone or zone group to perform playback actions, such as, for example, play or pause, fast forward, rewind, skip next, skip previous, enter / exit shuffle mode, enter / exit repeat mode, enter / exit crossfade mode, etc. Playback control area 133d may also include selectable icons for changing equalization settings, playback volume, and / or other suitable playback behavior. In the illustrated embodiment, user interface 133 comprises a display presented on a touchscreen interface of a smartphone (e.g., iPhone, 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 equal control access to the media playback system.

[0057] One or more speakers 134 (e.g., one or more transducers) may be configured to output sounds to a user of the control device 130a. In some embodiments, the one or more speakers comprise individual transducers configured to correspondingly output low, mid, 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 may 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, the two or more microphones 135 are positioned to capture location information of an audio source (e.g., voice, audible sound) and / or are configured to facilitate filtering of background noise. Furthermore, 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 comprise a device (e.g., a thermostat, an IoT device, a network device) that includes a portion of the electronics 132 and a user interface 133 (e.g., a touch screen) while omitting a speaker or microphone. Additional control device embodiments are described in further detail below with respect to FIGS. 4A-4D and 5.

[0059] e. Proper playback device configuration 1-1 to 1M show exemplary configurations of playback devices in zones and zone groups. First referring to FIG. 1M, in one example, a single playback device can belong to a zone. For example, playback device 110g in second bedroom 101c (FIG. 1A) may belong to zone C. In some implementations described below, multiple playback devices can be "combined" to form a "combined pair," which together form a single zone. For example, playback device 110l (e.g., left playback device) can be combined with playback device 110j (e.g., left playback device) to form zone A. The combined playback devices may have different playback responsibilities (e.g., channel responsibilities). In another implementation described below, multiple playback devices can be merged to form a single zone. For example, playback device 110h (e.g., front playback device) can be merged with playback device 110i (e.g., subwoofer) and playback devices 110j and 110k (e.g., left and right surround speakers, respectively) to form a single zone D. In another example, playback devices 110g and 110h may 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, apart from playing audio content synchronously, the merged playback devices 110h and 110i may each play audio content as if they were not merged.

[0060] Each zone in 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 may have different playback responsibilities, such as responsibility for a particular audio channel. For example, as shown in FIG. 1-I, playback devices 110l and 110m may be combined to generate or enhance a stereo effect for audio content. In this example, playback device 110l may be configured to play a left channel audio component, while playback device 110k may be configured to play a right channel audio component. In some implementations, such a stereo combination may be referred to as "pairing."

[0062] Further, 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 may be configured to render a range of mid-to-high frequencies, and the Sub device 110i may be configured to render low frequencies. However, when not combined, the Front device 110h may be configured to render a full range of frequencies. As another example, FIG. 1K shows the Front device 110h and the Sub device 110i further combined with the Left playback device 110j and the Right playback device 110k, respectively. In some implementations, the Right device 110j and the Left device 102k may be configured to form a surround or "satellite" channel of a home theater system. The combined playback devices 110h, 110i, 110j, and 110k may form a single Zone D (FIG. 1M).

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

[0064] In some embodiments, an NMD is combined or merged with another device to form a zone. For example, NMD 120b may be combined with playback device 110e, which together form a zone F called the Living Room. In other embodiments, a standalone networked microphone device may itself be in a zone. However, in other embodiments, a standalone networked microphone device may not be associated with a zone. Further details regarding associating networked microphone devices and playback devices as designated or default devices can be found, for example, in the above-referenced U.S. Patent Application Publication No. 15 / 438,749.

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

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

[0067] Certain data may be stored in a memory of the 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 its associated zone group. The memory may also contain data that is associated with the state of other devices in the media system and that is shared from time to time between the devices so that one or more of the devices have the most up-to-date data associated with the system.

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

[0069] In yet another example, the media playback system 100 can store variables or identifiers representing other associations of zones and zone groups, such as identifiers associated with areas, as shown in FIG. 1M. Areas 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 including zones A-D and a lower area 109b including zones E-I. In one aspect, an area can be used to call out a cluster of zone groups, and / or a zone that shares one or more zones and / or a zone group of another cluster. In another aspect, this is distinct from a zone group that does not share a zone 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 August 21, 2017, entitled "Room Association Based on Name," and U.S. Patent No. 8,483,853, filed September 11, 2007, entitled "Controlling and manipulating groupings in a multi-zone media system." Each of these applications is incorporated herein by reference in its entirety. In some embodiments, 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 devices 110 of the media playback system 100 are named and arranged according to a control hierarchy referred to as a home graph. Under the home graph hierarchy, the basic unit of the home graph hierarchy is a "set." A "set" refers to an individual device or multiple devices that work together in performing a given function, such as an individual playback device 110 or a combined zone of playback devices. After a set, the next level of the hierarchy is a "room." Under the home graph hierarchy, a "room" can be thought of as a repository for a given set of rooms in a residence. For example, an exemplary room corresponds to the kitchen of a home, is assigned the name "kitchen," and can contain one or more sets (e.g., "kitchen island"). The next level of the exemplary home graph hierarchy is an "area," which contains two or more rooms (e.g., "upstairs" or "downstairs"). The top of the home graph hierarchy is a "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 US Patent Application Publication No. 16 / 216,357, entitled "Home Graph," which is incorporated herein 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 embodiment of the disclosed technology. FIG. 2B is a front isometric view of the playback device 210 without the grill 216e. FIG. 2C is an exploded view of the playback device 210. With joint reference to FIGS. 2A-2C, the playback device 210 includes a housing 216 including an upper portion 216a, a right or first side 216b, a lower portion 216c, a left or second side 216d, a grill 216e, and a rear portion 216f. A plurality of fasteners 216g (e.g., one or more screws, rivets, clips) attach the frame 216h to the housing 216. A cavity 216j (FIG. 2C) in the housing 216 is configured to receive the frame 216h and the electronic device 212. Frame 216h is configured to carry a plurality of transducers 214 (individually identified in FIG. 2B as transducers 214a-f). Electronics 212 (e.g., electronics 112 of FIG. 1C) is configured to receive audio content from an audio source and to transmit electrical signals corresponding to the audio content to transducers 214 for playback.

[0072] The transducers 214 are configured to receive electrical signals from the electronics 112 and are further configured to convert the received electrical signals into audible sounds during playback. For example, the transducers 214a-c (e.g., tweeters) can be configured to output high-frequency sounds (e.g., sound waves having frequencies above about 2 kHz). The transducers 214d-f (e.g., mid-woofers, woofers, mid-range speakers) can be configured to output sounds at lower frequencies than the transducers 214a-c (e.g., sound waves having frequencies below about 2 kHz). In some embodiments, the playback device 210 includes a number of transducers different from those shown in Figures 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 transducers (e.g., 9, 10). Further, in some embodiments, all or a portion of the transducers 214 are configured to operate as a phased array to desirably tailor (e.g., narrower or wider) the radiation pattern of the transducers 214, thereby altering the user's perception of the sound emanating from the playback device 210.

[0073] 2A-2C, the filter 216i is axially aligned with the transducer 214b. The filter 216i can be configured to desirably attenuate a predetermined frequency range output by the transducer 214b to improve the sound quality and perceived sound 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 of the transducers 214.

[0074] 3A and 3B are front and right isometric side views, respectively, of an NMD 320 configured in accordance with an embodiment of the disclosed technology. FIG. 3C is an exploded view of the NMD 320. FIG. 3D is a close-up view of a portion of FIG. 3B including the user interface 313 of the NMD 320. Referring initially to FIGS. 3A-3C, the NMD 320 includes a housing 316 with an upper portion 316a, a lower portion 316b, and a middle portion 316c (e.g., a grill). A plurality of ports, holes, or openings 316d in the upper portion 316a allow the passage of sound to one or more microphones 315 (FIG. 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 of the housing 316 (FIG. 3C) encloses cavities 316f and 316g configured to accommodate a first transducer 314a (e.g., a tweeter) and a second transducer 314b (e.g., a mid-woofer, mid-range speaker, woofer), respectively. However, in other embodiments, the NMD 320 includes a single transducer, or three or more (e.g., two, five, six) transducers. In certain embodiments, the NMD 320 omits the transducers 314a and 314b entirely.

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

[0076] 3D, the user interface 313 includes multiple 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). The fourth control surface 313d is configured to receive touch input corresponding to activation and deactivation of one or more microphones 315. The first indicator 313e (e.g., one or more light emitting diodes (LEDs) or another suitable lighting device) may be configured to illuminate only when one or more microphones 315 are activated. The second indicator 313f (e.g., one or more LEDs) may be configured to remain illuminated in normal operation and to flash or otherwise change from illuminated 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. Moreover, in certain embodiments, the NMD 320 comprises a playback device and a control device, and the user interface 313 comprises a user interface of the control device.

[0077] 3A-3D together, the NMD 320 is configured to receive voice commands from one or more nearby users via one or more microphones 315. As described above with respect to FIG. 1B, the one or more microphones 315 can acquire, capture, or record sounds in the vicinity (e.g., an area within 10 meters of the NMD 320) and transmit electrical signals corresponding to the recorded sounds to the electronics 312. The electronics 312 can process the electrical signals 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, the NMD 320 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 after detecting one or more appropriate voice commands. The remote server can analyze the audio data, determine an appropriate action based on the voice command, and transmit a message to the NMD 320 to perform the appropriate action. For example, a user can utter, "Sonos, play Michael Jackson." The NMD 320 can record the user's voice utterances via one or more microphones 315, determine the presence of a voice command, and transmit 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 a VAS, and / or another suitable 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 the NMD 320 to perform the determined action (e.g., play audio content related to Michael Jackson). The NMD 320 can receive this command and play audio content related to Michael Jackson from the media content source.1B, suitable content sources may include devices or storage communicatively coupled to the NMD 320 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 NMD 320 determines and / or performs one or more actions corresponding to one or more voice commands without the intervention or involvement of an external device, computer, or server.

[0078] 4A-4D are schematic diagrams of a control device 430 (e.g., control device 130a of FIG. 1H, a smartphone, a tablet, a dedicated control device, an 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”). The selected group area 433b displays audio content information (e.g., artist name, track name, album art) of the audio content being played in the selected group and / or zone. The group areas 433c and 433d display the corresponding group and / or zone name, as well as audio content information, audio content being played or being played next in the play queue for the respective group or zone. The audio content area 433e includes information regarding the audio content in 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 to display one or more other user interface displays. For example, if 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) that includes a plurality of music services 433g (e.g., Spotify, Radio by Tune In, Apple Music, Pandora, Amazon, TV, Local Music, Line In) from which the user can browse and select media content for playback via one or more playback devices (e.g., one of the playback devices 110 of FIG. 1A). Alternatively, if the user selects "My Sonos" in 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. If the user selects the graphical representation 433j (FIG. 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 including an enlarged version of the graphical representation 433j, media content information 433k (e.g., track name, artist, album), transport controls 433m (e.g., play, rewind, fast forward, pause, volume), and a display 433n of the currently selected group and / or zone name.

[0079] FIG. 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, previous, 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 a user can select media items for playback and / or addition to a playback queue.

[0080] The playback zone area 533b may include representations of playback zones within the media playback system 100 (FIGS. 1A and 1B). In some embodiments, the graphical representations of the playback zones 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. Once grouped, playback devices within a zone grouped with the particular zone may be configured to play audio content in sync with the playback devices within the particular zone. Similarly, a "group" icon may be provided within the graphical representation of a zone group. In the illustrated embodiment, the "group" icon may be selectable to display an option for deselecting one or more zones within the zone group 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 certain embodiments, the representation of the play zones in play zone area 533b may be dynamically updated as play zone or zone group configurations change.

[0081] The playback status area 533c includes a graphical representation of audio content that is currently playing, previously playing, or next scheduled to play 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 in the playback zone area 533b and / or the playback queue area 533d. The graphical representation may include track title, artist name, album name, album year, track length, and other relevant information that may be useful for a 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 in 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 in the playback queue may comprise a uniform resource identifier (URI), a uniform resource locator (URL), or some other identifier that can be used by a playback device in the playback zone or zone group to find and / or retrieve the audio item from local or networked audio content sources, as the case may be, for playback by the playback device. In some embodiments, for example, a playlist may be added to the playback queue, and information corresponding to each audio item in the playlist may be added to the playback queue. In some embodiments, the audio items in the playback queue may be saved as a playlist. In certain embodiments, the playback queue may be empty or pre-populated but "unused" when the playback zone or zone group is continuously playing streaming audio content, such as Internet radio, that may otherwise continue to play until stopped, rather than individual audio items with playback durations. In some embodiments, the playback queue can include Internet radio and / or other streaming audio content items and can be "in use" when a playback zone or zone group is playing those items.

[0083] When a playback zone or zone group is "grouped" or "ungrouped," the playback queues associated with the affected playback zones or zone groups can be cleared or reassociated. For example, when 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 initially have playback queues that are empty, contain audio items from the first playback queue (such as when the second playback zone is added to the first playback zone), contain audio items from the second playback queue (such as when the first playback zone is added to the second playback zone), or are associated with a combination of audio items from both the first and second playback queues. If the established zone group is subsequently ungrouped, the resulting first playback zone may be reassociated with the previous first playback queue, or may be associated with a new playback queue that was empty or contained audio items from the playback queues associated with the established zone group before the established zone group was ungrouped. Similarly, the resulting second playback zone may be reassociated 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 before the established zone group was ungrouped.

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

[0085] In step 650a, the media playback system 100 receives, via the control device 130a, an indication of selected media content (e.g., one or more songs, albums, playlists, podcasts, videos, stations). The selected media content may include, for example, media items stored locally on one or more devices connected to the media playback system (e.g., audio source 105 of FIG. 1C) and / or media items stored on one or more media service servers (one or more of remote computing devices 106 of FIG. 1B). In response to receiving the indication 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 a playback queue of the playback device 110a.

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

[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 causing the playback device 110a to play the selected media content. In response to receiving message 651b, the playback device 110a sends a message 651c to the computing device 106a requesting the selected media content. In response to receiving message 651c, the computing device 106a sends a message 651d including data (e.g., audio data, video data, URL, URI) corresponding to the requested media content.

[0088] At step 650d, playback device 110a receives 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 a combined zone 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 in the combined zone. In another example, the playback device 110a is a coordinator of the group and is configured to send and receive timing information from one or more other devices in the group. One or more other devices in the group can receive the selected media content from the computing device 106a and start playing the selected media content in response to a message from the playback device 110a, so that all devices in the group play the selected media content in a synchronized manner.

[0090] IV. Exemplary Synchronous Grouping Techniques An example of a synchronization technique includes a 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 some embodiments, at least some aspects of the technical solution are derived from the technical structure and configuration of the audio information, playback timing, and clock timing information that the playback devices use to play audio content from audio sources in synchronization with each other, including how the different playback devices generate playback timing based on clock timing (local clock timing or remote clock timing) and play audio content based on the playback timing (locally or remotely generated) and the clock timing (locally or remotely generated). Therefore, to aid in understanding certain aspects of the disclosed technical solution, certain technical details of the audio information, playback timing, and clock timing information, as well as how the playback devices generate and / or use the playback timing and clock timing for playing audio content in different configurations, are described below.

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

[0092] In operation, a "source" playback device refers to a playback device that captures any of the aforementioned types of audio content from an audio source via an interface, where the interface may be, for example, one of the source playback device's network interface, a "line-connected" analog interface, a digital audio interface, or any interface now known or hereafter developed suitable for receiving audio content in digital or analog form.

[0093] An audio source is any system, device, or application that generates, provides, or makes available any of the aforementioned audio content to a playback device. For example, in some embodiments, an 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., AppleTV, 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 acquires audio content from an audio source and plays and / or distributes it to other playback devices is referred to herein as an "originating" playback device, a "master" playback device, or a "group coordinator." One function of an "originating" playback device is to process and play and / or distribute the received audio content to other playback devices. In some embodiments, the originating playback device transmits the processed audio content to all playback devices configured to play the audio content. In some embodiments, the originating 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 the multicast address. In some embodiments, the originating playback device alternatively transmits the processed audio content to a respective 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 the unicast address.

[0095] In some embodiments, a "source" playback device receives audio content in digital form from an audio source, for example as a stream of packets. In some embodiments, each packet in the stream of packets has a sequence number or other identifier that specifies the order of the packets. Because packets transmitted over 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 stream of packets 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, or at least includes, a timestamp indicating the time the packets were created. The packet creation time can be used as the sequence number, based on the assumption that the packets are created in the order in which they should be played next.

[0096] In some embodiments, the source playback device does not change sequence numbers or identifiers of the received packets during packet processing. In some embodiments, the source playback device reorders at least a first set of packets in the packet stream based on the sequence identifier of each packet, extracts audio content from the received packets, reassembles a bitstream of the audio content from the received packets, and then repacketizes the reassembled bitstream into a second set of packets, where the packets in the second set of packets have sequence numbers that differ from the sequence numbers of the packets in the first set of packets. In some embodiments, the individual packets in the second set of packets are of a different length (i.e., shorter or longer) than the individual packets in the first set of packets. In some embodiments, reassembling the bitstream from the incoming packets and then repacketizing the reassembled bitstream into different sets of packets facilitates uniform processing and / or transmission of the audio content by the source playback device and other playback devices that receive the audio content from the source playback device. However, for some delay-sensitive audio content, reassembly and repacketization may not be desirable, and therefore, in some embodiments, the source playback device may not perform reassembly and repacketization on some (or all) of the audio content it receives before playing the audio content and / or sending the audio content to other playback devices.

[0097] In some embodiments, an audio source provides audio content in digital form to an originating playback device, for example via a digital line connect interface. In such embodiments, the originating playback device packetizes the digital audio into packets of audio content before transmitting the audio content to other playback devices. In some embodiments, the individual packets of audio content include sequence numbers or other identifiers so that when other playback devices receive the audio content, those other playback devices can ensure that they place the received packets in the correct order before performing further packet processing.

[0098] In some embodiments, an audio source provides audio content in analog form to an originating playback device, for example via an analog line connection interface. In such embodiments, the originating playback device converts the received analog audio to digital audio and packetizes the digital audio into packets of audio content before transmitting the audio content to other playback devices. In some embodiments, the individual packets of audio content include sequence numbers or other identifiers so that when other playback devices receive the audio content, those other playback devices can ensure that they place the received packets in the correct order before performing further packet processing.

[0099] After obtaining the audio content from an audio source or another playback device, in some embodiments, the playback device does one or more of the following: (i) plays the audio content individually; (ii) plays the content synchronously with one or more additional playback devices; and / or (iii) transmits the audio content to one or more other playback devices.

[0100] b. Playback timing The playback devices disclosed and described herein use the playback timing to play audio content in synchronization with each other. Each playback device can generate the playback timing and / or play 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 the multicast address. In some embodiments, the source playback device alternatively transmits the playback timing to each 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 the unicast address.

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

[0102] In some embodiments, 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), with each frame (or packet) containing a portion of the audio content. In some embodiments, the playback timing of the audio content includes a playback time for each frame (or packet) of the audio content. In some embodiments, the playback timing of each frame (or packet) is included within the frame (or packet), e.g., in a header of the frame (or packet), an extension header of the frame (or packet), and / or a payload portion of the frame (or packet).

[0103] In some embodiments, the playout time of an individual frame (or packet) is identified in a timestamp or other indication. In such embodiments, the timestamp (or other indication) represents the point in time to play back the audio content in that individual frame (or packet). In operation, when the playout timing for an individual frame (or packet) is generated, the playout timing for that individual frame (or packet) is a future time relative to the current clock time of the reference clock when the playout timing for that individual frame (or packet) was generated. The reference clock can be a "local" clock at the playback device or a "remote" clock at a separate 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 playout timing and / or play audio content.

[0104] In operation, a playback device responsible for playing a particular audio content plays a portion of a particular audio content within an individual frame (or packet) at a playback time specified by the playback timing of that individual frame (or packet), with adjustments made to accommodate clock timing differences between the source playback device and the playback device responsible for playing the audio content, as described in more detail below.

[0105] c. Clock timing The playback devices disclosed and described herein use clock timing to generate playback timing for audio content and play back the audio content based on the generated playback timing. In some embodiments, the source playback device uses 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 playback timing for audio content that the source playback device receives from an audio source. The reference clock for an individual playback device may use a "local" clock at the playback device or a "remote" clock at a separate network device, e.g., another playback device, a computing device, or another network device configured to provide timing for the clock for the playback device to use to generate playback timing and / or play audio content.

[0106] In some embodiments, all of the playback devices responsible for synchronously playing a particular audio content use the same clock timing as the reference clock to play that particular 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, the network device that generates the clock timing also transmits the clock timing to all playback devices in the network that need to use the clock timing for generating the playback timing and / or playing the audio content. In some embodiments, the network device that generates the clock timing transmits the clock timing to a multicast network address, and all other playback devices configured to generate the playback timing and / or play the audio content receive the clock timing via the multicast address. In some embodiments, the network device alternatively transmits the clock timing to a unicast network address for each other playback device configured to play the audio content, and each other playback device configured to play the audio content receives the clock timing via the unicast address.

[0108] d. Generating recovered timing using clock timing from a local clock In some embodiments, the source playback device (i) generates playback timing for the audio content based on clock timing from a local clock at 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 playback timing for individual frames (or packets), the "source" playback device adds a "timing advance" to the current clock time of the source playback device's local clock that the source playback device is using to generate the playback timing.

[0109] In some embodiments, the "timing advance" is based on an amount of time equal to or greater than the sum of (i) the network transmission time required for frames and / or packets containing the audio content to be transmitted from the source playback device to all other playback devices configured to use the playback timing for synchronously playing back the audio content, and (ii) the playback time required for all other playback devices to use their playback timing for synchronous playback and process the frames / packets received from the source playback device.

[0110] In some embodiments, the source playback device determines the timing advance by sending one or more test packets to one or more (or possibly all) of the other playback devices configured to play the audio content that the source device is transmitting, and then receiving test response packets back from one or more of the other playback devices. In some embodiments, the source playback device and the one or more other playback devices negotiate the timing advance via multiple 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 by setting a timing advance sufficient for the playback device with the longest sum of network transmission time and packet processing time.

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

[0112] As described in more detail below, all playback devices configured to play audio content in a synchronous manner use playback timing and clock timing to play the audio content in sync with one another.

[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 the audio content in synchronization with one or more other playback devices. And, if the source playback device uses clock timing from a local clock at the source playback device to generate the play timing, the source playback device plays the audio content using the locally generated play 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 play timing reaches a time specified in the play timing of that individual frame (or packet).

[0114] For example, as described above, when the source playback device generates the playback timing of an individual frame (or packet), it adds a "timing advance" 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 a local clock at the source playback device. Thus, if the timing advance of an individual frame is, for example, 30 milliseconds, the source playback device will play back a portion (e.g., a sample or set of samples) of the audio content of an individual frame (or packet) 30 milliseconds after generating the playback timing for that individual frame (or packet).

[0115] In this manner, the source playback device plays back the audio content using the locally generated playout timing and the clock timing from the local reference clock, and plays back the portion of the audio content for each individual frame and / or packet when the clock time of the local reference clock reaches the playout timing for that individual frame or packet, as described further below, but in synchronization with the 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 audio content and playback timing of the audio content to one or more other playback devices. Also, in some embodiments, the network device providing the clock timing may be a different device than the source playback device. The playback devices receiving the audio content, playback timing, and clock timing from the other playback devices are configured to play the audio content using the playback timing from the source playback device (i.e., remote playback timing) and the clock timing from the clock of the other playback device (i.e., remote clock timing). In this way, the receiving playback device in this example plays the audio content using the remote playback timing and the remote clock timing.

[0117] A receiving playback device tasked with playing audio content in synchronization with all other playback devices plays individual frames (or packets) of the audio content by (i) receiving frames (or packets) containing portions of the audio content from the source playback device, (ii) receiving playback timing of the audio content from the source playback device (e.g., the playback timing included in the frame headers and / or packet headers of the frames and / or packets containing the portions of the audio content, or possibly elsewhere than the frames and / or packets containing the portions of the audio content), (iii) receiving 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 played audio content, and (iv) playing the audio content portion of the individual frame (or packet) when the local clock used by the receiving playback device to play the audio content reaches the playback time specified in the playback timing of the individual frame (or packet) received from the source playback device, adjusted by a "timing offset".

[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 at the network device that the network device uses to generate the clock timing and a "local" clock at the receiving playback device that the receiving playback device uses 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" that each playback device determines is unique to that playback device.

[0119] In some embodiments, when playing back audio content, the receiving playback device generates new playback timings (specific to the receiving playback device) for each frame (or packet) of the audio content by adding a 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. Because each receiving playback device calculates its own "timing offset," the "local" playback timing determined for each frame is specific to that playback device.

[0120] Also, when the "local" clock that the receiving playback device is using to play the audio content reaches the "local" play time of an individual frame (or packet), the receiving playback device plays the audio content (or a portion thereof) associated with that individual frame (or packet). As noted above, in some embodiments, the play timing of a particular frame (or packet) is in the frame's (or packet's) header. In other embodiments, the play timing of an individual frame (or packet) is transmitted separately from the frame (or packet) that contains the audio content.

[0121] The receiving playback device plays frames (or packets) containing portions of the audio content according to the playback timing adjusted by a "timing offset" relative to the clock timing, and the source playback generates playback timing for those frames (or packets) relative to the clock timing and plays the same frames (or packets) containing portions of the audio content according to the playback timing and its determined "timing offset," so that the receiving playback device and the source playback device play the same frames (or packets) containing the same portions of the audio content synchronously, i.e., 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. Pat. No. 8,234,395, entitled “System and method for synchronizing operations among a plurality of independently clocked digital data processing devices,” which is incorporated by reference in its entirety.

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

[0124] 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 particular form factor (e.g., headphones or earbuds) and includes one or more batteries in the power supply 712i to provide portable power.

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

[0126] The playback device 710a further includes electronics 712, a user interface 713 (e.g., one or more buttons, knobs, dials, touch-sensitive surface, display, touch screen), and one or more transducers 714 (hereinafter referred to as “transducers 714”). The electronics 712 is configured to receive audio from an audio source via input / output 711 and from one or more of the computing devices 106a-c via 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, a 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 phone calls, etc. In particular embodiments, for example, the playback device 710a can operate as an NMD (similar to the NMD 120 of FIG. 1F) configured to receive voice input from a user using the voice microphones and correspondingly perform one or more operations based on the received voice input. In further examples, the microphone 715 can include one or more acoustic noise canceling (ANC) microphones that, in operation, capture ambient noise in the environment to facilitate cancellation of the ambient noise by the playback device 710a.

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

[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, the link 103 and / or the network 104 (FIG. 1B). The network interface 712d 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-transient signals) including digital packet data that includes an Internet Protocol (IP)-based source address and / or an IP-based destination address. The network interface 712d can parse the digital packet data so that the electronics 712 appropriately receives and processes the data destined for the playback device 110a.

[0130] In the embodiment shown in FIG. 7B, the 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) can be configured to wirelessly communicate with one or more other devices (e.g., one or more of the playback device 110, the NMD 120, the control device 130, the other portable playback devices 710, and other devices disclosed herein, such as a bridge device) communicatively coupled to the network 104 (FIG. 1B) according to a suitable wireless communication protocol (e.g., WiFi, Bluetooth, LTE). In some embodiments, the network interface 712d optionally includes a wired interface 712f (e.g., an interface or receptacle configured to receive a network cable, such as an 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, the electronic device 712 omits the network interface 712d entirely and transmits and receives media content and / or other data via another communication path (eg, input / output 711).

[0131] The audio components 712g are configured to process and / or filter data including media content received by the electronics 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 components 712g comprise, for example, one or more digital-to-analog converters (DACs), audio pre-processing components, audio enhancement components, digital signal processors (DSPs), and / or other suitable audio processing components, modules, circuits, etc. In particular embodiments, one or more of the audio processing components 712g may include one or more subcomponents of the processor 712a. In some embodiments, the electronics 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 the output audio signal.

[0132] The amplifiers 712h are configured to receive and amplify audio output signals generated by the audio processing component 712g and / or the processor 712a. The amplifiers 7712h may comprise electronic devices and / or components configured to amplify the audio signals to a level sufficient to drive one or more of the transducers 714. In some embodiments, for example, the amplifiers 712h include one or more switching or class D power amplifiers. However, in other embodiments, the amplifiers include 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 amplifiers 712h include a suitable combination of two or more of the aforementioned types of power amplifiers. Furthermore, in some embodiments, individual ones of the amplifiers 712h correspond to individual ones of the transducers 714. However, in other embodiments, the electronics 712 includes a single one of the amplifiers 712 h configured to output an amplified audio signal to the multiple 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 a frequency between about 20 Hertz (Hz) and 20 Kilohertz (kHz)). In some embodiments, the transducer 714 may include a single transducer. However, in other embodiments, the transducer 714 includes multiple audio transducers. In some embodiments, the transducer 714 includes multiple types of transducers. For example, the transducer 714 may include one or more low frequency transducers (e.g., subwoofer, woofer), a mid-range frequency transducer (e.g., mid-range transducer, mid-woofer), and one or more high frequency transducers (e.g., one or more tweeters).

[0134] 7C is a front isometric view of a portable playback device 710a configured in accordance with 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 on or around the user's head over the user's ears.

[0135] The headphones 710a also include a user interface 713a having touch-sensitive areas to facilitate playback controls, such as transport and / or volume control. The touch-sensitive areas of the user interface 713a can support gesture control. For example, swiping forward or backward across the touch-sensitive areas can skip forward or backward, respectively. Other gestures include touch-and-hold and touch-and-continued-hold, which can correspond to various swapping and grouping functions, as described in further detail below. In some implementations, the user interface 713a can include a respective touch-sensitive area on the outside of each earcup.

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

[0137] FIG. 7E is a front isometric view of the portable playback device 710c. Compared to the headphones 710a and the earbuds 710b, the portable playback device 710c includes one or more larger transducers to facilitate louder audio content playback. A speaker grill 716a covers the transducers. Relative to the playback device 110, the portable playback device 710c may include less powerful amplifiers 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 touch-sensitive areas to facilitate playback controls such as transport and / or volume control.

[0138] Some portable playback devices 710 are configured to be placed on a device base 718. For illustrative purposes, FIG. 7F is a front isometric view of a portable playback device 710d configured to be placed on a device base 718a. Similar to the portable playback device 710c, compared to the headphones 710a and the earbuds 710b, the portable playback device 710d includes one or more larger transducers to facilitate louder audio content playback. A speaker grille 716b covers the transducers. The portable playback device 710c includes a user interface 713d having touch-sensitive areas to facilitate playback control, 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 can facilitate placement of the portable playback device 710c on the device base 718a and can improve stability of the playback device while placed on the device base 718a.

[0140] In an exemplary implementation, 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 on 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. The rotation of these two portions generates a volume control signal to a sensor on 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 an equipment 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 a current in a corresponding coil in 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 it from at least some other device bases (e.g., other device bases of the media playback system 100, or perhaps other device bases more broadly). 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 provided 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, QR code, or other identification component that is read by the playback device 710c when the playback device 710c is placed on the device base 718a.

[0143] In some implementations, a device base 718 of the media playback system 100 is associated with each zone. When the portable playback device 710 is placed in a device base, the device base joins the associated zone. Further details regarding device bases can be found, for example, in U.S. Pat. No. 9,544,701, entitled "Base Properties in a Media Playback System," which is incorporated herein 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 clocked computing component that processes input data according to instructions stored in the memory. An exemplary operation includes, among other examples, communicating with the playback device 710c (e.g., causing the playback device 710c to join an associated zone via one or more instructions) via a communication interface (e.g., a BLUETOOTH interface) and causing a charging system to provide current to the playback device 710c.

[0145] In an exemplary implementation, 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 of the media playback system 100 (e.g., at home, while connected to the network 104) to facilitate interoperability with the playback devices 110a-n of the media playback system 100, and in the second mode while "on the move," although the playback device 710 may also be capable of operating in the second mode while in physical proximity of 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. Additionally, 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 sync group or other arrangement with the playback devices 110a-n and / or other portable playback devices 710 in the first mode. Additionally, in the first mode, the portable playback device 710 may be controlled by the control device 130 in the same or 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 wearable device. That is, the playback device 710 can be paired with a mobile device, such as a smartphone or tablet, and a user can play the audio output of the mobile device. Similarly, the microphone 715a of the portable playback device 710 can provide audio input to the mobile device. As mentioned above, this mode can be utilized "on the go" to facilitate playback away from the media playback system 100, for example, outside the range of a home network. Additionally, this mode can be used in close proximity to the media playback system 100, thereby facilitating more private use of the portable playback device 710a or providing convenient access to the mobile device's content for playback.

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

[0149] The control device 130a may include communication interfaces, processing capabilities, and / or other features 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 710a may take advantage of some of these features. This arrangement may allow the portable playback device 710a to be smaller and more portable, consume less power, and / or be less expensive, among other possible advantages.

[0150] For example, in various embodiments, the portable playback device 710a may be implemented with or without a communications 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 (IEEE 802.15) or a wireless local area network connection (IEEE 802.11), the portable playback device 710a can stream music via the Internet connection and pairing connection of the control device 130a. In embodiments that include a wireless local area network interface, the portable playback device 710a may connect directly 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 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 (IEEE 802.15), the portable playback device 710a can stream music via the Internet connection and 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 with a gateway to the Internet or via a cellular data connection.

[0152] In an exemplary implementation, the control device 130a is bound or defaulted to a particular playback device (e.g., playback device 110c), a bound zone of playback devices (e.g., playback devices 110l and 110m), or a group of playback devices, such as the "Kitchen + Dining Room" group. Alternatively, if a home graph hierarchy is utilized, the control device 130a can be bound or defaulted to a particular set, room, or area. Then, in this configuration, control of the bound playback device 110 via the NMD 120 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 set. For example, in one example, the control device 130a may be configured as an "Anne's portable" zone or an "Anne's headphones" set. Configuring the control device 130a as a zone or set facilitates control of the paired headphones 710a by the NMD 120 and / or the control device 130 of the media playback system 100.

[0154] In alternative implementations, the portable playback device 710a may interface independently with the media playback system 100 as its own zone or set. Such an implementation of the portable playback device 710a may 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 may 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 mentioned above, the example techniques described herein relate to transitioning (or "swapping") playback sessions between portable playback device 710 and one or more playback devices 110. During a playback session swap, playback of audio content stops at the "source" playback device and begins at the "target" playback device at the same or substantially the same offset in the audio content. For example, 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, media playback system 100 can swap playback between one or more "source" playback devices 110 and a "target" portable playback device 710.

[0156] To illustrate, a user may begin listening to audio content through headphones 710a or earbuds 710b while "on the go" and then swap the playback of the audio content to one or more playback devices 110a-n to continue listening to the audio content loudly at home. In another example, a user may begin listening to audio content through headphones 710a or earbuds 710b at home (perhaps to avoid disturbing others in the home) and then connect to one or more playback devices 110a-n to continue listening to the audio content loudly. In a third example, a user may begin listening to audio content loudly through a portable playback device 710c and then swap to one or more playback devices 110a-n because the target playback device may have a larger acoustic output capability (e.g., due to a more powerful amplifier and / or a larger transducer), may be located in another room, may be configured in a synchronous group, or for any other reason.

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

[0158] A playback device in which a playback session is running can maintain state or access playback session data that defines and / or identifies the playback session. The playback session data can include data representing the source of the audio content (e.g., a URI or URL indicating the location of the audio content) and an offset indicating the position in the audio content to begin playback. Among other ways, the offset can be defined as a time (e.g., in milliseconds) from the beginning of the audio track or as a number of samples. In an example implementation, the offset can be set to a playback position in the audio content at the current playback position to give the target device time to begin buffering the audio content. The source playback device then 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 may include data representing the source of the audio content (e.g., a URI or URL indicating the location of the audio content) and an offset indicating the position within the audio content to begin playback. The offset may be defined as a time (e.g., in milliseconds) from the beginning of the audio track or as a number of samples, among other examples.

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

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

[0162] Additionally, the playback session data may also include authentication data, such as one or more keys and / or tokens. Such authentication data may include a token associated with a user's account. During a playback session swap, the media playback system 100 may verify that the token is authorized at both the source and the target playback device. The authentication data may further include a token associated with a streaming audio service, which may enable the target playback device to access the audio content at the source. Still further, the authentication data may include a token associated with a playback session that enables the target playback device to access the session. Other exemplary authentication data are 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 in a user interface of the playback device, such as user interface 313 of playback device 320 (FIG. 7D) or user interface 713a of headphones 710 (FIG. 7B). Alternatively, the playback session swap input may be provided in a user interface of control device 130, such as user interface 430 (FIGS. 4A-4D), when user interface 430 is controlling a particular playback device (e.g., a zone or zone group).

[0164] The playback device that accepts the playback session swap input may be referred to as the "lead playback device." In examples, the lead 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 may assume that the user wants to "push" the playback session to the nearby playback device 110. Thus, the portable playback device 710 is identified as the source of the swap, and the nearby playback device 110 is identified as the target.

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

[0166] Conversely, if the portable playback device 710 is not running a playback session and receives a playback session swap input, the portable playback device 710 determines that the user wants to "pull" the playback session from the nearby playback device 110. Here, the portable playback device 710 is identified as the target of the swap, and the nearby playback device 110 is identified as the source. To illustrate, FIG. 8B is a schematic diagram showing an exemplary pull swap between headphones 710a (FIG. 7C) and playback device 110b in the kitchen 110h zone (FIG. 7A). As shown in FIG. 8B, in the initial state, the playback device 110b continues to run a playback session. At this time, the user gives a playback session swap gesture to headphones 710a. Then, the playback session of the playback device 110b is pushed to headphones 710a. After the push, headphones 710a starts the playback session.

[0167] When both the portable playback device 710 and the nearby playback device 110 have ongoing playback sessions, it may be unclear whether the user wants to push the playback session of the portable playback device 710 to the nearby playback device 110 or pull 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" the playback session to the nearby playback device 110. To explain, FIG. 8C is a schematic diagram showing an example 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 their playback sessions. 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 to the playback device 110b. After the push, playback device 110b in kitchen 110h zone takes over the playback session running on headphones 710a. Conversely, if a user wants to "pull" the playback session of a nearby playback device 110, the user can first stop the playback session on portable playback device 710 and then grant a playback session swap to portable playback device 710. In another embodiment, portable playback device 710 may be configured to do the exact opposite.

[0168] In the example of FIGS. 8A-8C, the leading device is headphones 710a. In another example, a user may make a playback session swap input to any of the playback devices 110, such as playback device 110b. In this scenario, similar determinations may be applied when specifying the source and target of the swap. In particular, when playback device 110b is running a playback session and receives a playback session swap input, playback device 110b may determine that the user wants to "push" the playback session to a nearby portable playback device 710. Conversely, when playback device 110b is not running a playback session and receives a playback session swap input, playback device 110b may determine that the user wants to "pull" the playback session from a nearby portable playback device 710.

[0169] In an example, a lead playback device leading a swap can cause other playback devices in the lead playback device's neighborhood to identify themselves as swap targets. That is, the lead playback device can identify one or more nearby playback devices as targets for a push swap from the lead playback device or as sources for a pull swap to the lead playback device. After receiving or based on a playback session swap input, the lead playback device can identify such nearby playback devices automatically (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 which the lead playback device requests that a playback device eligible for swap emit a distinguishable sound (such as an audio chirp) that is detected by one or more microphones on the lead playback device, and the lead playback device then identifies the nearby playback devices based on characteristics of the detected sound.

[0171] To illustrate, Fig. 9 is a schematic diagram showing a voice-based identification technique using an audio chirp. The audio chirp includes acoustic characteristics (e.g., one or more tones) that allow identification of the playback device that transmits the audio chirp. In Fig. 9, a user initiates a swap on a portable playback device 710 (here, headphones 710a). As described above, if a playback session is running on headphones 710a, headphones 710a assume that the user wants to push the playback session to one or more nearby playback devices. Alternatively, headphones 710a assume that the user wants to pull the playback sessions of one or more nearby playback devices to headphones 710a.

[0172] After or based on receiving a playback session swap input, headphones 710a may identify playback devices in media playback system 100 that are eligible for swapping. In the case of a push swap, the set of playback devices eligible for swapping includes playback devices of a particular type or assigned a particular role in media playback system 100. Other portable playback devices may be ineligible for swapping. As another example, only masters in a combined zone (e.g., a stereo pair or surround sound configuration) may be considered eligible for swapping. In the case of a pull swap, the set of playback devices eligible for swapping includes playback devices that have an ongoing playback session. This set may 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 may maintain or access state variables of the playback device, as well as other configuration information. This state information may be updated periodically or on an event basis (e.g., when the status changes), such as via subscription to certain types of events or status (e.g., playback events, grouping events, topology change events, player volume events, group volume events, playback metadata events) and notification of the specific events. The protocol used for subscription may be uPnP-based or a proprietary controller protocol or API. The portable playback device 710, including the headphones 710a and earbuds 719b, may similarly maintain or access these state variables and determine the set of playback devices eligible for swapping based on the information in 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 in the cloud. In the example of FIG. 9, headphones 710a have identified playback device 110b, playback device 110g, and playback device 100g as eligible playback devices for swapping.

[0174] After identifying the multiple playback devices eligible for swapping, headphones 710a, as the lead playback device in the swap, may cause the multiple playback devices eligible for swapping to emit their respective audio chirps. For example, headphones 710a may send instructions to playback device 110b, playback device 110g, and playback device 100g to cause the multiple playback devices eligible for swapping to emit their own audio chirps. In some examples, the audio chirps may be ultrasonic (e.g., greater than 20 kHz) or near-ultrasonic (e.g., 19-20 kHz) to avoid propagation of the audio chirp outward from the vicinity of the emitting playback device and / or to avoid discomfort to the user.

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

[0176] After the lead playback device of the swap has instructed the multiple playback devices eligible for the swap to emit an audio chirp, it attempts to detect the emitted audio chirp via one or more microphones (e.g., microphone 715). For example, headphones 710a may attempt to detect the emitted audio chirp via one or more voice microphones in the housing of headphones 710a. Alternatively, headphones 710a may attempt to detect the emitted audio chirp via one or more ANC microphones in the housing of headphones 710a. In some cases, certain microphones (ANC or voice) may be selected or tuned to be sensitive to ultrasonic or near-ultrasonic ranges such that these microphones are particularly suited to receiving audio chirps. Other examples are possible as well.

[0177] To identify a "nearby" playback device, the lead playback device can compare the detected audio chirps. For example, headphones 710a may compare various metrics, such as 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 that is physically closest to the lead playback device. In an exemplary implementation, the lead playback device can list or rank the swap-eligible playback devices by relative signal strength (e.g., SNR) and then select the highest-ranked swap-eligible playback device as the source or target of the swap.

[0178] As shown in FIG. 9, headphones 710a detect audio chirps from playback devices 110n and 110g in bathroom 101a and bedroom 101c, respectively. However, headphones 710a did not detect audio chirps from playback device 110b. This is likely because audio chirps 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, a comparison of the metrics between the audio chirps emitted by playback device 110n and playback device 110g reveals that the audio chirp emitted by playback device 110n is "loudest," so playback device 110n is determined to be the closest playback device.

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

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

[0181] In some particular examples, a touch-and-hold (long touch) or a continuous touch-and-hold on a particular area of ​​the touch-sensitive area (e.g., play / pause area) triggers a swap. To illustrate, FIG. 10 is a chart showing an example control scheme for a portable playback device 710c, a playback device 110, and headphones 710a. As shown in FIG. 10, a user can provide a press input (a.k.a., touch) on the touch-sensitive area to perform a primary action (i.e., play or pause). If a physical button is available for swapping, the user can press and hold the physical button to invoke the swap.

[0182] For example, if the user continues to hold the press input (touch and hold, long touch), the secondary action is executed. For the portable playback device 710c and the playback device 110, the secondary action is to group with nearby playback devices. That is, for the leading playback device (i.e., the portable playback device 710c or the playback device 110), form a synchronous group with nearby playback devices. Separately, for the headphones 710a, the secondary action is to perform a push swap or pull swap as described in connection with FIG. 8A-FIG. 8C. This configuration allows the user to access the swap function more quickly when using the headphones 710a. Because the wearable playback device is designed for relatively private listening 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 scheme.

[0183] If the user continues to hold the press input further (touch and continued hold, long touch continued hold), a tertiary action is executed. For the portable playback device 710c and the playback device 110, the tertiary action is to perform a push swap or pull swap with a nearby playback device. For the headphones 710a, no tertiary action is configured. Other exemplary control schemes may configure a tertiary action for the headphones 710a. In some examples, continuing to hold the touch after the last action in the chain can cancel the input.

[0184] For the user, this control scheme provides an 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 user provides the trigger input to the first playback device. However, the user may have less confidence that the lead playback device has correctly identified 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 lead playback device has the potential to identify a different playback device as the source or target than the user intended, possibly due to the unique acoustic characteristics of the environment that cause an audio chirp emanating from a more distant playback device to appear closest.

[0185] Using this control scheme, when a press and hold input is made to the portable playback device 710c or the playback device 110 (in the case of a long press that the user continues to hold), a swap may result in a grouping between the source and destination sides, causing synchronous loud audio playback between the source and destination sides after the swap. In particular, when the lead playback device has an ongoing playback session, a push group is performed, whereby the lead playback device and the nearby playback devices synchronously play back the ongoing playback session. Conversely, when the lead playback device does not have an ongoing playback session, a pull group is performed, whereby the lead playback device and the nearby playback devices synchronously play back the ongoing playback session of the nearby playback device. This synchronous playback of loud audio provides the user with a preview of the source and destination sides of the swap that would occur if the user continued to hold the input. If the "previewed" playback device in the group is different from the user's desired swap source or destination, the user can make an input to cancel the group or to cancel the swap action.

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

[0187] In some examples, the portable playback device 710c may similarly traverse (reject) the list of group-eligible playback devices via successive touch-and-hold inputs. The group-eligible playback devices may be the same as the swap-eligible playback devices and may be identified using the same or similar audio-based identification techniques. For example, to push / pull the group with the closest playback device 110, the user may provide a first touch-and-hold input to the playback device 710c. To push / pull the group with the next-closest 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 may further traverse (reject) the ranked list of swap- and / or group-eligible playback devices in ranked order from closest to furthest. After the threshold period, the user must begin the input sequence again to perform the grouping.

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

[0189] To help the user understand the control scheme, the source and / or target playback devices can provide feedback including audio and / or visual feedback. To illustrate, FIG. 11, FIG. 10 are charts showing an example feedback scheme for the portable playback device 710c and the playback device 110. As shown in FIG. 11, at each stage of the control scheme, in association with each operation, the leading playback device (portable playback device 710c), which is the source in this example, provides audio and / or visual feedback. Furthermore, 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 own 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 of the pull or push swap, respectively, the lead playback device transitions the playback session from the source playback device to the target playback device. In an exemplary implementation, the swap includes forming a synchronous group that includes the source playback device and the target playback device. Exemplary synchronous grouping is described in more detail in Sections III and IV above. Upon forming the synchronous group, the target playback device begins playing the audio content in synchronization with the source playback device. The source playback device may then be removed from the synchronous group completing the swap. The source playback device may be removed or ungrouped from the synchronous group by sending a command to the target device to ungroup from the source playback device.

[0191] In another exemplary implementation, 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 current playlist, track, offset, etc. In yet another exemplary implementation, in a push swap, the lead 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] 8A , to push a playback session from headphones 710a to playback device 110b, headphones 710a form a synchronization group that includes headphones 710a and playback device 110b, thereby causing headphones 710a and playback device 110b to play the playback session synchronously. To end the push swap, headphones 710a leaves the synchronization group.

[0193] In the example of Figure 8A, the playback session is initiated on headphones 710a, so headphones 710a may initially act as the source device for the synchronous group. As described above, the source device or group coordinator captures the audio for the synchronous group. After headphones 710a leave the synchronous group, playback device 110b may take on the role of the source device.

[0194] In some examples, playback may be manipulated by the source or target playback device during the swap to avoid the user being confused by audio playback during the swap. For example, the playback session may be paused upon the creation of the synchronous group and then resumed after headphones 710a leave the synchronous group. In other examples, either headphones 710a or playback device 110b, or both, may be muted until the swap is complete. In yet another example, headphones 710a may continue playback for x seconds (e.g., 1, 2, 3 seconds, etc.) before pausing to allow for any delays in transitioning the playback session to the target playback device. Other examples are possible as well.

[0195] 8B, to pull the playback session from playback device 110b to headphones 710a, headphones 710a forms a synchronization group that includes headphones 710a and playback device 110b, thereby causing headphones 710a and playback device 110b to play the playback session synchronously. To end the push swap, playback device 110b leaves the synchronization group.

[0196] 8B, the playback session begins on playback device 110b, so playback device 110b may initially act as the source device for the synchronous group. As described above, the source device or group coordinator captures the audio for the synchronous group. After playback device 110b leaves the synchronous group, headphones 710a may take on 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 a source device. This would normally cause the source and target playback devices to play content in sync, but in these examples, the source playback device is placed in a muted state. Because the source playback device is muted, the playback session appears to have been swapped from the user's perspective. This may be a true mute, disabling or placing certain components, such as audio amplifiers, in a low power state, reducing power consumption compared to loud audio playback when not muted.

[0198] VII. Exemplary Home Theater Swap Techniques In some examples, a user may wish to migrate a playback session from a soundbar playback device to a wearable playback device to enable more private listening of audio from a television or other home theater source. Exemplary soundbar playback devices include playback device 110h (FIGS. 1K and 1J). A soundbar 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 source via an audio input interface. In addition, a soundbar playback device can operate as a source device for a combined zone that includes one or more satellites that can play a particular channel (e.g., playback devices 110j and 110k) and / or a particular frequency range (e.g., playback device 110i), as shown in FIG. 1K and FIG. 1J showing den 101d. Although the soundbar playback device implements a bar-shaped housing with multiple audio drivers arranged linearly along the front surface, a soundbar playback device does not necessarily have to have a bar-shaped housing.

[0199] An exemplary sound bar 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 sound bar playback device receives audio from a physically connected source (e.g., a television) via an audio input interface. When streaming audio via a network interface, the sound bar playback device can be considered to be in a music mode. Note that the streaming audio does not necessarily have to be music, but may be other types of streaming audio content, such as, for example, podcasts or news programs. When streaming audio content in the music mode, the sound bar playback device can perform swapping in the same or similar manner as described in Section VI.

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

[0201] In some cases, the wearable playback device initiates a swap mode. Figure 12A is an example message flow diagram showing instructions exchanged between headphones 710a, one or more satellites (den 101d) in a combined zone that includes soundbar playback device 110h (shown as playback devices 110j, 110k, and 110i as shown in Figure 1K), and one or more group members (if the combined zone is in a zone group that includes any additional zones) in an example swap mode initiated by headphones 710a.

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

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

[0204] Then, at 1283a, the headphones 710a transmit data representing the instruction received by the soundbar playback device 110h to enter the swap mode to the soundbar playback device 110h. The headphones 710a and the soundbar playback device 110h can transmit and receive data representing the instruction via their respective 802.11-enabled network interfaces. The headphones 710a may transmit this data based on receiving a playback session swap input.

[0205] Based on receiving the data representing the command to enter the swap mode, the sound bar playback device 110h transitions from the home theater mode to the swap mode. More specifically, at 1284a, the sound bar playback device 110h adds the headphones 710a to a combined zone, which may 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 playback device 110h and the satellites operate as nodes in 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 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 soundbar playback device 110h transitions its 802.11-enabled 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., the 5 GHz band). The soundbar playback device 110h then transmits data representing a 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-enabled 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 soundbar playback device, the soundbar playback device 110h forms a combined zone including the soundbar playback device 110h and the headphones 710a. This may be considered to be the same combined zone as the den 101d, or may be considered to be a new combined zone. At 1285a, after connecting to the first WLAN, the headphones 710a send a message to the sound bar playback device 110h to start streaming the HT audio stream.

[0208] Further, in some examples, while in swap mode, the headphones 710b effectively become satellites of the soundbar playback device 110h. Thus, the soundbar playback device 110h "parks" the satellite playback devices 110j, 110k, and 110i on a second wireless LAN in a second radio frequency band (e.g., the 2.4 GHz band) since the satellite playback devices 110j, 110k, and 110i are not playing audio. By parking the satellites on the second LAN, the satellites can remain in communication (e.g., to eventually re-form a bonding zone when transitioning back to home theater mode) and receive updates (e.g., state variable events) regarding the state of the media playback system 100. The soundbar playback device 110h can configure this second wireless LAN using its 802.11-enabled network interface.

[0209] At 1286a, sound bar playback device 110h stops streaming HT audio streams to satellites (e.g., 110j, 110k, and 110i). This may be performed as part of or in conjunction with parking satellite playback devices 110j, 110k, and 110i on the second WLAN. Similarly, at 1287a, sound bar playback device 110h may stop streaming HT audio streams to group members, if any. By forming a new combined zone at 1284a, sound bar playback device 110h may be removed from any existing zone groups, thereby causing the group members to stop receiving the HT audio streams.

[0210] At 1288a, the sound bar playback device 110h streams the HT audio stream to the headphones 710a for playback. In conjunction with the headphones 710a receiving the stream and playing the audio, the sound bar playback device 110h mutes and completes the swap. When muted, the sound bar playback device 110h can continue processing audio data for playback in sync with the headphones 710a. The HT audio stream may include data representing a binding 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 sound bar 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 as many channels as supported by the wearable or portable playback device.

[0211] During the swap mode, the soundbar playback device 110h can detect an event representing a trigger to transition from operating in the swap mode to operating in the home theater mode. Such an event may include receiving data representing an instruction to transition to the home theater mode (e.g., to exit the swap mode) from the headphones 710a, which the headphones 710a may send while in the swap mode after receiving a playback session swap input. As another example, the soundbar playback device 110h may 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 hours. Based on the detection of such an event, the soundbar playback device 110h can transition to the home theater mode.

[0212] Transitioning from the swap mode to the home theater mode may include the soundbar playback device 110h transitioning its 802.11-enabled network interface from operating as an access point to operating as a node of a mesh network. The soundbar playback device 110h may also connect the satellite playback devices to the mesh network. Furthermore, the soundbar playback device 110h may re-form a combined zone including the soundbar playback device 110h and the satellite playback devices 110j, 110k, and 110i.

[0213] Still further, while in swap mode, additional wearable playback devices can connect to the soundbar playback device 110h as satellites. This allows, for example, two partners to listen to television audio using their individual wearable devices in the den 101h without waking a child sleeping in the 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, which causes the second wearable playback device to send data to the soundbar playback device 110h representing an instruction to enter swap mode. The soundbar playback device 110h then joins the second wearable device using the technique shown in FIG. 12A.

[0214] In some cases, the control device initiates a swap mode. Figure 12B is an exemplary message flow diagram showing instructions exchanged between the control device 130a, headphones 710a, sound bar playback device 110h, and one or more satellites of a combined zone (den 101d) with the sound bar 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 plays audio from the audio input interface in the home theater mode. As a source device of a combined zone including a satellite, the sound bar type playback device 110h is a master device that distributes audio to the satellite in the home theater mode according to its role in the combined zone. Also, when the den 101d belongs to a zone group with one or more other zones, the sound bar type playback device 110h distributes full-range audio content to group members of the zone group as a source device of the zone group.

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

[0217] Then, at 1283b, the control device 130a sends a swap command to the headphones, which in turn sends an instruction to the soundbar playback device to enter swap mode. Alternatively, the control device 130a sends data representing an instruction to enter swap mode to the soundbar playback device 110h, which is received by the soundbar playback device 110h. The control device 130a and the soundbar playback device 110h can transmit and receive data representing the instruction via their respective 802.11-enabled network interfaces. The control device 130a may send this data based on receiving a playback session swap input.

[0218] Based on receiving the data representing the command to enter the swap mode, the sound bar playback device 110h transitions from the home theater mode to the swap mode. More specifically, at 1284b, the sound bar playback device 110h adds the headphones 710a to a combination zone, which may be the same combination zone as the den 101d (e.g., identified as "den" or a new combination 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 soundbar playback device 110h and the satellites operate as nodes of a mesh network. To facilitate adding the headphones 710a to the combined zone, the soundbar playback device 110h transitions its 802.11-enabled 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., the 5 GHz band). The soundbar playback device 110h then transmits data representing the service set identifier (SSID) of the first wireless LAN and (ii) a certificate for the first wireless LAN to the first wearable playback device via the 802.11-enabled 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 WLAN formed by the soundbar playback device, the soundbar playback device 110h forms a combined zone including the soundbar playback device 110h and the headphones 710a. This may be considered to be the same combined zone as the den 101d, or may be considered to be a new combined zone. At 1285b, after connecting to the first WLAN, the headphones 710a send a message to the soundbar 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 playback device 110h.

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

[0222] At 1287b, sound bar playback device 110h stops streaming the HT audio stream to the satellites, which may be performed as part of or in conjunction with parking satellite playback devices 110j, 110k, and 110i on the second Wi-Fi.

[0223] At 1288b, the sound bar playback device 110h streams the HT audio stream to the headphones 710a for playback. In conjunction with the headphones 710a receiving the stream and playing the audio, the sound bar playback device 110h mutes and completes the swap. The HT audio stream may include data representing a join 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 sound bar playback device 110h may downmix the surround sound audio track to an audio track having fewer channels, such as a stereo audio track.

[0224] VIII. Exemplary Swap Methods Methods 1300A, 1300B, 1400, and 1500 illustrated in Figures 13A, 13B, 14, and 15 present exemplary swapping techniques according to exemplary embodiments described herein. These exemplary techniques may be implemented within an operating environment including, for example, the media playback system 100 of Figure 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, as well as other devices described herein and / or other suitable devices. Furthermore, the operations illustrated as being performed by the media playback system may be performed by any suitable device, such as a playback device or a control device of the media playback system. Methods 1300A, 1300B, 1400, and 1500 may include one or more operations, functions, or actions as illustrated by one or more of the blocks illustrated in Figures 13A, 13B, 14, and 15. Although the blocks are shown in sequential order, these blocks may also be performed in parallel and / or in orders different from those described herein. Additionally, various blocks may be combined into fewer blocks, divided into additional blocks, and / or removed based on the desired implementation.

[0225] Further, for the embodiments disclosed herein, the flow chart illustrates the functions and operations of one possible implementation of the present embodiment. In this regard, each block may represent a module, segment, or portion of program code, including one or more instructions executable by a processor to perform a particular logical function or step in a process. The program code may be stored in any type of computer-readable medium, such as a storage device, including, for example, a disk or hard drive. The computer-readable medium may include non-transitory computer-readable media, such as, for example, a register memory, a processor cache, and a computer-readable medium that stores short-term data, such as a random access memory (RAM). The computer-readable medium may also include non-transitory media, such as, for example, a secondary or permanent long-term storage device, such as a read-only memory (ROM), an optical or magnetic disk, a compact disk read-only memory (CD-ROM), and the like. The computer-readable medium may also be any other volatile or non-volatile storage system. The computer-readable medium may be considered, for example, a computer-readable storage medium, or a tangible storage device. In addition, in the embodiments disclosed herein, each block may represent a circuit that is wired to perform a particular logical function in a process.

[0226] a. How to pull an example swap Method 1300A illustrates an example pull swap technique. A portable playback device, such as headphones 710a, earbuds 710b, or portable playback device 710c, can perform a pull swap technique to pull audio content in a playback session of playback device 110 to the portable playback device.

[0227] At 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, the playback session swap input can initiate a pull swap between portable playback device 710 and one or more source playback devices when portable playback device 710 is not currently playing audio content. In some examples, portable playback device 710 receives the playback session swap input via a user interface. For example, headphones 710a may receive a touch-and-hold input as described in connection with FIG. 10. Alternatively, portable playback device 710c may receive a continuous touch-and-hold input. In a further example, 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] At block 1304A, method 1300A includes identifying one or more source playback devices in the 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 also play audio content in the playback session. As discussed 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 the one or more source playback devices may include identifying a set of swap-eligible playback devices in the media playback system and then having the set of swap-eligible playback devices emit respective audio chirps identifying the swap-eligible playback devices to emit. The portable playback device 710 may then detect, via one or more microphones, audio chirps emitted by the one or more swap-eligible playback devices and select one or more source playback devices from among the one or more swap-eligible playback devices based on 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 swap-eligible playback devices. Selecting the one or more source playback devices may include comparing one or more respective metrics of the detected audio chirps emitted by the one or more swap-eligible playback devices to determine that the one or more source playback devices are physically closest to the portable playback device 710 among the one or more swap-eligible playback devices.

[0230] At block 1306A, method 1300A includes swapping the playback session from the source playback device to the portable playback device. For example, the portable playback device 710 may migrate the playback session from the determined one or more source playback devices to the portable playback device 710. Migrating the playback session may include forming a first synchronous group that includes the portable playback device 710 and the one or more source playback devices. By forming the first synchronous group, the portable playback device 710 begins playing a particular audio content of the playback session.

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

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

[0233] At 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, headphones 710a may receive a touch-and-hold input as described in connection with FIG. 10. Alternatively, portable playback device 710c may receive a continuous touch-and-hold input. In a further example, 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] At block 1304B, method 1300B includes identifying one or more source playback devices in the 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 LAN (e.g., network 104 of FIG. 1B) and that also play audio content in the 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 audio-based identification techniques, as described in Section VI. In such examples, identifying the one or more target playback devices may include identifying a set of swap-eligible playback devices in the media playback system and then having the set of swap-eligible playback devices emit respective audio chirps identifying the swap-eligible playback devices to emit. The portable playback device 710 may then detect, via one or more microphones, audio chirps emitted by the one or more swap-eligible playback devices and select one or more target playback devices from among the one or more swap-eligible playback devices based on 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 swap-eligible playback devices. Selecting the one or more target playback devices may include comparing one or more respective metrics of the detected audio chirps emitted by the one or more swap-eligible playback devices to determine that the one or more target playback devices are physically closest to the portable playback device 710 among the one or more swap-eligible playback devices. The comparison may be performed by any device within the media playback system and / or the remote computing system.

[0236] At block 1306B, method 1300B includes swapping the playback session from the portable playback device to one or more target playback devices. For example, portable playback device 710 may migrate its playback session to one or more target playback devices. Migrating the playback session may include forming a first synchronous group that includes portable playback device 710 and the one or more target playback devices. Forming the first synchronous group causes the one or more target playback devices to begin playing particular audio content of the playback session.

[0237] Migrating the playback session can further include stopping playback of the particular audio content on the portable playback device 710. In some examples, playback of the particular 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. Example Home Theater Swap Method Method 1400 illustrates an example home theater swap technique in which a sound bar playback device can perform a home theater swap technique to cause a wearable or portable playback device to play audio received by the sound bar playback device and transmitted to a swap target device.

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

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

[0241] At block 1406, the method 1400 includes transitioning from the home theater mode to the swap mode. The sound bar 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 Figures 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 to the playback device 110h as a satellite, the playback device 110h can transition its 802.11-enabled 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. Furthermore, the playback device 110h can transmit data to the wearable playback device via the 802.11-enabled network interface representing a service set identifier (SSID) of the first wireless LAN and a certificate for the first wireless LAN that the wearable playback device can use to connect to the first wireless LAN.

[0243] Transitioning from the home theater mode to the swap mode may further include forming a second synchronization group including the sound bar type playback device and the wearable playback device. For example, the playback device 110h and the headphones 710a may form a second combined zone after the headphones 710a connect to the first wireless LAN. After forming the second combined zone, the playback device 110h may act as a source device for the second combined zone. In this role, the playback device 110h sends data representing the second synchronization group and audio playback timing information to the headphones 710a. The headphones 710a play 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 play audio.

[0244] Transitioning from the home theater mode to the swap mode may further include parking one or more satellite playback devices on a second Wi-Fi. For example, playback device 110h may cause playback devices 110j and 110k and / or playback device 110i to connect to a second Wi-Fi in a second radio frequency band and leave the first synchronization group.

[0245] In a further example, a soundbar playback device can add one or more additional wearable playback devices to the swap mode simultaneously with the first wearable playback device. For example, while in the swap mode, playback device 110h may receive data from a second wearable playback device, such as earbud 710b or, in other circumstances, headphones 710a, representing an instruction to enter the swap mode. Based on receiving the data representing the instruction to enter the swap mode, playback device 110h causes the second wearable playback device to join the second synchronization group.

[0246] Having the second wearable playback device join the second synchronization group may include transmitting data representing the SSID of the first wireless LAN and a 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 an indication from the second playback device 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 audio playback timing information to the second wearable playback device. The second wearable playback device plays the audio in synchronization with the first wearable playback device based on the playback timing information, as described in connection with Section VI.

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

[0248] At block 1502, the 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, the source playback device or the target playback device detects the swap trigger and initiates the playback session swap. Alternatively, another associated 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 example swap triggers include detecting a user action, such as a user input. For example, the source playback device (e.g., the portable playback device 710) can detect a particular input that represents a swap command and initiate a playback session swap based on the detection of the particular input. As another example, the control device 130 can detect a particular input that represents a swap command and initiate a playback session swap based on the detection of the particular input. Various other examples are possible.

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

[0251] At block 1504, method 1500 includes determining one or more source playback devices and one or more target playback devices. As described above, an example implementation includes swapping playback between one or more portable playback devices 710 and one or more playback devices 110. Portable playback device 710 may act as a source playback device or a target playback device depending on the context. Playback device 110 can 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 the context. For example, if the playback device 710 detects a particular input that represents a swap command, the playback device 710 can initiate a playback session swap as the source playback device based on the detection of the particular input. In another example, if the control device 130 detects a particular input that represents a command to swap playback from the playback device 110, the control device 130 can initiate a playback session swap with the playback device 110 as the source playback device, or can send data to the playback device 110 indicating a command to cause the 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 the portable playback device 710 detects the proximity of one or more potential target playback devices 110, the portable playback device 710 can initiate a playback session swap with the portable playback device 710 as the source playback device. As another example, if the 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, the paired control device 130 or bridge device 860 may initiate a playback session swap with the paired portable playback device 710 as the source playback device, or may send data to the paired portable playback device 710 indicating the proximity of the playback device 110 to cause the 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, the one or more destination devices are determined based on a predefined swap pair with the source playback device. For example, as shown in FIG 11A, kitchen 101h is designated as a predefined swap pair with headphones 710a. As described above, the swap pairs can be configured and / or reconfigured via control device 130 or other suitable device.

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

[0256] Still further, in other examples, the one or more target devices are determined based on the context. For example, the one or more playback devices may detect a particular input indicative of a command to designate the one or more playback devices as the target playback devices. In a further example, the one or more target playback devices are determined based on an association between the target playback devices and a device base. For example, if device base 718a is associated with kitchen 101h, placing portable playback device 710c into 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 destination based on the context, one or more additional playback devices 110 may be determined based on a synchronization grouping between the first playback device 110 and one or more additional playback devices 110. For example, if the playback device 110l in the master bedroom 101b is determined as a destination device, the playback device 110m is also determined as a source playback device based on the combined pair configuration of the playback device 110m and the playback device 110l. In another example, if 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 a source playback device. This facilitates the session swap from all playback devices 110 involved in the playback session.

[0258] At block 1506, method 1500 includes swapping the playback sessions from the one or more source playback devices to the one or more target playback devices. In embodiments, method 1500 may implement any suitable technique for swapping playback sessions, such as the example messaging, cloud queuing, and grouping techniques described in Section V. Other examples are contemplated.

[0259] IX. Exemplary Bridge Devices In some example implementations, a portable playback device, such as headphones 710a, earbuds 710b, or portable playback device 710c, can interface with the media playback system 100 via a bridge device 860. FIG. 16A illustrates an example pairing configuration between headphones 710a and a bridge device 860a. In contrast to a general-purpose smartphone or tablet that includes bridge features when configured as a control device 130, the bridge device 860a is configured with hardware and software to interface the portable playback device 710a with the media playback system 100. The bridge device 860a may also include other features to support or extend the media playback system 100.

[0260] Similar to the control device 130a, the bridge device 860a may include communication interfaces, 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 may utilize some of these features. This arrangement may allow the portable playback device 710a to be smaller and more portable, consume less power, and / or be less expensive, among other possible advantages. For example, similar to the control device 130a, the bridge device 860a may include additional communication interfaces compared to the portable playback device 710a. For example, the headphones 710a may utilize the cellular data connection of the bridge device 860a to connect to the Internet. 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 may be paired with both a mobile device (e.g., a smartphone or tablet, capable of implementing the control device 130 via installation of controller application software) and a bridging device 860. In such an implementation, the portable playback device 710a may 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 includes a connection to the Internet to facilitate the audio streaming, and the bridging device 860 serves as an interface to the media playback system 100.

[0262] In an exemplary implementation, the bridging device 860a is coupled 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, such as the "kitchen+dining room" group. Alternatively, if a home graph hierarchy is utilized, the bridging device 860a may be coupled to a particular set, room, or area. In this case, the control of the playback device 110 coupled to the bridging device 860a via the NMD 120 or the control device 130 also controls the paired portable playback device 710a.

[0263] Alternatively, the bridge device 860a itself may form a zone or set. For example, in one example, the bridge device 860a may be configured as a "Ben's headphones" zone or set. Configuring the bridge device 860a facilitates control of the paired headphones 710a with the NMD 120 and / or control device 130 of the media playback system 100.

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

[0265] 16B, the electronics 812 includes one or more processors 812a (hereinafter referred to as "processor 812a"), memory 812b, software components 812c, a network interface 812d, and power 812i. In some embodiments, the electronics 112 optionally includes one or more other components 812j (e.g., one or more sensors, a video display, a touch screen).

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

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

[0268] The network interface 812d is configured to facilitate the transmission of data between the bridging device 860a and one or more other devices of a data network, such as the link 103 and / or the network 104 (FIG. 1B). In the illustrated embodiment of FIG. 16B, the network interface 812d includes one or more wireless interfaces 812e (hereinafter referred to as "wireless interface 812e"). The 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., the playback device 110, the NMD 120, the control device 130, and / or the portable playback device 710) communicatively coupled to the network 104 (FIG. 1B) according to a suitable wireless communication protocol (e.g., WiFi, Bluetooth, LTE). In some examples, the 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 an Ethernet, USB-A, USB-C, and / or Thunderbolt cable) configured to communicate with other devices via a wired connection according to an appropriate wired communication protocol.

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

[0270] In an exemplary implementation, the command device, in comparison to the control device 130, is configured to control only the paired and / or coupled playback devices, and not the playback devices 110a-n of the media playback system 100 in general. For example, in the example of FIG. 16A where the bridge device 860a is paired with the portable playback device 710a, playback commands issued at the command device 862a are executed at the portable playback device 710a. Furthermore, when the bridge device 860a is coupled to one or more playback devices 110, playback commands issued at the command device 862a are also executed at the coupled playback device 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 about the base of the housing 816a, as shown in FIG. 16C. Clockwise and counterclockwise rotation of the dial 863a corresponds to up and down volume adjustment.

[0272] The user interface 813a of the bridge device 860a also includes a touch-sensitive area 864a for facilitating transport control of the paired playback device 710 and / or the coupled playback device 110, as shown in FIG. 16D. The touch-sensitive area 864a is formed on the top surface of the housing 816a, as shown in FIG. 16C. The touch-sensitive area 864a may be implemented as a capacitive or resistive touch-sensitive area, among other examples. In this example, a touch input to the center of the touch-sensitive area 864a is interpreted as a play / pause toggle. The touch-sensitive area 864a may also interpret certain inputs as fast-forward and rewind skips. For example, touch inputs to the right and left sides of the touch-sensitive area 864a may be interpreted as fast-forward skips and rewind skips, respectively. Alternatively, a left-to-right swipe gesture on the touch-sensitive 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 implementations, the user interface 813a of the bridge device 813a is intentionally limited to a certain subset of playback commands compared to the “full-featured” controls supported by the control device 130. As shown in Figures 16C and 16D, such a subset may include volume and transport controls (and perhaps only certain transport controls). Such a simplified, minimal user interface may improve the user experience of the paired playback device 710 or the coupled playback device 110 by reducing discomfort, among other possible benefits.

[0274] In embodiments of the command device 862a that exclude library and / or search controls for selecting audio content for playback, initiating playback via the command device 862a can initiate a particular audio repository. The particular audio repository may be pre-configured by the user via the control device 130 or may be automatically selected by the media playback system. Exemplary audio repository locations 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-sensitive area 864b on the top surface of the housing 816b, and buttons 865a-d on the front of the housing 816b. Like the dial 863a, the dial 863b facilitates volume control of the portable playback device 710 paired to the bridge device 860b and / or the playback device 110 coupled to the bridge device 860b. Additionally, the touch-sensitive area 864b facilitates transport control of the paired portable playback device 710 and / or the coupled playback device 110, like the touch-sensitive area 864a.

[0276] Buttons 865a-d correspond to respective audio storage locations. A particular audio storage location may be pre-configured by a user via control device 130 or may be automatically selected by the media playback system (e.g., based on user-specified favorites or listening frequency). Selection of a particular button 865 causes the paired playback device 710 and / or coupled playback device 110 to begin playing the corresponding storage location, similar to how a radio preset tunes a radio to a corresponding radio station.

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

[0278] In some implementations, the bridge device 860 may include a graphical display. In such examples, the user interface 813 of the bridge device 860 may include a graphical user interface that is 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. Additionally, the graphical user interface may reduce discomfort caused by the presence of a graphical display and may have limited playback control compared to the control devices 430 and 530, among other possible advantages.

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

[0280] The first user interface display 1770a includes a number of regions 1771a-f similar to the buttons 865a-d (FIG. 8F). In the first user interface display 1770a, the regions 1770a-g are selectable via touch input to the respective regions. Each region 1771 corresponds to a respective audio repository. A particular audio repository may be pre-configured by a 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 audio repository locations include Internet radio stations, playlists, albums, podcasts, as well as other streaming audio content. Upon selection of a particular button 865, the paired playback device 710 and / or the coupled playback device 110 begins playback of the corresponding repository.

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

[0282] When a particular region 1771 (e.g., region 1771a) is selected, the bridge device 860 causes the paired playback device 710 and / or the coupled playback device 110 to start playing the corresponding storage location. When region 1771a is selected again while a storage location is playing, the bridge device 860 causes the paired playback device 710 and / or the coupled playback device 110 to stop playing the corresponding storage location. In this manner, region 1771 functions as a play / pause button.

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

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

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

[0286] The second user interface display 1770b may further include navigation controls. By way of example, the second user interface display 1770b includes navigation controls 1774a and 1774b. The navigation control 1774a causes the bridge device 860 to display the first user interface display 1770a. The navigation control 1774b causes the bridge device 860 to display the third user interface display 1770c, which includes a queue.

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

[0288] In some implementations, the graphical user interface facilitates selection of a portable playback device 710 for pairing with the bridge device 860 and / or the playback device 110 for coupling with the command device 862. To illustrate, 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. Switching the 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 such that the headphones 710a are paired with the bridge device 860.

[0289] Selecting multiple zone names will form a zone group between the zones (if not already formed) and pair the bridge device 860 with the zone group (thereby controlling all playback devices 110 in the zone group). Selecting the "All" toggle will put the media playback system 100 into party mode (where all playback devices 110 play music in sync) and pair the bridge device 860 with all playback devices 110 in the media playback system 100.

[0290] In an exemplary embodiment, the bridge device 860 charges one or more batteries via placement in the device base 718. FIG. 18A illustrates placement of the bridge device 860a in the device base 718b. The bridge device 860a can interact with the device base 718b in the same or 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 in the device base 718b will cause the bridge device 860a (and the paired portable device 710) to join the associated zone.

[0291] In an exemplary implementation, 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, rotation of the bridge device 860a relative to the device base 718b also controls the volume of the playback device 110 joined to the bridge device 860a. Similar to the bridge device 718a, the bridge device 860a can rotate relative to the device base 718b and generate a volume control signal to 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. Rotation of these two portions generates a volume control signal at a sensor of the device base 718b that controls the volume of the paired playback device 710 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 may support charging of the portable device 170. To illustrate, 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 earbuds 710b via a charging case 1080. Similar to the device base 718, the bridge device 860a may charge the earbuds 710b via inductive charging or conductive terminals. In some implementations, the device base 718b may directly charge the earbuds 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] 18C shows another exemplary stacking configuration to facilitate charging of devices. In this example, the device base 718a charges the portable playback device 710c. The portable playback device 710c charges the bridge device 860a. The bridge device 860a charges the earbuds 710b via the charging case 1080. In this configuration, only the device base 718a requires external power to charge the various stacked devices.

[0294] X. Additional Swap Examples In some examples, the source and target of the swap are predefined. For a given swap pair, the source is the playback device 710 or one or more playback devices 110 that are playing the audio content, and the target is another playback device that is not playing the 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 the swap pair triggers the swap. For example, a particular input to the user interface 713a of the headphones 710 (FIG. 7B), such as a tap or gesture on a touch-sensitive area (or a portion thereof), may trigger the swap. In a further example, the portable playback device 710 may include a physical button for triggering the swap. Still further, a pattern of touch input (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 input are also contemplated.

[0296] Additionally or alternatively, an input to the target device triggers the swap. For example, a particular input to the user interface 113 of the playback device 110a (FIG. 1C) may trigger the swap. In a further example, the playback device 110 may include a physical button for triggering the swap. Actuating the button (e.g., by selecting, touching, sliding, etc.) triggers the swap. Other types of input are also contemplated.

[0297] In an example, a user interface, 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 the predefined swap pair. To illustrate, 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 display on the control device 430 as an example, but may be adapted to display on other example devices disclosed herein. The control device 430 may display the first user interface display 1931a during a setup procedure for the headphones 710a. Additionally, a user may display the first user interface 1931a via a setup user interface display, among other examples.

[0298] As shown, the first user interface display 1931a includes a graphical representation of the zones in the media playback system 100 (i.e., the zone names) and a toggle control corresponding to each zone. Switching the toggle control configures the corresponding zone 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 controls may be used in other embodiments. The exemplary user interface may include functionally similar user interface displays for defining swap pairs for other portable playback devices 710 of the media playback system 100 (e.g., the earbuds 710b and / or the portable playback device 710c). The predefined swap pairs may be stored in the data storage of the control device 130, the playback device, and / or the portable playback device 710, possibly as one or more state variables shared between these devices.

[0299] Alternatively, if a home graph hierarchy is implemented, a similar user interface display may include a graphical representation of the sets, rooms, and / or areas of the home graph configured in media playback system 100. This user interface display may 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 headphone 710a.

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

[0301] A user can define a custom input corresponding to a predefined swap pair. To illustrate, FIG. 19C presents a third user interface display 1931c for facilitating the definition of a custom gesture. As shown, the third user interface display 1931c includes a prompt for providing the custom gesture. After initiating a press, the swap pair earbud 710b and 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 data storage.

[0302] In a further example, placing the 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, a swap goal is predefined for the portable playback device 710c.

[0303] Alternatively, the device base 718a may be bound to one or more specific zones. Placing the portable playback device 710c on the device base 718a then triggers a swap to one or more specific zones. Further details regarding binding zones to device bases can be found, for example, in U.S. Pat. No. 9,544,701, entitled "Base Properties in a Media Playback System," which, as noted above, is incorporated herein by reference in its entirety.

[0304] In a further example, an input to a user interface of the device base 718a can trigger a swap. Exemplary inputs include a button press (or other action) or a touch input to a touch-sensitive area, similar to the exemplary inputs described above. For example, certain gestures 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 NMD 120a triggers the swap. For example, the user may utter a voice input "swap to kitchen." As described above in connection with FIGS. 3A-3D, the user may activate a voice assistance service to process the voice input via a wake-up word or a button press (e.g., push-to-talk). The voice input includes a first command indicating an action ("swap") and a second command indicating a target playback device for the action ("kitchen"). Here, the voice input is sent to the voice assistance service for processing, as described above in connection with FIGS. 3A-3D. In some cases, instructions corresponding to the processed voice command are sent back to the source playback device or the target playback device to cause the playback session swap to be performed. Alternatively, instructions corresponding to the processed voice command are forwarded to a server to cause the playback session swap to be performed, as described in further detail below in connection with FIGS. 12B and 12C. Following the swap, the NMD 120a may audibly confirm the swap with a voice response such as "<audio content name> is now playing in the kitchen."

[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 begins playing the audio content previously playing on the target and the target begins playing the audio content previously playing on the source. Alternatively, the playback session of the source playback device is swapped to the target playback device and playback on the target is stopped.

[0307] In an exemplary implementation, 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 the source of the audio content (e.g., a URI or URL indicating the location of the audio content) and an offset indicating a position in the audio content to begin playback. The offset can be defined as a time (e.g., in milliseconds) from the beginning of the audio track or as a number of samples, among other examples. In an exemplary implementation, the offset can be set to a playback position in the audio content at the current playback position to enable the time for the target device to begin 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 may further include one or more identifiers corresponding to the playback session. For example, the playback session data may include a session identifier that distinguishes the playback session from other playback sessions. The playback session data may also include an application identifier that identifies the media playback system controller application software that controls the playback session. Additionally, the playback session data may include a streaming audio service identifier that identifies a streaming audio service that hosts 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 may 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 may identify a zone, a combined zone, or a zone group of devices.

[0309] The play session data may further include data representing a play state. The play state may include a play state of the session (e.g., playing, paused, or stopped). If the play session implements a play queue, the play session data may include a play queue state, such as the current play position in the queue.

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

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

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

[0313] At 2081a, the source playback device initiates a playback session. The playback session may be initiated at the source playback device, the control device 130, or the bridge device 860, among other examples. In some cases, the playback session may include one or more additional playback devices that play synchronously with the source playback device as part of a group.

[0314] At 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 to the source playback device indicating that the swap trigger was detected.

[0315] At 2083a, the source playback device transmits playback session data to the target playback device. As an example, the playback session data includes data representing a URI indicating a source of audio content currently being played in the session (e.g., a currently playing audio track). The playback session data also includes data representing an offset in the audio content indicating a location in the audio content to begin playback. In addition, 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 a URI corresponding to each media item in the queue, as well as an order of the queued media items. Additionally, the playback session data includes one or more identifiers, as described above.

[0316] At 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 may include a URI indicating a source of the audio content at the content server. The fetch message may further include an offset. The fetch message may also include other data, such as one or more identifiers and / or authentication data.

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

[0318] At 2086a, the target playback device sends an acknowledgement message to the source playback device after receiving the playback session data. In an example implementation, the source playback device may not stop the playback session until it receives an acknowledgement message from the target playback device. The acknowledgement message may indicate that the swap was successful.

[0319] Another example implementation utilizes a cloud queue to facilitate playback session swapping. In contrast to the queue (i.e., local queue) of the playback device 110's data storage, the cloud queue of the playback session is maintained in the cloud of the computing device 106. In this implementation, rather than 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 manipulating 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 illustrate, FIG. 20B is an exemplary message flow diagram showing instructions exchanged between the source playback device, 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 may include additional or fewer messages. In some implementations, the messages are not sent 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] At 2081b, the source playback device initiates a playback session. The playback session may be initiated at the source playback device, the control device 130, or the bridge device 860, among other examples. In some cases, the playback session may include one or more additional playback devices that play synchronously with the source playback device as part of a group.

[0322] At 2082b, 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 to the source playback device indicating that the swap trigger was detected.

[0323] At 2087, the source playback device sends a swap session message to the cloud queue server including the playback session data. The swap session message can indicate the target playback device via one or more identifiers. In some examples, such as predefined swap pairs, the cloud queue server can maintain predefined swap pairs for media playback system 100. The swap session message can also include data representing an offset in the audio content indicating a location in the audio content to begin playback. In examples, the cloud queue 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. Still further, the swap session message can include a home identifier that identifies media playback system 100 (to distinguish it from other media playback systems in other homes) and one or more player identifiers to identify the source and / or target playback device.

[0324] Based on receiving the swap session message, the cloud queue server retargets the session from the source device to the target device. For example, the cloud queue server may use the home identifier in the playback session data to identify the cloud queue of the media playback system 100, and then use the group identifier (or queue identifier) ​​to identify the cloud queue utilized in the playback session. The cloud queue server may swap the session to the target playback device modifying the cloud queue data to associate the cloud queue with the target playback device. Alternatively, the cloud queue server may mirror the cloud queue of the source device with the cloud queue of the target playback device, and then set the playback state of the cloud queue to match the playback state indicated in the playback session data.

[0325] For example, at 2088, the cloud queue server transmits playback session data to the target playback device. The playback session data includes data representing a URI indicating a source of the currently playing audio content in the session (e.g., the currently playing audio track). The playback session data also includes data representing an offset in the audio content indicating a location in the audio content to begin playback. In addition, if the source playback device is playing audio content from a cloud queue having multiple audio tracks, the playback session data may further include data representing a window from the cloud queue. The window may indicate media items after the currently playing audio content, as well as possibly media items before the currently playing audio content. The target playback device may queue this window in its local queue to facilitate further playback of the cloud queue in the transferred session.

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

[0327] FIG. 20C is an example message flow diagram showing instructions 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, which may be implemented by one or more cloud servers) during another example swap of a playback session. Such messages are representative and may include additional or fewer messages. In some implementations, the messages are not sent 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] At 2081c, the source playback device initiates a playback session. The playback session may be initiated at the source playback device, the control device 130, or the bridge device 860, among other examples. In some cases, the playback session may include one or more additional playback devices that play synchronously with the source playback device as part of a group.

[0329] At 2082c, 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 to the source playback device indicating that the swap trigger was detected.

[0330] At 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 may also include a URI indicating a source of the audio content and an offset within that content.

[0331] At 2089, the target playback device sends a swap session request to one or more servers. In a cloud queue implementation, the swap session request may be in the form of a load queue request indicating instructions to load the current cloud queue state of the cloud queue being played by the source playback device onto 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 streaming of the 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 a cloud queue server to create a new session on the target playback device. The 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 on the target playback device.

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

[0334] In 2086b, the target playback device sends an acknowledgement message to the source playback device after receiving the playback session data. In an example implementation, the source playback device may not stop the playback session until it receives an acknowledgement message from the target playback device. The acknowledgement message may 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 mentioned above, the example playback device 110 and / or playback device 710 may dynamically form and transform synchronization groups. As mentioned above, further details regarding audio playback synchronization between 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 incorporated herein 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 begins 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 muting can be a hidden (e.g., system) mute that is distinct from a mute command via a user interface. A hidden mute may be performed by lowering the volume or setting the volume to 0 on the source device while displaying in the user interface that the source device is not muted and playback is paused.

[0337] To swap playback back to the source playback device, the target playback device is removed from the synchronization group. A possible advantage of this implementation is that the session can be swapped back to the source device with relatively little delay, since the audio content does not need to be buffered again. 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 a source playback device and a target playback device triggers a swap. For example, detecting that the source and target playback devices of a given swap pair are in proximity can initiate a swap of playback sessions between the source and target playback devices. In some implementations, the source and target playback devices of a swap are defined by the proximity of the source and target playback devices. Exemplary proximity detection may be performed in one or more areas, such as proximity to 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 in the home. In an example, when a 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 in the home.

[0340] To illustrate, in an exemplary implementation, the paired control device 130a (FIG. 7G) detects wireless signals indicative of 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 in-home 802.11 network (e.g., network 104) via the network interface 132d. Because the playback devices 110a-n are connected to network 104, the detection of this network indicates the proximity of the paired control device 130a (and, by proxy, the paired portable playback device 710) to the home. Other exemplary wireless signals include near field communication (NFC) and 802.15 (Bluetooth, Bluetooth low energy) signals that may be transmitted by the in-home playback devices 110a-n. In other examples, the paired bridge device 860 (FIG. 16A) may detect such signals, or the portable playback devices 710 may detect the signals directly 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 may include a GPS sensor and compare current GPS coordinates to stored GPS coordinates of the home (or other known locations of the playback devices 110a-n) to determine whether the paired control device 130a is in proximity to this stored location. In a further example, the paired control device 130a may 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 may utilize a camera to detect known objects or signals in the home. Other examples are possible as well.

[0342] In some examples, verification from a user is required before performing a playback session swap based on proximity. In some examples, the verification is performed via an input to a user interface of the source portable playback device 710 (or 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 including 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 multiple selectable controls. The first selectable control ("Swap") causes the paired control device 130a to perform a playback session swap between the headphones 710a ("Ben's headphones") with the kitchen 101h, which may be a predefined swap pair (FIG. 11A) or the closest playback device 110, among other examples. The second selectable control ("Cancel") cancels the proximity-based swap.

[0344] Also shown in FIG. 21A are selectable controls 2192a and 2193b. Selectable control 2192a causes kitchen 101h to continue a stopped playback session (e.g., playing a podcast) rather than transferring the ongoing playback session. In an exemplary implementation, selectable control 2192a may represent the last stopped playback session on portable playback device 710a, the last stopped playback session on kitchen 101h, or the last stopped playback session on media playback system 100, among other examples. Alternatively, push notification 2191a may include multiple 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, the example push notification 2191 can include selectable controls 2193 for starting a new playback session at various types of audio repositories corresponding to the user. For example, each selectable control 2193 can start a new playback session with a favorite playlist, radio station, podcast, album, or artist, similar to button 865 (FIG. 16E) and / or area 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 display to select a different swap target. To illustrate, Fig. 21B presents a second user interface display 2131b for facilitating selection of a swap target. The user interface display 2131b includes a number of toggle controls corresponding to respective zones of the media playback system 100 for facilitating selection of one or more target playback devices 110n.

[0347] In some implementations, the proximity of the portable playback device 710 to a zone initiates a playback session swap with a playback device 110 in that zone. Detecting the proximity of the portable playback device 710 to a given zone may include detecting a signal (e.g., radio, ultrasonic) emitted by a playback device in that zone. In some implementations, detection of a signal emitted by another smart device in 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 may detect signals emitted by the playback device 110b, as well as other smart devices (e.g., smart oven, smart refrigerator, smart power outlet), and store these signals as markers for the kitchen 101h in a profile corresponding to the kitchen 101h. The paired control device 130a may also combine this signal data with other sensor data (e.g., altitude) acquired while in the kitchen 101h. The markers in a given profile may also be weighted (e.g., signals of a playback device in a given zone may be weighted more heavily than other smart devices in that zone).

[0349] Given stored profiles of multiple zones of the media playback system 100, to detect whether the portable playback device 710 is in proximity to a given zone, the paired control device 130a can compare current signal and / or sensor data to the stored profiles corresponding to the zone. For example, the paired control device 130a can determine the closest match to 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 threshold markers by determining proximity to a particular zone when a predetermined number (or percentage) of markers in the stored profile for the particular 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 profiles and / or detect proximity using the stored profiles.

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

[0351] Similar to proximity to home, before executing a playback session swap to a zone based on proximity, the media playback system 100 may require verification that the user intends to execute the swap. To illustrate, FIG. 21C presents a third user interface display 2131c including 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 a user input to a playback device of that zone. For example, a particular user input to playback device 710 (or a paired control device 130a or bridge device 860a) can initiate a playback session swap with playback device 710 as the source playback device. User input to a given playback device 110 then selects that playback device (or the associated zone) as the target playback device. The source and target playback devices may be configured to perform the swap on the condition that a second input is detected within a predetermined period (e.g., 5 seconds) after the first input 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 in proximity to the source playback device. To illustrate, FIG. 22A shows an example playback session swap between a portable playback device 710c and a playback device 110e in proximity to the portable playback device 710c. As shown, a specific swap input (e.g., a long press on the 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 illustrates an example of a playback session swap between headphones 710a and a playback device 110e that is in close proximity to the portable playback device 710a. As illustrated, a hold close action triggers the playback session swap. In this example, the source playback device (i.e., headphones 710a) and the target playback device (i.e., playback device 110e) are both identified by the hold close action, which results in a near field communication exchange between the headphones 710a and the playback device 110e. Because near field communication has a limited range (e.g., 4 cm), the near field communication exchange indicates the proximity of the headphones 710a and the playback device 110e.

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

[0356] 22D illustrates another example of a playback session swap between earbud 710b and playback device 110e. In this example, a hold close action by bridge device 860a (paired with earbud 710b) triggers a playback session swap. In this example, the source playback device (i.e., earbud 710b) and the target playback device (i.e., playback device 110e) are both identified by a hold close action, which results in a near field wireless communication exchange between the paired bridge device 860a and 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 "kitchen + dining room" zone group). As mentioned above, an example of a synchronization technique includes a 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 the audio content and timing information to the group members) or a group member (which receives the audio content and timing information from the group coordinator).

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

[0359] Generally, when initiating a playback session swap via the GUI of control device 130a or the VUI of NMD 120a, a combined zone or zone group is targeted as a whole by referencing 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 a group coordinator, which 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 a cloud queue server to have the cloud queue server execute the swap or to relay instructions to the group coordinator to execute the playback session swap.

[0360] In other cases, the group member is the target of the swap (e.g., by making an input in the group member's user interface indicating a swap command). In a local-side implementation, the group coordinator can send one or more messages indicating the swap command to the group coordinator, which then performs the play session swap. In a cloud-side implementation, the group member can send one or more messages indicating the play session swap to the cloud queue server to have the cloud queue server perform the swap or to relay instructions to the group coordinator to perform the play session swap. Alternatively, the group member may send one or more messages indicating the play session swap to the group coordinator, which causes the group coordinator to send a play session swap request to the cloud server.

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

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

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

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

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

[0366] FIG. 23F is a front isometric view of earbud 2310a and earbud 2310b showing an example 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 in accordance with aspects 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 a portable playback device 2410 showing an exemplary arrangement with a device base 2418.

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

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

[0381] FIG. 25B is a first side view of 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 in accordance with an aspect of the disclosed technology.

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

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

[0386] XII. Conclusion The above descriptions of portable playback devices, playback devices, control devices, playback zone configurations, and media content sources are merely examples of some of the operating environments in which the features and methods described below may be implemented. Other operating environments and configurations of media playback systems, playback devices, and network devices not explicitly described herein may also be applicable and suitable for implementing the features and methods.

[0387] The above description discloses various exemplary systems, methods, apparatus, and articles of manufacture that include, among other components, firmware and / or software executing on hardware. It is understood that such examples are merely illustrative and should not be considered limiting. For example, it is intended that any or all of the firmware, hardware, and / or software aspects or components may be embodied exclusively in hardware, exclusively in software, exclusively in firmware, or in any combination of hardware, software, and / or firmware. Thus, the examples provided are not the only ways to implement such systems, methods, apparatus, and / or articles of manufacture.

[0388] Furthermore, reference to an "embodiment" herein means that a particular function, structure, or feature described in connection with an embodiment may be included in at least one exemplary embodiment of the present invention. The appearances of the term in various places in this specification do not necessarily all refer to the same embodiment, nor are separate or alternative embodiments mutually exclusive with other embodiments. As such, the embodiments described herein can be combined with other embodiments, as would be understood, either explicitly or implicitly, by one skilled in the art.

[0389] The present specification has been presented broadly in terms of exemplary environments, systems, procedures, steps, logic blocks, processes, and other symbolic representations that directly or indirectly resemble the operation of network-connected data processing devices. These process descriptions and representations are typically used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. Many specific details have been described to provide a thorough understanding of the present disclosure. However, those skilled in the art will understand that certain embodiments of the present disclosure may be practiced without certain specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail to avoid unnecessarily obscuring aspects of the embodiments. Thus, the scope of the present disclosure is defined by the appended claims, rather than by the description of the embodiments set forth above.

[0390] If any of the appended claims are read to cover purely software and / or firmware implementations, then at least one of the elements in at least one example is expressly defined herein to include a tangible, non-transitory medium, such as memory, DVD, CD, Blu-ray, etc., that stores the software and / or firmware.

[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 transitioning 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: The method of example 1, wherein 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 play the audio content synchronously, and muting the first playback device.

[0393] Example 3: The method of example 1 or 2, wherein 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, and the cloud queue server transfers or transmits the playback session to the second playback device based on the instruction.

[0394] Example 4: The method of any preceding example, wherein transitioning 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.

[0395] Example 5: The method of any preceding example, 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 one or more housings carrying the at least one processor, data storage, one or more amplifiers, one or more transducers, and one or more batteries, wherein the one or more housings are formed into at least one of (a) headphones or (b) earbuds.

[0396] Example 6: The method according to any preceding example, wherein the first playback device is paired with the 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.

[0397] Example 7: The method of any preceding example, wherein detecting a playback session swap trigger includes detecting an input, via a user interface of the control device, representing a command to swap playback sessions.

[0398] Example 8: A method as described in any preceding example, wherein detecting an input representing a command to swap playback sessions includes detecting a touch-and-hold input on a touch sensitive area of ​​the first playback device, where the touch input performs a first action other than swapping.

[0399] Example 9: A method as described in any preceding example, wherein detecting an input representing a command to swap playback sessions includes detecting a touch-and-continued-hold input to a touch sensitive area of ​​the first playback device, where the touch input performs a first action, and the touch-and-hold performs a group action, and the first action is not 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 of example 10, wherein 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.

[0402] Example 12: The method of example 10 or 11, wherein the bridge device comprises a circular housing, and the method includes detecting a 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 of 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 at least one processor, data storage, the one or more amplifiers, the one or more transducers, and the one or more batteries, wherein the housing is formed into a handheld speaker.

[0404] Example 14: The method of example 13, wherein detecting the playback session swap trigger includes detecting that the housing has been placed within the device base.

[0405] Example 15: The method of any preceding example, wherein the second regeneration device eliminates the battery and draws current from wall power.

[0406] Example 16: The method of any preceding example, wherein detecting a playback session swap trigger comprises detecting proximity of a second playback device to a first playback device.

[0407] Example 17: The method of any preceding example, wherein determining one or more target playback devices comprises detecting proximity of a second playback device to the first playback device.

[0408] Example 18: A method as described in any preceding example, wherein the one or more target playback devices further include a third playback device, and determining the one or more target playback devices further includes determining that the third playback device is configured into a synchronization group with the second playback device.

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

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

[0411] Example 21: A tangible, non-transitory computer-readable medium having stored thereon instructions executable by one or more processors to perform 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 in (a) earbuds or (b) headphones, the housings carrying 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 the one or more processors to perform the method described in any of Examples 1 to 18.

[0413] Example 23: A method including a wearable device, the method including: receiving data representing a first playback session swap input; and, based on the receiving of the data representing the first playback session swap input, identifying one or more source playback devices in a media playback system that (a) are connected to a first wireless local area network (LAN) and (b) are playing particular audio content in a playback session, where the wearable playback device is connected to the first wireless LAN via an 802.11 enabled network interface; and transitioning the playback session from the determined one or more source playback devices to the wearable playback device, where transitioning the playback session includes (i) forming a first synchronization group including the wearable playback device and the one or more source playback devices, where forming the first synchronization group includes causing the wearable playback device to start playing the particular audio content of the playback session; and (ii) causing the one or more source playback devices to stop playing the particular audio content.

[0414] Example 24: The method of Example 23, wherein identifying one or more source playback devices includes identifying a set of swap-eligible playback devices of the media playback system; causing the set of swap-eligible playback devices to emit respective audio chirps identifying the emitting swap-eligible playback devices; detecting via one or more microphones the audio chirps emitted by the one or more swap-eligible playback devices; and selecting one or more source playback devices from among the one or more swap-eligible playback devices based on 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 swap-eligible playback devices.

[0415] Example 25: The method described in Example 24, wherein the one or more microphones comprise one or more acoustic noise-canceling microphones carried on one or more outer surfaces of the one or more wearable housings, and detecting audio chirps emitted by the one or more swap-eligible playback devices includes detecting audio chirps emitted by the one or more swap-eligible playback devices via the one or more acoustic noise-canceling microphones.

[0416] Example 26: A method as described in any preceding Example 23 to 25, wherein selecting one or more source playback devices from among the one or more swap-eligible playback devices includes comparing one or more respective metrics of detected audio chirps emitted by the one or more swap-eligible playback devices to determine that the one or more source playback devices are physically closest to the wearable playback device among the one or more swap-eligible playback devices.

[0417] Example 27: The method of any preceding Example 23 to 26, further comprising: receiving data representing a second playback session swap input while playing audio content in the migrated playback session; identifying one or more target playback devices in a media playback system connected to the 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, where migrating the playback session includes (i) forming a second synchronization group including the wearable playback device and the one or more target playback devices, where forming the second synchronization group includes causing the one or more target playback devices to start playing certain audio content of the playback session, and (ii) removing the wearable playback device from the second synchronization group.

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

[0419] Example 29: A method as described in any preceding Example 23 to 28, wherein receiving data representing a playback session swap input includes receiving data representing instructions for performing a playback session swap from a controller application of the mobile device via an 802.11 enabled network interface.

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

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

[0422] Example 32: The method of any preceding Example 23 to 31, wherein the wearable playback device comprises: one or more network interfaces, where the one or more network interfaces comprise an 802.11 compatible 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, the one or more wearable housings carrying 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 data storage having stored therein instructions executable by the one or more processors to cause the wearable playback device to perform the method of any of Examples 23 to 31.

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

[0424] Example 34: A system configured to perform any of the methods of examples 23 to 32.

[0425] Example 35: A device configured to perform the method of any of Examples 23 to 32.

[0426] Example 36: A tangible, non-transitory computer-readable medium having stored thereon instructions executable by one or more processors to perform the method of any of Examples 23 to 32.

[0427] Example 37: A method including a wearable device, the method including: receiving data representing a first playback session swap input; and, based on the receiving of the data representing the first playback session swap input, identifying one or more source playback devices in a media playback system that (a) are connected to a first wireless local area network (LAN) and (b) are playing particular audio content in a playback session, where the wearable playback device is connected to the first wireless LAN via an 802.11 enabled network interface; and transitioning the playback session from the determined one or more source playback devices to the wearable playback device, where transitioning the playback session includes (i) forming a first synchronization group including the wearable playback device and the one or more source playback devices, where forming the first synchronization group includes causing the wearable playback device to start playing the particular audio content of the playback session; and (ii) causing the one or more source playback devices to stop playing the particular audio content.

[0428] Example 38: The method of Example 37, wherein identifying one or more source playback devices includes identifying a set of swap-eligible playback devices of the media playback system; causing the set of swap-eligible playback devices to emit respective audio chirps identifying the emitting swap-eligible playback devices; detecting via one or more microphones the audio chirps emitted by the one or more swap-eligible playback devices; and selecting one or more source playback devices from among the one or more swap-eligible playback devices based on 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 swap-eligible playback devices.

[0429] Example 39: The method described in Example 38, wherein the one or more microphones comprise one or more acoustic noise-canceling microphones carried on one or more outer surfaces of the one or more wearable housings, and detecting audio chirps emitted by the one or more swap-eligible playback devices includes detecting audio chirps emitted by the one or more swap-eligible playback devices via the one or more acoustic noise-canceling microphones.

[0430] Example 40: A method as described in any preceding Example 37 to 39, wherein selecting one or more source playback devices from among the one or more swap-eligible playback devices includes comparing one or more respective metrics of detected audio chirps emitted by the one or more swap-eligible playback devices to determine that the one or more source playback devices are physically closest to the wearable playback device among the one or more swap-eligible playback devices.

[0431] Example 41: The method of any preceding Example 37 to 40, further comprising: receiving data representing a second playback session swap input while playing audio content in the transitioned playback session; identifying one or more target playback devices in a media playback system connected to the first wireless LAN based on the second playback session swap input; and transitioning the playback session from the determined one or more target playback devices to the wearable playback device, where transitioning the playback session further comprises: (i) forming a second synchronization group including the wearable playback device and the one or more target playback devices, where forming the second synchronization group includes causing the one or more target playback devices to start playing certain audio content of the playback session; and (ii) removing the wearable playback device from the second synchronization group.

[0432] Example 42: A method as described in any preceding Example 37 to 41, wherein one or more wearable housings of the wearable playback device have a touch-sensitive area, and receiving data representing the playback session swap input includes receiving input data representin...

Claims

1. 1. A processor-implemented method comprising: receiving audio from a home theater source through an input interface of a soundbar type playback device; While in the home theater mode, performing audio playback in a playback session in a first synchronization group including the sound bar type playback device and at least one additional playback device, where the sound bar type playback device is configured as a sourcing device of the first synchronization group and sends playback timing information to the at least one additional playback device; receiving an instruction to enter a swap mode with the wearable playback device during the playback session; transitioning to a swap mode with the wearable playback device according to the received instruction, where the transitioning to the swap mode includes: forming a second synchronization group including the sound bar type playback device and the wearable playback device, where the sound bar type playback device is configured as a sourcing device of the second synchronization group and sends audio sound and playback timing information to the wearable playback device; muting the audio playback while the wearable playback device is playing the audio according to the playback timing information; The method includes:

2. The step of transitioning to the swap mode further includes: transitioning a wireless network interface of the sound bar playback device from connecting to a first wireless network to operating as an access point for a second wireless network; Including, wherein the sound bar type playback device transmits audio and playback timing information to the wearable playback device via the second wireless network. The method of claim 1.

3. And next steps: transmitting a service set identifier (SSID) of the second wireless network and authentication data of the second wireless network, and the wearable playback device connecting to the second wireless network using the SSID of the second wireless network and the authentication data of the second wireless network. The method of claim 2 comprising:

4. The wireless network interface is configured to transmit in a first wireless frequency band and a second wireless frequency band, where the second wireless network operates in the first wireless frequency band, and where the step of transitioning to the swap mode further includes: parking at least one additional playback device on a third wireless network operating in the second wireless frequency band; The method of claim 2 comprising:

5. And next steps: adding one or more additional wearable playback devices to the swap mode simultaneously with the wearable playback device; Including, wherein adding one or more additional wearable playback devices to the swap mode includes adding the one or more additional wearable playback devices to the second synchronization group; The method according to any one of claims 1 to 4.

6. The step of receiving an instruction to transition to a swap mode with the wearable playback device includes the following steps: receiving, from the wearable device, an instruction to transition to a swap mode with the wearable playback device; The method according to any one of claims 1 to 5, comprising:

7. The step of receiving an instruction to transition to a swap mode with the wearable playback device includes the following steps: receiving an instruction to transition to a swap mode with the wearable playback device from the control device; The method according to any one of claims 1 to 5, comprising:

8. the audio is comprised of multiple channels; Playing audio in a playback session on the first synchronous group includes playing one or more first channels of the plurality of channels, and at least one additional playback device playing one or more second audio channels of the plurality of channels; Further, next steps Downmixing the multiple channels to a fewer number of channels before transmitting the audio and playback timing information to the wearable playback device. The method according to any one of claims 1 to 7, comprising:

9. The wearable playback device comprises: at least one processor; Data storage device; One or more amplifiers; one or more audio transducers; one or more batteries configured to power one or more amplifiers and one or more audio transducers; and one or more housings housing at least one processor, data storage device, one or more amplifiers, one or more transducers, and one or more batteries; wherein the one or more housings are formed for at least one of: (a) a headphone; or (b) an earphone; The method according to any one of claims 1 to 8.

10. Furthermore, Detecting a swap input of the playback session, including detecting a particular input to the wearable playback device; and Sending an instruction from the wearable playback device to the sound bar type playback device; The method according to any one of claims 1 to 9, comprising:

11. Detecting a particular input to a touch-sensitive area of ​​the wearable playback device includes: Detecting a touch and hold input to a touch-sensitive area on the first playback device; wherein the touch input performs a first action that is not a swap. The method of claim 10.

12. The step of transitioning to the swap mode in the wearable playback device includes the steps of: Sending an instruction to the cloud queue server to transfer the playback session from the sound bar type playback device to the wearable playback device; wherein the cloud queue server transfers the playback session to the second playback device based on the instruction. The method according to any one of claims 1 to 11.

13. A home theater source can consist of one of the following: a television, a set-top box, a streaming media playback device, or a computer. The method according to any one of claims 1 to 12.

14. A system configured to carry out the method according to any of claims 1 to 13.

15. An apparatus, the apparatus being any one of a sound bar type playback device, at least one additional playback device, a cloud queue server, a control device, and a wearable playback device, configured to perform the method according to any one of claims 1 to 13.

16. A tangible, non-transitory computer readable medium having stored therein instructions executable by one or more processors for performing the method of any of claims 1 to 13.

17. A program for causing a computer to execute the method according to any one of claims 1 to 13.

18. A wearable playback device 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 configured for (a) earphones or (b) headphones, the one or more housings housing containing at least one processor, a network interface, one or more amplifiers, one or more transducers, and one or more batteries; Including, Further, a data storage having stored therein instructions executable by one or more processors to perform the method according to any one of claims 1 to 13. A wearable playback device having the above structure.

Images