Playback transition between audio devices

Abstract

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

Description

[Technical Field]

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

[0002] The present disclosure relates to consumer products, and more particularly to methods, systems, products, features, services, and other elements directed to media playback, or some aspects thereof. [Background technology]

[0003] Options for accessing and listening to digital audio in out-of-home 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 desired music in any room equipped with a networked playback device. Media content (e.g., songs, podcasts, video sounds) is streamed to the playback device, allowing different corresponding media content to be played in each room equipped with a playback device. Multiple rooms can also be grouped for synchronized playback of the same media content and / or the same media content can be listened to in all rooms simultaneously. [Brief explanation 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 only and that variations, including different and / or additional features and arrangements thereof, are possible. [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. 1 is a block diagram of a network microphone device. [Figure 1F] FIG. 1 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] 1 is a schematic diagram of a corresponding media playback system zone. [Figure 1J] 1 is a schematic diagram of a corresponding media playback system zone. [Figure 1K] 1 is a schematic diagram of a corresponding media playback system zone. [Figure 1L] 1 is a schematic diagram of a corresponding media playback system zone. [Figure 1M] FIG. 1 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 grille. [Figure 2C] FIG. 2B is an exploded view of the playback device of FIG. 2A. [Figure 3A] FIG. 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; [Figure 5] FIG. 2 is a front view of the control device. [Figure 6] FIG. 2 is a message flow diagram for a 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] 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. 1 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 exemplary push swap in accordance with aspects of the disclosed technology. [Figure 8B] FIG. 1 is a schematic diagram illustrating an exemplary pull swap in accordance with aspects of the disclosed technology. [Figure 8C] FIG. 1 is a schematic diagram illustrating an exemplary push swap in accordance with aspects of the disclosed technology. [Figure 9]FIG. 1 is a schematic diagram illustrating an exemplary audio-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 exemplary feedback technique in accordance with aspects of the disclosed technology. [Figure 12A] FIG. 10 is an exemplary messaging diagram illustrating an exemplary playback session swap technique. [Figure 12B] FIG. 10 is an exemplary messaging diagram illustrating 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 according to aspects 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] FIG. 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 aspects 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] FIG. 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] 1A-1C are schematic diagrams of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17B]1A-1C are schematic diagrams of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17C] 1A-1C are schematic diagrams of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17D] 1A-1C are schematic diagrams of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17E] 1A-1C are schematic diagrams of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 17F] 1A-1C are schematic diagrams of a bridge device user interface at various stages of operation in accordance with aspects of the disclosed technology; [Figure 18A] 1 is a diagram of an exemplary arrangement between a bridge device and a device base. [Figure 18B] 1 is a diagram of an exemplary arrangement between a portable playback device, a bridge device, and a device base. [Figure 18C] 1 is 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. 10 is an exemplary messaging diagram illustrating an exemplary playback session swap technique. [Figure 20B] FIG. 10 is an exemplary messaging diagram illustrating an exemplary playback session swap technique. [Figure 20C] FIG. 10 is an exemplary messaging diagram illustrating 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 exemplary proximity-based playback session swap. [Figure 22B] FIG. 1 illustrates an exemplary proximity-based playback session swap. [Figure 22C] FIG. 1 illustrates an exemplary proximity-based playback session swap. [Figure 22D] FIG. 1 illustrates an exemplary 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. 1 is a front isometric view of the earbuds showing an exemplary arrangement with a charging case. [Figure 23G] FIG. 1 is an isometric view of an 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. 10 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. 1 is a side view of a portable playback device. [Figure 24C] FIG. 1 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. 1 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] 1 is a second side view of the headphones. The drawings are intended to illustrate some exemplary embodiments, but 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 INVENTION

[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, portable) 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 audio). Furthermore, some exemplary techniques can 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 the illustrative headphones while on the go. For example, the user begins listening to KEXP Seattle using earbuds paired with a mobile device (e.g., a smartphone) via a wireless connection such as 802.15 (Bluetooth) or 802.11, among other examples. In this example, KEXP radio is streamed to the mobile device over the Internet.

[0007] 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 predetermined swap pair with the earbud, or may be determined after the input using proximity detection techniques such as audio chirps, as described in further detail herein. The earbud and / or mobile device perform a playback session swap with the kitchen zone, and KEXP Radio playback continues to play continuously on the playback device in the kitchen.

[0008] In another illustrative example, a user may initiate a playback session on an exemplary 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 internet through a home local area network. Wanting to meditate, the user brings the handheld speaker into the living room and asks a 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 a curated meditation playlist is playing, the user's friend enters the living room and suggests that the user check out a new Childish Gambino track 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, initiating 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 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 handheld speaker's detected proximity 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 sound bar 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 a baby to sleep in an adjacent room, the user initiates a playback session swap from the sound bar device to a handheld speaker that the user has placed on their 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 illustrative purposes only. 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 a 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 that 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 additional embodiments of the various disclosed 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 located in an environment 101 (e.g., a home). The media playback system 100 includes one or more playback devices 110 (individually identified as playback devices 110a-n), one or more network microphone devices (“NMDs”) 120 (individually identified as NMDs 120a-c), and one or more control devices 130 (individually identified as control devices 130a, 130b).

[0018] As used herein, the term "playback device" can generally refer to a network device configured to receive, process, and output data for a media playback system. For example, a playback device can 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 can 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 related functions to enable user access, control, and / or configuration of 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 NMDs 120 are configured to receive spoken word commands, and one or more 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 particular 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 may be configured to play a morning playlist when an associated trigger condition (e.g., the presence of a user in the kitchen, the detection of 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] 1A , environment 101 comprises a home with 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. While specific 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] Media playback system 100 can be configured with one or more playback zones, some of which may correspond to rooms within environment 101. Media playback system 100 may be formed with one or more playback zones, after which additional zones may be added or removed, forming, for example, the configuration shown in FIG. 1A. Each zone may be named 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 encompass multiple rooms or spaces. In certain embodiments, a single room or space may encompass multiple playback zones.

[0024] In the illustrated embodiment of FIG. 1A , master bathroom 101a, second bedroom 101c, office 101e, living room 101f, dining room 101g, kitchen 101h, and outdoor patio 101i each include one playback device 110, while master bedroom 101b and den 101d include multiple playback devices 110. In master bedroom 101b, playback devices 110l and 110m may be configured to synchronize and play audio content, for example, as individual ones of multiple playback devices 110, as combined playback zones, as integrated playback devices, and / or any combination thereof. Similarly, in den 101d, playback devices 110h-j may be configured to synchronize and play audio content, for example, as individual ones of 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 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 be grilling on patio 101i and listening to hip hop music played by playback device 110c, while another user is preparing food in kitchen 101h and listening to classical music played by playback device 110b. In another example, a playback zone may play the same audio content in synchronization with another playback zone. For example, a user may hear the same hip hop music being played by playback device 110c on patio 101i being played by playback device 110f in office 101e. In some embodiments, playback devices 110c and 110f play hip hop music in synchronization so that the user perceives the audio content 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 media playback system 100 and cloud network 102. For ease of illustration, certain devices of media playback system 100 and cloud network 102 are omitted from FIG. 1B. One or more communication links 103 (hereinafter "links 103") are provided to communicatively couple media playback system 100 and 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 first computing device 106a, second computing device 106b, and 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 is 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 cloud network 102 is shown in FIG. 1B as having three computing devices 106, in some embodiments, cloud network 102 comprises fewer (or more) than three computing devices 106.

[0029] Media playback system 100 is configured to receive media content from network 102 via link 103. The received media content may consist of, for example, a uniform resource identifier (URI) and / or a uniform resource locator (URL). For example, in some examples, media playback system 100 may stream, download, or otherwise obtain data from a URI or URL corresponding to the received media content. Network 104 communicatively couples link 103 with at least some of the devices of media playback system 100 (e.g., one or more of playback device 110, NMD 120, and / or control device 130). Network 104 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 comprising Ethernet, Universal Serial Bus (USB), and / or other suitable wired communication). As used herein, 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, communication protocols transmitted at 2.4 gigahertz (GHz), 5 GHz, and / or another suitable frequency, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ac, 802.11ad, 802.11af, 802.11ah, 802.11ai, 802.11aj, 802.11aq, 802.11ax, 802.11ay, 802.15, etc.

[0030] In some embodiments, network 104 constitutes a dedicated communications network that media playback system 100 uses to send messages between individual devices and / or to transmit media content to and from media content sources (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 networks. 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 via, for example, 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 , playback devices 110l and 110m constitute group 107a. Playback devices 110l and 110m can be located in different rooms in a home and can be temporarily or permanently grouped into group 107a based on user input received at control device 130a and / or another control device 130 of media playback system 100. Once arranged in group 107a, playback devices 110l and 110m can be configured to synchronously play the same or similar audio content from one or more audio content sources. In particular embodiments, for example, group 107a includes a combining zone in which playback devices 110l and 110m respectively compose the left and right audio channels of multi-channel audio content, thereby creating or enhancing a stereo effect for the audio content. In some embodiments, group 107a further includes playback device 110. However, in other embodiments, media playback system 100 omits group 107a and / or other groupings of playback devices 110. Further details regarding groups and other arrangements of playback devices are described below with reference to Figures 1-I-IM.

[0034] 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 , NMD 120a is a standalone device, and NMD 120d is integrated into playback device 110n. NMD 120a is configured to receive voice input 121, for example, from user 123. In some embodiments, 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 media playback system 100. In some aspects, for example, 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®, or 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. Suitable playback device 1C is a block diagram of a playback device 110a including input / output 111. Input / output 111 can include analog I / O 111a (e.g., one or more wires, cables, and / or other suitable communication links configured to transmit analog signals) and / or digital I / O 111b (e.g., one or more wires, cables, or other suitable communication links configured to transmit digital signals). In some embodiments, analog I / O 111a is an audio line-in input connection, for example, constituting an auto-sensing 3.5mm audio line-in connection. In some embodiments, 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, 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 particular embodiments, Analog I / O 111a and Digital 111b may not necessarily include cables, but rather include interfaces (e.g., ports, plugs, jacks) configured to receive connectors of cables carrying analog and digital signals, respectively.

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

[0037] Playback device 110a further includes electronics 112, a user interface 113 (e.g., one or more buttons, knobs, dials, touch-sensitive surfaces, displays, touchscreens), and one or more transducers 114 (hereinafter referred to as “transducers 114”). 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 network 104 ( FIG. 1B ), amplify the received audio, and output the amplified audio for playback via one or more transducers 114. In some embodiments, 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, playback device 110a, having 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 , electronics 112 includes one or more processors 112a (hereinafter referred to as “processor 112a”), memory 112b, software components 112c, 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 power source 112i (e.g., one or more power supplies, power cables, power receptacles, batteries, induction coils, Power-over Ethernet (POE) interfaces, and / or other suitable power sources). In some embodiments, electronics 112 optionally includes one or more other components 112j (e.g., one or more sensors, a video display, a touchscreen).

[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 from another one of the playback devices 110a. In some embodiments, the instructions 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 zone).

[0040] Processor 112a may be further configured to execute instructions that cause playback device 110a to synchronize playback of audio content with another of one or more playback devices 110. As will be appreciated by those skilled in the art, during synchronized playback of audio content on multiple playback devices, a listener will preferably be unable to perceive a time difference between playback of the audio content by playback device 110a and 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, memory 112b is further configured to store data associated with playback device 110a, such as one or more zones and / or zone groups of which playback device 110a is a member, audio sources accessible to playback device 110a, and / or playback queues with which 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 playback device 110a. Memory 112b may also include data associated with the state of one or more other devices of media playback system 100 (e.g., playback device 110, NMD 120, control device 130). In some aspects, for example, state data is shared among at least some of the devices of media playback system 100 at predetermined intervals (e.g., every 5 seconds, every 10 seconds, every 60 seconds) so that one or more of the devices have up-to-date data associated with media playback system 100.

[0042] Network interface 112d is configured to facilitate data transmission between playback device 110a and one or more other devices on a data network, such as link 103 and / or network 104 (FIG. 1B). Network interface 112d is configured to send 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 Internet Protocol (IP)-based source addresses and / or IP-based destination addresses. Network interface 112d can parse the digital packet data so that electronic device 112 appropriately receives and processes the data intended for playback device 110a.

[0043] In the illustrated embodiment of FIG. 1C , network interface 112d includes one or more wireless interfaces 112e (hereinafter referred to as “wireless interface 112e”). 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 network 104 ( FIG. 1B ) according to a suitable wireless communication protocol (e.g., WiFi, Bluetooth, LTE). In some embodiments, network interface 112d optionally includes 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 over a wired connection with other devices according to a suitable wired communication protocol. In particular embodiments, network interface 112d includes wired interface 112f and excludes 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] Audio processing component 112g is configured to process and / or filter data constituting media content received by electronic device 112 (e.g., via input / output 111 and / or network interface 112d) to generate an output audio signal. In some embodiments, audio processing component 112g includes, for example, one or more digital-to-analog converters (DACs), audio preprocessing components, audio enhancement components, digital signal processors (DSPs), and / or other suitable audio processing components, modules, circuits, etc. In particular embodiments, one or more of audio processing components 112g may include one or more subcomponents of processor 112a. In some embodiments, electronic device 112 omits audio processing component 112g. In some aspects, for example, processor 112a executes instructions stored in 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 particular embodiments, the amplifier 112h includes a suitable combination of two or more of the aforementioned types of power amplifiers. Furthermore, in some embodiments, an individual amplifier 112h corresponds to an individual 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 approximately 20 Hertz (Hz) and approximately 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., subwoofers, woofers), 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 audible frequencies below about 500 Hz, "mid-range frequency" can generally refer to audible frequencies between about 500 Hz and about 2 kHz, and "high frequency" can generally refer to audible frequencies above about 2 kHz. However, in certain embodiments, one or more of the transducers 114 comprise transducers that do not conform to the aforementioned frequency ranges. For example, one of the transducers 114 may comprise a mid-woofer transducer configured to output sound at frequencies between about 200 Hz and about 5 kHz.

[0047] By way of example, 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. Furthermore, those skilled in the art will understand that the playback devices are not limited to the exemplary embodiments described herein or to 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 earphones). In other embodiments, one or more playback devices 110 comprise a docking station for a personal mobile media playback device and / or an interface configured to interact with the docking station. In certain embodiments, the playback device may be integrated with another device or component, such as a television, a lighting fixture, or some other device for indoor or outdoor use. In some embodiments, the playback device omits a user interface and / or one or more transducers. For example, Figure 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 playback device 110q (FIG. 1C) acoustically coupling playback device 110a (FIG. 1C) with playback device 110i (e.g., a subwoofer) (FIG. 1A). In the illustrated embodiment, playback devices 110a and 110i are separate playback devices 110 housed in separate enclosures. However, in some embodiments, combined playback device 110q comprises a single enclosure that houses both playback devices 110a and 110i. Combined playback device 110q can be configured to process and reproduce sound differently than the uncoupled playback device (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, when combined with a first playback device, is configured to render only the mid- and high-frequency components of particular audio content, and playback device 110i is configured to render the low-frequency components of particular audio content. In some embodiments, combined playback device 110q includes an additional playback device and / or another combined playback device. Embodiments of additional playback devices are described in further detail below with respect to FIGS. 2A-3D.

[0049] c. Suitable Network Microphone Device (NMD) FIG. 1F is a block diagram of 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 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, an NMD can be incorporated into a playback device. FIG. 1G is a block diagram of playback device 110r including NMD 120d. Playback device 110r can include many or all of the components of playback device 110a, further including microphone 115 and audio processing 124 (FIG. 1F). Playback device 110r optionally includes integrated control device 130c. Control device 130c can include, for example, a user interface (e.g., user interface 113 of FIG. 1B) configured to receive user input (e.g., touch input, voice input) without using a separate control device. However, in other embodiments, playback device 110r receives commands from another control device (e.g., control device 130a of FIG. 1B).

[0051] Referring again to FIG. 1F, 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 NMD 120a is located. The received sounds may include, for example, vocalizations, audio played by NMD 120a and / or another playback device, background voices, environmental sounds, etc. Microphone 115 converts the received sounds into electrical signals to generate microphone data. Audio processing 124 receives and analyzes the microphone data to determine whether voice input is present in the microphone data. The voice input may consist, for example, of an activation word followed by an activation word containing 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 an 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, 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). A 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. A user may similarly speak an activation word followed by a request to play a particular song, album, or music playlist on a playback device in the home. Receiving and processing voice input data is described in further detail with reference to FIGS. 3A-3F.

[0053] d. Suitable control devices 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 actions or operations 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 particular 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] Control device 130a includes electronics 132, a user interface 133, one or more speakers 134, and one or more microphones 135. Electronics 132 includes one or more processors 132a (hereinafter referred to as “processor 132a”), memory 132b, software components 132c, and a network interface 132d. Processor 132a can be configured to perform functions related to facilitating user access, control, and configuration of media playback system 100. Memory 132b can include data storage into which one or more software components executable by processor 302 can be loaded to perform those functions. Software components 132c can include applications and / or other executable software configured to facilitate control of media playback system 100. Memory 112b can be configured to store, for example, software components 132c, media playback system controller application software, and / or other data related to media playback system 100 and the user.

[0055] Network interface 132d is configured to facilitate network communication between control device 130a and one or more other devices in media playback system 100 and / or one or more remote devices. In some embodiments, network interface 132d 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). Network interface 132d can be configured to transmit and / or receive data to, for example, playback device 110, NMD 120, others of control device 130, one of computing devices 106 of FIG. 1B, one or more other devices comprising the media playback system, etc. The transmitted and / or received data can include, for example, playback device control commands, state variables, playback zone and / or zone group configurations. 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 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 integrated player, or separating one or more playback devices from a combined or integrated player. More 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 indicator 133b (e.g., elapsed time and / or time remaining indicator), media content information area 133c, playback control area 133d, and zone indicator 133e. The media content information area 133c can include a display of relevant information (e.g., title, artist, album, genre, year of release) about 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 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 networked devices to provide equivalent control access to the media playback system.

[0057] One or more speakers 134 (e.g., one or more transducers) may be configured to output sounds to a user of control device 130a. In some embodiments, one or more speakers comprise individual transducers configured to correspondingly output low, mid, and / or high frequencies. In some aspects, for example, control device 130a is configured as a playback device (e.g., one of playback devices 110). Similarly, in some embodiments, control device 130a is configured as an NMD (e.g., one of 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, two or more microphones 135 are positioned to capture location information of an audio source (e.g., voice, audible sound) and / or 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, IoT device, network device) that includes a portion of the electronics 132 and a user interface 133 (e.g., a touchscreen) without 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. Referring first 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., the left playback device) can be combined with playback device 110j (e.g., the right 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., the front playback device) can be merged with playback device 110i (e.g., a 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 can be merged to form merged group or zone group 108b. Merged playback devices 110g and 110h may not be specifically assigned different playback responsibilities. That is, merged playback devices 110h and 110i can each play audio content as if they were not merged, apart from playing audio content synchronously.

[0060] Each zone in 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, and zone C may be provided as a single entity called the second bedroom.

[0061] Combined playback devices may have different playback responsibilities, such as responsibility for specific audio channels. For example, as shown in FIG. 1-I, playback devices 110l and 110m may be combined to create or enhance a stereo effect for audio content. In this example, playback device 110l may be configured to play the left channel audio component, while playback device 110k may be configured to play the right channel audio component. In some implementations, such stereo combining may be referred to as "pairing."

[0062] Furthermore, combined playback devices may have additional and / or different respective speaker drivers. As shown in FIG. 1J, a playback device 110h labeled Front may be combined with a playback device 110i labeled Sub. The Front device 110h may be configured to render a mid- to high-frequency range, 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 110k may be configured to form surround or "satellite" channels 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 may be capable of rendering the full range of audio content for which the respective playback device is capable. 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 can each output the full range of audio content for which each playback device 110a and 110n is capable in sync.

[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 zone F, referred to as the living room. In other embodiments, a standalone network microphone device may itself be within a zone. However, in other embodiments, a standalone network microphone device may not be associated with a zone. Further details regarding associating network 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] Zones of 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 containing 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 C1. 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, zones of individual and / or combined playback devices may play audio in synchronization with one another, as described in the previously referenced U.S. Pat. No. 8,234,395. Playback devices may also be dynamically grouped and ungrouped to form new or different groups that play audio content in synchronization.

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

[0067] Certain data may be stored in the 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 devices so that one or more of the devices have the most current data associated with the system.

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

[0069] In yet another example, 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 not within a zone group. For example, FIG. 1M shows upper area 109a including zones A-D and lower area 109b including zones E-I. In one aspect, an area can be used to refer to a cluster of zone groups and / or zones that share one or more zones and / or zone groups of another cluster. In another aspect, this is different 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 Application Publication 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 called a home graph. Under the home graph hierarchy, the basic unit of the home graph hierarchy is the "set." A "set" refers to an individual device or multiple devices that work together to perform a given function, such as an individual playback device 110 or a combined zone of playback devices. After a set, the next level in the hierarchy is the "room." Under the home graph hierarchy, a "room" can be thought of as a repository of a set of rooms in a given residence. For example, an exemplary room corresponds to the kitchen of a home and is assigned the name "kitchen" and can contain one or more sets (e.g., "kitchen island"). The next level in the exemplary home graph hierarchy is an "area," which contains two or more rooms (e.g., "upstairs" or "downstairs"). The top level of the home graph hierarchy is the "home." Home refers to the entire house and all the sets within it. Each level in 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 in accordance with 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. Referring together 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 a frame 216h to the housing 216. A cavity 216j (FIG. 2C) within the housing 216 is configured to receive the frame 216h and the electronic device 212. 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 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 approximately 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 approximately 2 kHz). In some embodiments, the playback device 210 includes a number of transducers different from those shown in FIGS. 2A-2C. For example, the playback device 210 can include fewer 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). Additionally, in some embodiments, all or some of the transducers 214 are configured to operate as a phased array to desirably adjust (e.g., narrow or wide) 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, filter 216i is axially aligned with transducer 214b. Filter 216i can be configured to desirably attenuate a predetermined frequency range output by transducer 214b to improve the sound quality and perceived sound stage collectively output by transducers 214. However, in some embodiments, playback device 210 omits filter 216i. In other embodiments, playback device 210 includes one or more additional filters aligned with transducer 214b and / or at least another of 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 an enlarged 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 having an upper portion 316a, a lower portion 316b, and a middle portion 316c (e.g., a grille). A plurality of ports, holes, or openings 316d in the upper portion 316a allow sound to pass 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 electrical signals based on the received sound. In the illustrated embodiment, frame 316e of housing 316 (FIG. 3C) encloses cavities 316f and 316g configured to house first transducer 314a (e.g., a tweeter) and second transducer 314b (e.g., a mid-woofer, mid-range speaker, or woofer), respectively. However, in other embodiments, NMD 320 includes a single transducer, or three or more (e.g., two, five, or six) transducers. In certain embodiments, NMD 320 omits transducers 314a and 314b entirely.

[0075] Electronics 312 (FIG. 3C) includes components configured to drive 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, electronics 312 includes many or all of the components of electronics 112 described above with respect to FIG. 1C. In particular embodiments, 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, 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., a previous control), a second control surface 313b (e.g., a next control), and a third control surface 313c (e.g., a 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 remain illuminated during normal operation and may be configured 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, user interface 313 includes first indicator 313e without second indicator 313f. Further, in certain embodiments, NMD 320 comprises a playback device and a control device, and 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, after detecting one or more appropriate voice commands, 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. The remote server can analyze the audio data, determine an appropriate action based on the voice command, and send 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 send 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 send 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 a 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. First user interface display 431a (FIG. 4A) includes a display name 433a (i.e., "Room"). Selected group area 433b displays audio content information (e.g., artist name, track name, album art) for audio content being played in the selected group and / or zone. Group areas 433c and 433d display the corresponding group and / or zone name, as well as audio content information and audio content playing or next to be played in the play queue for the respective group or zone. Audio content area 433e includes information about the audio content in the selected group and / or zone (i.e., the group and / or zone shown in selected group area 433b). Lower display area 433f is configured to receive touch input and display one or more other user interface displays. For example, if the user selects "Browse" in lower display area 433f, control device 430 can be configured to output a second user interface display 431b (FIG. 4B) that includes multiple 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 for and select media content for playback via one or more playback devices (e.g., one of playback devices 110 of FIG. 1A). Alternatively, if the user selects "My Songs" in lower display area 433f, control device 430 can be configured to output a third user interface display 431c (FIG. 4C).First media content region 433h can include a graphical representation (e.g., album art) corresponding to an individual album, station, or playlist. Second media content region 433i can include a graphical representation (e.g., album art) corresponding to an individual song, track, or other media content. When a user selects graphical representation 433j (FIG. 4C), control device 430 can be configured to begin playing audio content corresponding to graphical representation 433j and output fourth user interface display 431d including an enlarged version of 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 zones 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 options for selecting one or more other zones within the media playback system to be grouped with the particular zone. Once grouped, playback devices within the zone grouped with the particular zone can be configured to play audio content in synchronization with the playback devices in 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 options 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 region 533b may be dynamically updated as the play zone or zone group configuration changes.

[0081] Playback status area 533c includes a graphical representation of audio content 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 playback zone area 533b and / or play 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 media playback system 100 via user interface 531.

[0082] The play queue area 533d includes a graphical representation of the audio content in the play queue associated with the selected playback zone or zone group. In some embodiments, each playback zone or zone group may be associated with a play 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 play 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 play queue, and information corresponding to each audio item in the playlist may be added to the play queue. In some embodiments, the audio items in the play queue may be saved as a playlist. In certain embodiments, the play 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 can otherwise continue to play until stopped, rather than individual audio items with playback durations. In some embodiments, the playback queue may include internet radio and / or other streaming audio content items and may be "in use" when a playback zone or zone group is playing those items.

[0083] When playback zones or zone groups are "grouped" or "ungrouped," the playback queues associated with the affected playback zones or zone groups can be cleared or reassociated. For example, if a first playback zone containing a first playback queue is grouped with a second playback zone containing a second playback queue, the established zone group can initially have playback queues that are empty, contain audio items from the first playback queue (e.g., if the second playback zone is added to the first playback zone), contain audio items from the second playback queue (e.g., if 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 is empty or contains 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 in media playback system 100 (FIGS. 1A-1M).

[0085] At step 650a, media playback system 100 receives, via 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 (e.g., one or more of remote computing devices 106 of FIG. 1B). In response to receiving the indication of the selected media content, control device 130a sends message 651a to playback device 110a (FIGS. 1A-1C) to add the selected media content to a playback queue of playback device 110a.

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

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

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

[0089] In step 650e, playback device 110a optionally causes one or more other devices to play the selected media content. In one example, playback device 110a is one of a combined zone of two or more players (FIG. 1M). 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, playback device 110a is a group coordinator 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 computing device 106a and begin playing the selected media content in response to a message from playback device 110a, so that all devices in the group play the selected media content synchronously.

[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 playback devices use to play audio content from audio sources in synchronization with each other, including how 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, specific technical details of the audio information, playback timing, and clock timing information, as well as how playback devices generate and / or use the playback timing and clock timing to play 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 now known or later developed computing device; (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 computing device. (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 systems 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 later developed suitable for receiving audio content in digital or analog format.

[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, play, and / or distribute 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 from an audio source in digital form, 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 packet was 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 next be played.

[0096] In some embodiments, the source playback device does not change the 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 each packet's sequence identifier, 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 for some (or all) of the audio content that 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 connection 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, they can ensure that the received packets are placed in the correct order before performing further packet processing.

[0098] In some embodiments, an audio source provides audio content in analog format to a source playback device, for example, via an analog line connection interface. In such embodiments, the source 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, they can ensure that the received packets are placed 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) play the audio content independently; (ii) play the content in synchronization with one or more additional playback devices; and / or (iii) transmit the audio content to one or more other playback devices.

[0100] b. Playback timing The playback devices disclosed and described herein use playback timing to play audio content in synchronization with one another. Individual playback devices can generate 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. A source playback device that generates playback timing for audio content also 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 may be "local" clock timing (i.e., clock timing generated by the source 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 audio content. As described above, in some embodiments, 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, playback timing of the audio content includes a playback time for each frame (or packet) of the audio content. In some embodiments, playback timing for individual frames (or packets) is included within the frame (or packet), for example, in the frame's (or packet's) header, the frame's (or packet's) extension header, and / or the frame's (or packet's) payload portion.

[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 at which 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 time in the future 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, such as another playback device, computing device, or other 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 the particular audio content within each 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 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 the audio content that the source playback device receives from the 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, such as another playback device, computing device, or other network device configured to provide timing for the clock that the playback device uses 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 of the playback devices play the audio content using the same clock timing 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 determined 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 synchronous playback of 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 perhaps all) of the other playback devices configured to play the audio content 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 one or more other playback devices negotiate the timing advance via multiple test and response messages. In some embodiments with 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 that portion of the audio content) or that a smaller timing advance is sufficient (e.g., because the receiving device has buffered more packets containing a portion of the audio content than is necessary to provide consistent and reliable playback).

[0112] As will be explained in more detail below, all playback devices configured to play audio content in a synchronized manner use playback timing and clock timing to play the audio content in synchronization 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 back audio content synchronized with one or more other playback devices. If the source playback device uses clock timing from a local clock at the source playback device to generate the playback timing, the source playback device plays back the audio content using the locally generated playback timing and the locally generated clock timing. In operation, the source playback device plays back an individual frame (or packet) containing a portion of the audio content when the local clock used by the source playback device to generate the playback timing reaches a time specified in the playback timing of that individual frame (or packet).

[0114] For example, as described above, when the source playback device generates the playback timing for 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 for an individual frame is, for example, 30 milliseconds, the source playback device will play back the portion of the audio content (e.g., a sample or set of samples) for that 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 locally generated playback timing and clock timing from the local reference clock, and as described further below, when the clock time of the local reference clock reaches the playback timing of an individual frame or packet, the source playback device plays back that portion of the audio content of that individual frame and / or packet 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, a 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 that receive 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 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 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 for the audio content from the source playback device (e.g., playback timing contained in frame and / or packet headers of the frames and / or packets containing portions of the audio content, or possibly elsewhere than the frames and / or packets containing portions of the audio content), (iii) receiving clock timing from another network device, such as another playback device, computing device, or another network device configured to provide clock timing for use by the playback device to generate 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 its clock timing and a "local" clock at the receiving playback device that the receiving playback device uses to play back the audio content. In operation, each playback device that receives clock timing from another network device calculates its own "timing offset" based on the difference between its own local clock and the clock timing. Thus, the "timing offset" determined by each playback device is unique to that playback device.

[0119] In some embodiments, when playing back audio content, the receiving playback device generates new playback timing (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] Additionally, 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 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 herein 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 to 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 is configured for portable use. While shown in a home environment 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 include 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, 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 portable playback device 710a can use to stream audio content through or communicate with the bridge device.

[0126] Playback device 710a further includes electronics 712, a user interface 713 (e.g., one or more buttons, knobs, dials, touch-sensitive surfaces, displays, touchscreens), and one or more transducers 714 (hereinafter referred to as “transducers 714”). Electronics 712 is configured to receive audio from an audio source via input / output 711 and from one or more of 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 transducers 714.

[0127] In some embodiments, 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, microphone 715 may include one or more audio microphones to facilitate audio input, such as for phone calls. In particular embodiments, for example, playback device 710a may operate as an NMD (similar to NMD 120 of FIG. 1F ) configured to receive audio input from a user using the audio microphones and correspondingly perform one or more actions based on the received audio input. In further examples, microphone 715 may 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 playback device 710a.

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

[0129] The network interface 712d is configured to facilitate the transmission of data between the playback device 710a and one or more other devices of a data network, such as, for example, link 103 and / or network 104 (FIG. 1B). The network interface 712d is configured to send and receive data corresponding to media content (e.g., audio content, video content, text, photographs) and other signals (e.g., non-transient signals) including digital packet data that include 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 properly receives and processes the data destined for the playback device 110a.

[0130] 7B , network interface 712d includes one or more wireless interfaces 712e (hereinafter referred to as “wireless interface 712e”). 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 playback device 110, NMD 120, control device 130, other portable playback devices 710, and other devices disclosed herein, such as a bridge device) communicatively coupled to network 104 ( FIG. 1B ) according to a suitable wireless communication protocol (e.g., WiFi, Bluetooth, LTE). In some embodiments, network interface 712d optionally includes 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] Audio component 712g is configured to process and / or filter data including media content received by electronics 712 (e.g., via input / output 711 and / or network interface 712d) to generate an output audio signal. In some embodiments, audio processing component 712g comprises, for example, one or more digital-to-analog converters (DACs), audio preprocessing components, audio enhancement components, digital signal processors (DSPs), and / or other suitable audio processing components, modules, circuits, etc. In particular embodiments, one or more of audio processing components 712g may include one or more subcomponents of processor 712a. In some embodiments, electronics 712 omits audio processing component 712g. In some aspects, for example, processor 712a executes instructions stored in memory 712b to perform audio processing operations to generate an 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 particular 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 approximately 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., subwoofers, woofers), a mid-range frequency transducer (e.g., mid-woofers), 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 in accordance with aspects 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, compared to the loud audio playback of the playback device 110. As shown, the portable playback device 710b (also referred to as earbuds 710b) includes a housing 716b for supporting a pair of transducers 714b in a user's ear. The earbuds 710b also include a user interface 713b having touch-sensitive areas for facilitating playback control, such as transport and / or volume control. The earbuds 710b may be in the form of wired, wireless, or true wireless earbuds.

[0137] FIG. 7E is a front isometric view of a portable playback device 710c. Compared to the headphones 710a and earbuds 710b, the portable playback device 710c includes one or more larger transducers to facilitate louder audio content playback. A speaker grille 716a covers the transducers. Relative to the playback device 110, the portable playback device 710c may include a less powerful amplifier and / or smaller transducers to balance the battery life, audio output capabilities, and form factor (i.e., size, shape, and weight) of the portable playback device 710c. The portable playback device 710c includes a user interface 713c with 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 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 with 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 on the portable playback device 710c. Such protrusions and recesses can facilitate placement of the portable playback device 710c on the device base 718a and can improve the stability of the playback device while it is 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 a device charging system. When the playback device 710c is placed on the device base 718a, the playback device 710c can draw current from the charging system to charge one or more of its batteries. In some examples, the charging system of the device base 718a includes an inductive charging circuit (e.g., a coil that induces current in a corresponding coil in the playback device 710c, which 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 718a.

[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 in 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 718a 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 718a. 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. Placing the portable playback device 710 in a device base causes the device base to join 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 for 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. Example operations include, 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, playback device 710 may operate in one of a first mode and a second mode. Generally, playback device 710 operates in the first mode while in physical proximity of media playback system 100 (e.g., at home, connected to network 104) to facilitate interoperability with playback devices 110a-n of media playback system 100, and in the second mode while “on the move,” although playback device 710 may also be capable of operating in the second mode while in physical proximity of media playback system 100. Portable playback device 710 may switch modes manually (e.g., via user input to user interface 713) or automatically (e.g., based on proximity to one or more playback devices 110a-n, based on connection to 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 its 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 in the media playback system 100. For example, the portable playback device 710 may form a synchronization group or other arrangement with playback devices 110a-n and / or other portable playback devices 710 in the first mode. 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 the 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 described 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 proximity to the media playback system 100, thereby facilitating more private use of the portable playback device 710a or providing convenient access to content on the mobile device for playback.

[0148] 7G illustrates an exemplary pairing configuration between headphones 710a and a mobile device configured as control device 130a. As described above, the mobile device can become control device 130 through the installation of control application software and can further provide bridging functionality to facilitate control device 130a acting as an interface between headphones 710a and 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 can 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 control device 130a's Internet connection and paired connection. 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 710a 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 control device 130a's Internet connection and the paired connection. In this example, the bridge device 860's Internet connection may be a wireless local area network with a gateway to the Internet or via a cellular data connection.

[0152] In an exemplary implementation, controlling device 130a is bound or defaults 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 a "kitchen + dining room" group. Alternatively, if a home graph hierarchy is utilized, controlling device 130a can be bound or defaults to a particular set, room, or area. In this configuration, control of the combined playback device 110 via NMD 120 or controlling device 130 then 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 "Ann's Portable" zone or an "Ann'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 an alternative implementation, portable playback device 710a can interface independently with media playback system 100 as its own zone or set. Such an implementation of portable playback device 710a can include a cellular data connection to facilitate portable streaming (i.e., streaming away from media playback system 100 and / or network 104). In this example, portable playback device 710a can join media playback system 100 as a zone or set when connected to network 104 or when in proximity to playback device 110.

[0155] VI. Exemplary Swap Techniques As mentioned above, the example techniques described herein relate to transitioning (or "swaping") playback sessions between portable playback device 710 and one or more playback devices 110. During a playback session swap, playback of audio content stops on a "source" playback device and begins on a "target" playback device at the same or substantially the same offset within 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 so as not to disturb 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 portable playback device 710c and then swap to one or more playback devices 110a-n, where the target playback device may have greater acoustic output capabilities (e.g., due to a more powerful amplifier and / or larger transducer), may be located in another room, may be configured in a synchronization group, or for any other reason.

[0157] Similarly, a user may listen to audio content through one or more playback devices 110a-n and then swap playback to 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 then swap playback to portable playback device 710c so that they can pick up music outside in their yard.

[0158] A playback device with an ongoing playback session may maintain state or access playback session data that defines and / or identifies the playback session. 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. Among other ways, 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. In an exemplary implementation, the offset may be set to a playback position in the audio content at the current playback position to allow 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 begins 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 the play state. The play state may include the 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 the 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 media playback system 100 may use the queue version to maintain consistency. The queue version may be incremented each time the queue is changed 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 allow the target playback device to access 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.

[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 is sometimes referred to as the “lead playback device.” In examples, the lead playback device is either the source or the destination of the swap. When the portable playback device 710 has an ongoing playback session (e.g., the portable playback device is actively playing audio content or has an active but paused playback session) and receives a playback session swap input, the portable playback device 710 can assume that the user wants to “push” 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 destination.

[0165] To illustrate, FIG. 8A is a schematic diagram illustrating an exemplary push swap between headphones 710a (FIG. 7C) and playback device 110b in kitchen 110h zone (FIG. 7A). As shown in FIG. 8A, initially, headphones 710a continue to execute a playback session. At this time, a user applies a playback session swap gesture to headphones 710a. The playback session of headphones 710a is pushed (taken over) to playback device 110b. After the push, kitchen 110h zone receives information about the playback session and continues to play 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 illustrating 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, initially, playback device 110b continues to run a playback session. At this time, the user applies a playback session swap gesture to headphones 710a. The playback session of playback device 110b is then pushed to headphones 710a. After the push, headphones 710a begins 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 illustrate, FIG. 8C is a schematic diagram illustrating an exemplary push swap between headphones 710a (FIG. 7C) and playback device 110b in the kitchen 110h zone (FIG. 7A). As shown in FIG. 8C, initially, both headphones 710a and playback device 110b have ongoing playback sessions. At this time, the user applies a playback session swap gesture to headphones 710a. The playback session of headphones 710a is then pushed to 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 initiate a playback session swap with 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 issue a playback session swap input to any of the playback devices 110, such as playback device 110b. In this scenario, similar determinations may apply when specifying the source and destination 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 its vicinity 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 a lead playback device requests a playback device eligible for a swap to emit a distinguishable sound (such as an audio chirp) that is detected by one or more microphones on the lead playback device. The lead playback device then identifies the nearby playback device based on characteristics of the detected sound.

[0171] To illustrate, Figure 9 is a schematic diagram illustrating a sound-based identification technique using audio chirps. The audio chirps include acoustic characteristics (e.g., one or more tones) that allow for identification of the playback device transmitting the audio chirp. In Figure 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 the swap. In the case of a push swap, the set of playback devices eligible for the swap 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 the swap. As another example, only the master in a combined zone (e.g., a stereo pair or surround sound configuration) may be considered eligible for the swap. In the case of a pull swap, the set of playback devices eligible for the swap includes playback devices 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 devices 110 in the media playback system 100 may maintain or access playback device state variables, as well as other configuration information. This state information may be updated periodically or on an event-by-event basis (e.g., when a status changes), such as via subscriptions to specific types of events or status (e.g., playback events, grouping events, topology change events, player volume events, group volume events, playback metadata events) and notifications of the specific events. The protocol used for subscriptions may be uPnP-based or a proprietary controller protocol or API. The portable playback devices 710, including the headphones 710a and earbuds 719b, may similarly maintain or access these state variables and determine a 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 in 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 the swap, headphones 710a, as the lead playback device in the swap, may cause the multiple playback devices eligible for the swap to emit their own 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 the swap to emit their own audio chirps. In some examples, the audio chirps may be ultrasonic (e.g., above 20 kHz) or near-ultrasonic (e.g., 19-20 kHz) to avoid propagation of the audio chirp beyond 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 a coded identifier. Each coded identifier may be different and may be coded as a set of tones known to the lead playback device. Audio chirps from multiple playback devices eligible for swapping may be transmitted immediately, simultaneously, sequentially, or when a particular playback device receives an instruction to transmit an audio chirp. In some examples, devices in the media playback system may provide timing information regarding when to transmit audio chirps for each of the playback devices.

[0176] After instructing the multiple playback devices eligible for the swap to emit an audio chirp, the leading playback device in the swap attempts to detect the emitted audio chirp via one or more microphones (e.g., microphone 715). For example, headphones 710a may attempt to detect the emitted audio chirp via one or more audio microphones within the housing of headphones 710a. Alternatively, headphones 710a may attempt to detect the emitted audio chirp via one or more ANC microphones within the housing of headphones 710a. In some cases, particular microphones (ANC or audio) may be selected or tuned to be sensitive in the ultrasonic or near-ultrasonic range, making them particularly well-suited for receiving the audio chirp. Other examples are possible as well.

[0177] To identify a "nearby" playback device, the lead playback device can compare detected audio chirps. For example, headphones 710a may compare various metrics, such as the sound pressure and signal-to-noise ratio of the detected audio chirps, to identify the "loudest" audio chirp that can be assumed to be emitted by the playback device physically closest to the 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] 9, headphones 710a detect audio chirps from playback devices 110n and 110g, located in bathroom 101a and bedroom 101c, respectively. However, headphones 710a do not detect audio chirps from playback device 110b. This is likely because the audio chirp from kitchen 101h, which is located on a different floor of the house from the other zones, could not propagate to headphones 710a. In this example, a comparison of the metrics for the audio chirps emitted by playback device 110n and playback device 110g reveals that the audio chirp emitted by playback device 110n is the "loudest," and therefore 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 can 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 specific volume level. Because different playback devices have different types of transducers and / or amplifiers, the volume level of each playback device emitting a chirp may vary based on the type of device. Alternatively, the playback devices may be pre-configured to emit audio chirps at a specific 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 portion thereof), may trigger a 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 a swap. Other types of input are also contemplated.

[0181] In some particular examples, a touch and hold (long touch) or continuous touch and hold on a particular area of ​​the touch-sensitive area (e.g., the play / pause area) triggers a swap. To illustrate, FIG. 10 is a chart illustrating an exemplary control scheme for the portable playback device 710c, the playback device 110, and the 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 a swap.

[0182] For example, if the user continues to hold a press input (touch and hold, long touch), a 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 lead playback device (i.e., the portable playback device 710c or the playback device 110), to 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 FIGS. 8A-8C. This configuration allows the user to access the swap function more quickly when using the headphones 710a. Because wearable playback devices are designed for relatively private listening compared to the portable playback device 710c and the playback device 110, users are less likely to want to group the headphones for synchronous playback with these types of devices. Other exemplary implementations may vary this control scheme.

[0183] If the user continues to hold the touch input (touch and continued hold, or long touch and hold), a tertiary action is performed. 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 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 accurately 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 technique described above, the lead playback device may identify a different playback device as the source or target than the user intended, perhaps due to the unique acoustic characteristics of the environment that cause audio chirps emanating from more distant playback devices to appear closest.

[0185] Using this control scheme, when a press-and-hold input is provided to the portable playback device 710c or the playback device 110 (in the case of a long press where the user continues to hold), a potential swap results in a grouping between the source and destination sides, resulting in synchronized loud audio playback between the source and destination sides after the swap. In particular, when the lead playback device has an active playback session, a push group is performed, causing the lead playback device and the nearby playback devices to synchronously play the active playback session. Conversely, when the lead playback device does not have an active playback session, a pull group is performed, causing the lead playback device and the nearby playback devices to synchronously play the active playback session of the nearby playback device. This synchronized loud audio playback 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 cancel the group or perform an input to cancel the swap action.

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

[0187] In some examples, the portable playback device 710c can 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 a 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 a 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 can further traverse (reject) the ranked list of swap- and / or group-eligible playback devices in ranked order from closest to farthest. 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 users understand the control scheme, the source and / or target playback devices can provide feedback, including audio and / or visual feedback. To illustrate, FIGS. 11 and 10 are charts illustrating an exemplary 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, the lead playback device (portable playback device 710c), which is the source in this example, provides audio and / or visual feedback in association with each operation. 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 in FIG. 11 as two different tones, “Marco” and “Polo”), 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 a pull or push swap, respectively, the lead playback device transfers the playback session from the source playback device to the target playback device. In an exemplary implementation, the swap includes forming a synchronization group including the source playback device and the target playback device. Exemplary synchronization grouping is described in more detail in Sections III and IV above. Upon forming the synchronization group, the target playback device begins playing audio content in synchronization with the source playback device. The source playback device may then be removed from the synchronization group completing the swap. The source playback device can be removed or ungrouped from a synchronization group by sending an ungrouping command to the target device 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 the 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 in synchronization. To end the push swap, headphones 710a leave the synchronization group.

[0193] 8A, the playback session begins on headphone 710a, so headphone 710a may initially act as the source device for the synchronization group. As described above, the source device or group coordinator captures the audio for the synchronization group. After headphone 710a leaves the synchronization group, playback device 110b may assume the role of the source device.

[0194] In some examples, playback may be controlled by the source or target playback device during the swap to avoid user confusion from audio playback during the swap. For example, the playback session may be paused upon the creation of the synchronization group and then resumed after headphones 710a leave the synchronization 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, etc.) before pausing to allow for any delay in transferring 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 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 in synchronization. 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 can initially act as the source device for the synchronization group. As described above, the source device or group coordinator captures the audio for the synchronization group. After playback device 110b leaves the synchronization group, headphones 710a may assume the role of the source device.

[0197] In alternative embodiments, 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 synchronously, but in these examples, the source playback device is placed in a muted state. Because the source playback device is muted, the playback sessions appear to have been swapped from the user's perspective. This may be a true mute, where certain components, such as audio amplifiers, are disabled or placed 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 transition a playback session from a soundbar-type playback device to a wearable playback device to enable more private listening of audio from a television or other home theater source. Exemplary soundbar-type playback devices include playback device 110h (FIGS. 1K and 1J). A soundbar-type playback device can receive audio from a television, a media player (e.g., a set-top box, a streaming media playback device, a computer), or another home theater source via an audio input interface. Furthermore, a soundbar-type playback device can operate as a source device for a combined zone containing one or more satellites capable of playing specific channels (e.g., playback devices 110j and 110k) and / or specific frequency ranges (e.g., playback device 110i), as shown in FIGS. 1K and 1J illustrating den 101d. While a soundbar-type playback device implements a bar-shaped housing with multiple audio drivers linearly arranged along its front surface, a soundbar-type 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 the audio input interface. When streaming audio via the network interface, the sound bar playback device may be considered to be in the 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 podcasts or news programs. When streaming audio content in the music mode, the sound bar playback device may perform swapping in the same or similar manner as described in Section VI.

[0200] While in home theater mode, the sound bar 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 playback device. In swap mode, the sound bar playback device acts as a source device, in this case playing audio from the audio input interface, just 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 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, sound bar playback device 110h, one or more satellites (den 101d) within a combined zone that includes sound bar 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 within a zone group that includes any additional zones) in an example swap mode initiated by headphones 710a.

[0202] Before entering the swap mode, the sound bar-type playback device 110h plays audio from the audio input interface in home theater mode (1281a). As a source device for a combined zone that includes a satellite, the sound bar-type playback device 110h distributes audio to the satellite in home theater mode according to its role in the combined zone. Also, if 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 for 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 swap mode to the soundbar playback device 110h. The headphones 710a and the soundbar playback device 110h can transmit and receive the 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 the combined zone, which may be the same combined zone as the den 101d or a new combined zone.

[0206] In some examples, in 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 may include a dedicated communications network implemented as a mesh network. In 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 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) 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 the same combined zone as the den 101d or 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] Additionally, in some examples, while in swap mode, headphones 710b effectively become satellites of soundbar playback device 110h. Thus, soundbar playback device 110h “parks” 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 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 bonding zones when transitioning back to home theater mode) and receive updates (e.g., state variable events) regarding the state of media playback system 100. 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 the HT audio stream 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 Wi-Fi. Similarly, at 1287a, sound bar playback device 110h can stop streaming the HT audio stream to group members, if any. By forming a new combined zone at 1284a, sound bar playback device 110h can be removed from any existing zone groups, thereby causing the group members to stop receiving the HT audio stream.

[0210] At 1288a, the soundbar 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 soundbar playback device 110h mutes and completes the swap. When muted, the soundbar 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 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 soundbar playback device 110h can downmix the surround sound audio track to an audio track with fewer channels, such as a stereo audio track. The surround sound audio track can be downmixed to include the same number of channels as supported by the wearable or portable playback device.

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

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

[0213] Furthermore, while in swap mode, additional wearable playback devices can connect to soundbar playback device 110h as satellites. This allows, for example, two partners to listen to television audio using their individual wearable devices in den 101h without waking a child sleeping in adjacent bedroom 101c. A user can cause a second wearable playback device (e.g., earbud 710b) to join swap mode by providing a playback session swap input (e.g., touch and hold) to the second wearable device, thereby causing the second wearable playback device to send data to soundbar playback device 110h representing an instruction to enter swap mode. 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 control device 130a, headphones 710a, sound bar playback device 110h, and one or more satellites in a combined zone (den 101d) with sound bar playback device 110h in an exemplary swap mode initiated by control device 130a.

[0215] Before entering the swap mode, the sound bar-type playback device 110h plays audio from the audio input interface in home theater mode (1281b). As a source device for a combined zone including a satellite, the sound bar-type playback device 110h is a master device that distributes audio to the satellite in home theater mode according to its role in the combined zone. Also, if 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 for the zone group.

[0216] At 1282b, control device 130a receives a 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 send 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 the same combined zone as the den 101d (e.g., “den” or a new combined zone (e.g., identified as “den + Ben’s headphones”)).

[0219] 12A , in some examples, in home theater mode, the soundbar playback device 110h and the satellites operate as nodes in 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 the same combined zone as the den 101d, or may be considered 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 begin streaming an 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] Additionally, in some examples, while in swap mode, headphones 710b effectively become satellites of soundbar playback device 110h. Thus, because headphones 710b are using a first Wireless LAN in a first wireless band, soundbar playback device 110h “parks” satellite playback devices 110j, 110k, and 110i on a second Wireless LAN in a second wireless 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 bonding zones when transitioning back to home theater mode) and receive updates regarding the state of media playback system 100 (e.g., state variable events). Soundbar playback device 110h can configure this second Wireless LAN using its 802.11-enabled network interface.

[0222] At 1287b, soundbar 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 network.

[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 splice zones and playback timing information for the audio. In some examples, the audio is multi-channel audio, such as a surround soundtrack. In such examples, the sound bar playback device 110h can downmix the surround sound audio track to an audio track with fewer channels, such as a stereo audio track.

[0224] VIII. Exemplary Swap Methods Methods 1300A, 1300B, 1400, and 1500 shown 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, media playback system 100 of Figure 7A, one or more of playback devices 110a-n, one or more of NMDs 130, one or more of control devices 130, one or more of portable playback devices 710, and other devices described herein and / or other suitable devices. Furthermore, operations illustrated as being performed by a media playback system may be performed by any suitable device, such as a playback device or control device of a 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 shown 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 a different order than described herein. Also, various blocks may be combined into fewer blocks, divided into additional blocks, and / or eliminated based on the desired implementation.

[0225] Furthermore, for the embodiments disclosed herein, a flowchart illustrates the functionality and operation of one possible implementation of the present invention. 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 implement a specific 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 a disk or hard drive. The computer-readable medium may include non-transitory computer-readable media, such as register memory, processor cache, and computer-readable media that store short-term data, such as random access memory (RAM). The computer-readable medium may also include non-transitory media, such as secondary or persistent long-term storage devices, such as read-only memory (ROM), optical or magnetic disks, compact disk read-only memory (CD-ROM), etc. 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. Additionally, in the embodiments disclosed herein, each block may represent a circuit wired to perform a specific logical function in a process.

[0226] a. How to pull an example swap Method 1300A illustrates an exemplary pull-swap technique. A portable playback device, such as headphones 710a, earbuds 710b, or portable playback device 710c, can perform the 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, the 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 the portable playback device 710 and one or more source playback devices when the portable playback device 710 is not currently playing audio content. In some examples, the portable playback device 710 receives the playback session swap input via a user interface. For example, as described in connection with FIG. 10, the headphones 710a may receive a touch-and-hold input. Alternatively, the 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 described in Section VI, the set of eligible source playback devices may be filtered using various other factors, such as the type or role of the playback device.

[0229] In some examples, the portable playback device 710 identifies one or more source playback devices through 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 causing the set of swap-eligible playback devices to 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 specific audio content of the playback session.

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

[0232] b. How to push an example swap Method 1300B illustrates an exemplary 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, the portable playback device 710 may receive data representing a first playback session swap input. As described in connection with Section VI, if the portable playback device 710 is currently playing audio content, the playback session swap input can initiate a push swap between the portable playback device 710 and one or more target playback devices. In some examples, the portable playback device 710 receives the playback session swap input via a user interface. For example, as described in connection with FIG. 10, the headphones 710a may receive a touch-and-hold input. Alternatively, the 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 the 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 through 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 causing the set of swap-eligible playback devices to emit respective audio chirps identifying the swap-eligible playback devices they 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 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 synchronized group that includes portable playback device 710 and the one or more target playback devices. By forming the first synchronized group, the one or more target playback devices begin playing specific audio content of the playback session.

[0237] Migrating the playback session can further include stopping playback of the particular audio content on portable playback device 710. In some examples, playback of the particular audio content on one or more source playback devices is stopped by removing 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 exemplary 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, method 1400 includes playing audio while in home theater mode. For example, a sound bar playback device can play audio while in home theater mode. In some examples, the sound bar playback device is a master device of a first synchronization group. For example, an exemplary sound bar is playback device 110h, which can act as a source device for a combined zone of den 101d. This combined zone includes playback devices 110j and 110k and / or playback device 110i, as shown in FIGS. 1K and 1J.

[0240] At block 1404, method 1400 includes receiving an instruction to transition to swap mode. For example, as shown in FIG. 12A, playback device 110h may receive data representing an instruction to transition to swap mode from a wearable playback device, such as headphones 710a. As another example, as shown in FIG. 12B, playback device 110h may receive data representing an instruction to transition to swap mode from 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] 12A and 12B, transitioning from home theater mode to swap mode can include various steps. For example, to facilitate connecting the wearable playback device to playback device 110h as a satellite, 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. Additionally, 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 soundbar 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 Wi-Fi network. 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 transmits 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 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 network. For example, playback device 110h may cause playback devices 110j and 110k and / or playback device 110i to connect to a second Wi-Fi network in a second wireless 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 swap mode simultaneously with the first wearable playback device. For example, while in swap mode, playback device 110h may receive data from a second wearable playback device, such as earbuds 710b or, in other circumstances, headphones 710a, indicating an instruction to enter swap mode. Based on receiving the data indicating the instruction to enter swap mode, playback device 110h causes the second wearable playback device to join a 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 WLAN and a certificate for the first WLAN to the second wearable playback device. For example, after the second wearable playback device connects to the first WLAN formed by playback device 110h, 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 playback device 110h and headphones 710b. At that time, 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, 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 control device 130 or 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, a source playback device (e.g., 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, 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. A further exemplary swap trigger includes detecting proximity of a source playback device (or paired device, e.g., control device 130a) to a particular location, such as the 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 operate 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 playback device 710 detects a specific input representing a swap command, playback device 710 can initiate a playback session swap as the source playback device based on the detection of the specific input. In another example, if control device 130 detects a specific input representing a command to swap playback from playback device 110, control device 130 can initiate a playback session swap with playback device 110 as the source playback device, or can send data to playback device 110 indicating a command to cause playback device 110 to initiate a playback session swap as the source playback device.

[0253] In a further example, the context is based on proximity. For example, if 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 a 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 can initiate a playback session swap with the paired portable playback device 710 as the source playback device, or can 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, one or more target devices are determined based on a predetermined swap pair with the source playback device. For example, as shown in FIG. 11A, kitchen 101h is designated as a predetermined swap pair with headphones 710a. As described above, the swap pair can be configured and / or reconfigured via control device 130 or other suitable 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 ranges, such as a location (e.g., a home), a zone, an area, or an individual device.

[0256] In still further examples, the one or more target devices may be determined based on context. For example, the one or more playback devices may detect a particular input indicating a command to designate the one or more playback devices as target playback devices. In a further example, the one or more target playback devices may be 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 a 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 synchronized grouping between the first playback device 110 and one or more additional playback devices 110. For example, if playback device 110l in master bedroom 101b is determined as a destination device, playback device 110m may also be determined as a source playback device based on the combined pair configuration of playback device 110m and playback device 110l. In another example, if a kitchen + dining room zone group is configured and playback device 110d in the dining room receives a swap input, playback device 110b may also be determined as a source playback device. This facilitates session swaps from all playback devices 110 involved in the playback session.

[0258] At block 1506, method 1500 includes swapping playback sessions from one or more source playback devices to 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 queue, and grouping techniques described in Section V. Other examples are also 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 media playback system 100 via bridge device 860. FIG. 16A shows an example pairing configuration between headphones 710a and bridge device 860a. In contrast to a general-purpose smartphone or tablet that includes bridge features when configured as control device 130, bridge device 860a is configured with hardware and software for interfacing portable playback device 710a with media playback system 100. Bridge device 860a may also include other features to support or enhance media playback system 100.

[0260] Like the control device 130a, the bridge device 860a may include communications 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 can 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, like the control device 130a, the bridge device 860a may include additional communications 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, bridging device 860a is coupled to a specific playback device (e.g., playback device 110c), a combined zone of playback devices (e.g., playback devices 110l and 110m), or a group of playback devices, such as the "kitchen + dining room" group. Alternatively, if a home graph hierarchy is utilized, bridging device 860a may be coupled to a specific set, room, or area. Control of playback device 110 coupled to bridging device 860a via NMD 120 or control device 130 then also controls 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 a "Ben's headphones" set. Configuring the bridge device 860a facilitates control between the paired headphones 710a and 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 including input / output 811. The input / output 811 may include analog I / O 811a (e.g., one or more wires, cables, and / or other suitable communication links configured to carry analog signals) and / or digital I / O 811b. The bridge device 860a further includes electronics 812 and a user interface 813 (e.g., one or more buttons, knobs, dials, touch-sensitive surface, display, touchscreen). 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, 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, electronics 112 optionally includes one or more other components 812j (e.g., one or more sensors, a video display, a touchscreen).

[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 the intended purpose of the bridging device, and therefore, 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) 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 a 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 media playback system 100. To configure bridge device 860a as a command device 862a, user interface 813a of 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. Similar to control device 130, input to these playback controls is translated into playback commands via software component 812c and sent to one or more playback devices 110 and / or 710 for controlling playback via network interface 812d.

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

[0271] The user interface 813a of the bridge device 860a includes a dial 863a for facilitating 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, 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 input 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 specific 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 can improve the user experience of the paired playback device 710 or the coupled playback device 110 by reducing annoyance, 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 with the bridge device 860b and / or the playback device 110 coupled to the bridge device 860b. Additionally, like the touch-sensitive area 864a, the touch-sensitive area 864b facilitates transport control of the paired portable playback device 710 and / or the coupled playback device 110.

[0276] Buttons 865a-d correspond to respective audio storage locations. Particular audio storage locations 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). Selecting 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, selecting button 865a causes bridge device 860b to send one or more instructions to paired playback device 710 to play the audio repository corresponding to button 865a. The one or more instructions may include a URI that indicates the location of the audio repository on computing device 106 (e.g., a content server of a streaming audio service). The paired playback device 710 then streams the audio repository from computing device 106 and plays the audio repository.

[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 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] 17A presents a first user interface display 1770a configured to 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] First user interface display 1770a includes multiple regions 1771a-f, similar to buttons 865a-d (FIG. 8F). In first user interface display 1770a, regions 1770a-g are selectable via touch input to the respective regions. Each region 1771 corresponds to a respective audio storage location. A particular audio storage location may be pre-configured by the 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). Exemplary audio storage locations include Internet radio stations, playlists, albums, podcasts, and other streaming audio content. Selecting a particular button 865 causes paired playback device 710 and / or coupled playback device 110 to begin playback of the corresponding storage location.

[0281] Here, by way of example, region 1770a is shown in a central position on first user interface display 1770a. Regions 1771b and 1771f are partially shown in lower and upper positions, respectively, on first user interface display 1770a. By scrolling first user interface display 1770a up or down using an upward or downward swipe gesture, respectively, region 1771b or 1771f can be fully displayed, and regions 1771c-e can similarly be displayed in a round-robin fashion. Illustratively, FIG. 17B shows an upward swipe that moves region 1771b toward the central position. FIG. 17C shows region 1771b in the central position after the upward swipe of FIG. 17B. As shown in FIG. 17C, regions 1771a and 1771c are partially displayed when region 1771b is 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 way, 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 fast-forward skips and rewind skips. In particular, a left swipe can cause a fast-forward skip, while a right swipe can cause a rewind skip.

[0284] 17D presents a second user interface display 1770b that may be displayed based on selection of region 1771a. Second user interface display 1770b includes region 1772 that includes a graphical representation of the audio content being played on 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 on the second user interface display 1770b may correlate to a skip forward and a 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] 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 through an audio repository. Selecting an individual audio track or other media item within the audio repository causes the media item to play. 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 (e.g., podcast episodes) available within the repository.

[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 playback device 110 for coupling with the command device 862. To illustrate, FIG. 17F presents a fourth user interface display 1770d having multiple toggle controls 1775 corresponding to respective portable playback devices 710 and zones. Toggling a toggle control 1775 pairs or couples the corresponding portable playback device 710 or playback device 110 with the bridge device. As shown, toggle control 1775a corresponding to headphones 710a is turned on such that 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 (all playback devices 110 will 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 on 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 on 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 that support the portable device 710 of the media playback system. For example, the bridge device 860 can support charging of the portable device 170. To illustrate, FIG. 18B shows an exemplary stacked configuration including a device base 718b that charges the bridge device 860a and the bridge device 860a that charges the earbuds 710b via a charging case 1080. Like 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 in 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 device charging. In this example, device base 718a charges portable playback device 710c. Portable playback device 710c charges bridge device 860a. Bridge device 860a charges earbuds 710b via charging case 1080. In this configuration, only device base 718a requires external power to charge the various stacked devices.

[0294] X. Additional Swap Examples In some examples, the source and target of the swap are predefined. In 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 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 user interface 133 of control device 130a or user interface 813 of bridge device 860a, can facilitate the definition of a predefined swap pair. To illustrate, FIG. 19A presents a first user interface display 1931a for facilitating the definition of a swap pair for headphones 710a (“Ben's headphones”). First user interface display 1931a is configured to display on control device 430 by way of example, but may be adapted to display on other example devices disclosed herein. Control device 430 may display first user interface display 1931a during a setup procedure for headphones 710a. Additionally, a user may display first user interface 1931a via a setup user interface display, among other examples.

[0298] As shown, first user interface display 1931a includes a graphical representation of zones in media playback system 100 (i.e., zone names) and a toggle control corresponding to each zone. Switching a toggle control configures the corresponding zone as a swap pair with headphones 710a. In this example, kitchen 101h is defined as a swap pair with headphones 710c. While toggle controls are shown by way of 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 media playback system 100 (e.g., earbuds 710b and / or portable playback device 710c). Predefined swap pairs may be stored in data storage of control device 130, playback device, and / or 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 the earbud 710b. As shown, each predefined swap pair corresponds to a different input (e.g., a different gesture). Providing an input corresponding to a particular predefined swap pair triggers a swap of that swap pair.

[0301] A user can define a custom input that corresponds 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 earbud 710b of the swap pair and the playback devices 110l and 110m monitor their respective user interfaces 713b and 113 to detect the custom input and then store the custom input in 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 coupled 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 coupling 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 operation) 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 swap triggers.

[0305] In a further example, an input to the user interface 113 of the NMD 120a triggers the swap. For example, a user can utter a voice input of “swap to kitchen.” As described above in connection with FIGS. 3A-3D , the user can activate a voice-assistance service to process the voice input via a wake-up word or button press (e.g., push-to-talk). The voice input includes a first command (“swap”) indicating an action and a second command (“kitchen”) indicating a target playback device for the action. Here, the voice input is sent to the voice-assistance service and processed, 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 execute the playback session swap. Alternatively, instructions corresponding to the processed voice command are forwarded to a server to execute the playback session swap, as described in further detail below in connection with FIGS. 12B and 12C . Following the swap, the NMD 120a can 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 with 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 the position within 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 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 begins 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 the 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 media playback system 100 from other media playback systems. As a further example, a group identifier may identify devices in a zone, combined zones, or zone group.

[0309] The play session data may further include data representing the play state. The play state may include the 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 the 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 media playback system 100 may use the queue version to maintain consistency. The queue version may be incremented each time the queue is changed 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, 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 allow the target playback device to access 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, Figure 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 (Figure 7G) or the paired bridge device 860a (Figure 16A).

[0313] At 2081a, the source playback device initiates a playback session. The playback session may be initiated at the source playback device, control device 130, or 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, control device 130, device base 718, or bridge device 860) detects the swap trigger and sends data to the source playback device indicating that the swap trigger has been 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 the source of the audio content currently being played 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 the position in the audio content from which playback should begin. 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 the order of the queued media items. Furthermore, 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 on 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 the acknowledgement message from the target playback device. The acknowledgement message may indicate that the swap was successful.

[0319] Another exemplary implementation utilizes a cloud queue to facilitate playback session swaps. In contrast to a queue in the playback device's 110 data storage (i.e., a local queue), the playback session's cloud queue is maintained in the cloud on the computing device 106. In this implementation, rather than locally controlling the playback devices 110a-n over the network 104, the control device 130a controls the playback devices 110a-n through the computing device 106 by manipulating the computing device's 106 cloud queue. The computing device 106 synchronizes the cloud queue (or a portion thereof) with the playback devices 110 participating in the playback session.

[0320] 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 rather 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, control device 130, or 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, control device 130, device base 718, or bridge device 860) detects the swap trigger and sends data to the source playback device indicating that the swap trigger has been 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 may indicate the target playback device via one or more identifiers. In some examples, such as predefined swap pairs, the cloud queue server may maintain predefined swap pairs for media playback system 100. The swap session message may also include data representing an offset within the audio content that indicates a location in the audio content to begin playback. In examples, the cloud queue server may also track the playback position within the playback session and use the position in the swap session message to verify the playback position. Furthermore, the swap session message may 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 can use the home identifier in the playback session data to identify the cloud queue in 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 can 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 this 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 the source of the audio content currently being played 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 the location in the audio content from which playback should begin. Additionally, 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 the offset of 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 playback sessions. Such messages are representative and may include additional or fewer messages. In some implementations, messages are sent from the paired control device 130a (FIG. 7G) or the paired bridge device 860a (FIG. 16A) rather than from the portable playback device 710 (as the source or target playback device).

[0328] At 2081c, the source playback device initiates a playback session. The playback session may be initiated at the source playback device, control device 130, or 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, control device 130, device base 718, or bridge device 860) detects the swap trigger and sends data to the source playback device indicating that the swap trigger has been 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 cue identifier. The playback session data may also include a URI indicating the 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 can 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, at which time the target playback device starts playing the audio content at the offset in the audio content.

[0334] At 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 destination playback devices perform the swap by forming a synchronization group. As mentioned above, exemplary 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 mute 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 the user interface indicates 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 portable playback device 710 to 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 portable playback device 710, paired control device 130a (FIG. 7G), or paired bridge device 860 (FIG. 16A), the proximity of portable playback device 710 to media playback system 100 is detected via a sensor or wireless communication interface of portable playback device 710, paired control device 130a (FIG. 7G), or paired bridge device 860 (FIG. 16A). This proximity detection initiates a playback session swap between portable playback device 710 and one or more target playback devices 110 in the home.

[0340] To illustrate, in an exemplary implementation, paired control device 130a (FIG. 7G) detects wireless signals indicating the proximity of portable playback device 710 to playback device 110. For example, paired control device 130a (FIG. 7G) can detect (e.g., connect to) an in-home 802.11 network (e.g., network 104) via network interface 132d. Because playback devices 110a-n are connected to network 104, the detection of this network indicates the proximity of paired control device 130a (and, by proxy, 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 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 its current GPS coordinates with 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 within the home. Other examples are possible as well.

[0342] In some examples, verification from the user is required before performing a playback session swap based on proximity. In some examples, the verification is performed via 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 detecting proximity to the playback devices 110a-n.

[0343] 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 nearest playback device 110, among other examples. The second selectable control ("Cancel") cancels the proximity-based swap.

[0344] 21A also shows 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 in 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] Selectable control 2193a causes kitchen 101h to start a new playback session that includes playing a given playlist. In various implementations, example push notification 2191 may include selectable controls 2193 for starting new playback sessions with various types of audio repositories corresponding to the user. For example, each selectable control 2193 may 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 Figure 21A, a third selectable control of the push notification 2191a causes the display of the user interface display to select a different swap target. Illustratively, Figure 21B presents a second user interface display 2131b for facilitating the selection of a swap target. The user interface display 2131b includes a plurality of toggle controls corresponding to respective zones of the media playback system 100 to facilitate the 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 kitchen 101h, the paired control device 130a may detect signals emitted by playback device 110b, as well as other smart devices (e.g., a smart oven, a smart refrigerator, a smart power outlet), and store these signals as markers for kitchen 101h in a profile corresponding to kitchen 101h. The paired control device 130a may also combine this signal data with other sensor data (e.g., altitude) acquired while in kitchen 101h. Markers in a given profile may also be weighted (e.g., signals from playback devices in a given zone may be weighted more heavily than other smart devices in that zone).

[0349] Given stored profiles for 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 with the stored profile 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 that zone are also present in the current signal and / or sensor data. While 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 stored profiles.

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

[0351] Similar to proximity to home, before executing a playback session swap to a zone based on proximity, media playback system 100 can 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. Paired control device 130a may display third user interface display 2131c based on detecting proximity to den 101d.

[0352] In a further example, proximity to a given zone may be determined via user input to a playback device in that zone. For example, a particular user input to playback device 710 (or a paired control device 130a or bridge device 860a) may 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 an associated zone) as the target playback device. The source and target playback devices may be configured to execute 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 that is proximate to the source playback device. To illustrate, FIG. 22A shows an exemplary playback session swap between a portable playback device 710c and a playback device 110e that is proximate 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] 14B shows 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 shown, 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 (which is 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 shows 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 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 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 master bedroom 101b, or a surround sound configuration such as den 101d) or a zone group (e.g., a "kitchen + dining room" zone group). As described above, an example synchronization technique involves 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, when 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 synchronized group placement. 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, the 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, a 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 executes the playback session swap. In a cloud-side implementation, the group member can send one or more messages indicating the playback session swap to the cloud queue server to cause the cloud queue server to execute the swap or to relay instructions to the group coordinator to execute the playback session swap. Alternatively, the group member may send one or more messages indicating the playback session swap to the group coordinator, which then causes the group coordinator to send a playback session swap request to the cloud server.

[0361] XI. Additional Portable Playback Device Examples 23A is a front isometric view of earbuds 2300 including earbud 2310a and earbud 2310b configured in accordance with aspects of the disclosed technology. As shown, 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 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 aspects of the disclosed technology.

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

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

[0383] FIG. 26A is a front view of headphones 2610 configured in accordance with aspects of the disclosed technology.

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

[0385] FIG. 26C is a second side view of 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, references herein to an "embodiment" mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one example embodiment of the present invention. Appearances of this term in various places throughout this specification do not necessarily all refer to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. As such, the embodiments described herein can be combined with other embodiments, as will be understood, either explicitly or implicitly, by one skilled in the art.

[0389] This specification has been presented broadly in terms of illustrative 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 set forth 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 the 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. Accordingly, 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 a purely software and / or firmware implementation, 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 so 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 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 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, via a user interface of the control device, an input representing a command to swap playback sessions.

[0398] Example 8: The method of 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, wherein the touch input performs a first action other than swap.

[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, 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 a playback session swap trigger includes detecting, via a user interface of the bridge device, an input 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 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 that carries at least one processor, data storage, one or more amplifiers, one or more transducers, and one or more batteries, wherein the housing is formed into a handheld speaker.

[0404] Example 14: The method of example 13, wherein detecting a playback session swap trigger includes detecting that a 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: The method described in any preceding example, wherein the one or more target playback devices further comprise 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 storing 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 into (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 a 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 receiving 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 the playback session, the wearable playback device being connected to the first wireless LAN via an 802.11-enabled network interface; and migrating the playback session from the determined one or more source playback devices to the wearable playback device, the migrating comprising: (i) forming a first synchronization group including the wearable playback device and the one or more source playback devices, the forming the first synchronization group comprising 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 comprises 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: The method of 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 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, wherein transitioning the playback session comprises: (i) forming a second synchronization group including the wearable playback device and the one or more target playback devices, wherein forming the second synchronization group comprises causing the one or more target playback devices to start playing specific audio content of the playback session; and (ii) removing the wearable playback device from the second synchronization group.

[0418] Example 28: A method described in any preceding Example 23 to 27, wherein one or more wearable housings of the wearable playback device have touch-sensitive areas, and receiving data representing a 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, where the one or more wearable housings carry the one or more network interfaces, the one or more transducers, the one or more amplifiers, the one or more batteries, the one or more processors, and data storage having stored thereon 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 the method of any 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 storing 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 receiving 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 the playback session, the wearable playback device being connected to the first wireless LAN via an 802.11-enabled network interface; and migrating the playback session from the determined one or more source playback devices to the wearable playback device, the migrating comprising: (i) forming a first synchronization group including the wearable playback device and the one or more source playback devices, the forming the first synchronization group comprising 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 in 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: The method of 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, wherein transitioning the playback session comprises: (i) forming a second synchronization group including the wearable playback device and the one or more target playback devices, wherein forming the second synchronization group comprises causing the one or more target playback devices to start playing specific audio content of the playback session; and (ii) removing the wearable playback device from the second synchronization group.

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

[0433] Example 43: A method as described in any preceding Example 37 to 42, 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.

[0434] Example 44: A method as described in any preceding Example 37 to 43, 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.

[0435] Example 45: The method of any preceding Example 37 to 44, 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 the 802.11-enabled network interface; receiving data representing (i) a service set identifier (SSID) of the second wireless LAN and (ii) a certificate of the second wireless LAN from the master playback device via the 802.11-enabled network interface; disconnecting from the first wireless LAN and connecting to the 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) multi-channel audio via the 802.11-enabled network interface.

[0436] Example 45: The method of any preceding Example 37 to 44, wherein the wearable playback device comprises: one or more network interfaces, wherein 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, wherein the one or more wearable housings carry the one or more network interfaces, the one or more transducers, the one or more amplifiers, the one or more batteries, the one or more processors, and data storage having stored thereon instructions executable by the one or more processors to cause the wearable playback device to perform the method of any of Examples 37 to 44.

[0437] Example 46: The method of Example 45, 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.

[0438] Example 47: A system configured to perform the method of any of Examples 37 to 46.

[0439] Example 48: A device configured to perform the method of any of Examples 37 to 46.

[0440] Example 49: A tangible, ...

Claims

1. 1. A processor-implemented method comprising: detecting a playback session swap trigger corresponding to a playback session while a first playback device is playing audio content during the playback session; (a) determining one or more source playback devices; and (b) determining one or more target playback devices; wherein the one or more source playback devices include a first playback device and the one or more target playback devices include 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; wherein Note that you can transfer the playback session here. forming a synchronization group with the first playback device as a group coordinator and including the one or more target playback devices as group members, wherein the group coordinator is configured to stream the audio content and send playback timing information to the group members to synchronize playback between the group coordinator and the group members; After forming the synchronization group, removing the one or more source playback devices from the synchronization group to (i) stop playback on the one or more source playback devices, and (ii) change a group coordinator of the synchronization group from the first playback device to the second playback device; A method comprising:

2. Migrating the playback session from the determined one or more source playback devices to the one or more target playback devices includes: Muting the first playback device while the transition is occurring. The method of claim 1 , comprising:

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

3. The method of claim 1 or 2, comprising:

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

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

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

7. Detecting the playback session swap trigger corresponding to the playback session includes: (i) by a user touching a touch-sensitive area of ​​the first playback device; (ii) a touch input by a user to a touch-sensitive area of ​​the second playback device. The method of claim 1 , comprising:

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

9. Detecting the input representing the command to swap the playback sessions includes: detecting a touch-and-hold input on a touch-sensitive area of ​​the second playback device; Note that a single touch input here performs a first action that is not a swap. The method of claim 8, comprising:

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

11. the second playback device is paired with a bridge device via a first type of wireless connection, and the second playback device is connected to the first playback device via the first type of wireless connection and a second type of wireless connection between the bridge device and the first playback device; Note that the bridge device has a subset of available playback commands compared to the many available playback commands of the control device. Also, wherein the bridge device comprises a circular housing, and the method further comprises: detecting rotation of the circular housing; and adjusting the playback volume of the first playback device proportionally to the rotation; Including, The method according to any one of claims 1 to 10.

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

13. Detecting the playback session swap trigger corresponding to the playback session includes: Detecting that the housing is placed within a device base.

13. The method of claim 12, comprising:

14. The method of any preceding claim, wherein the first playback device does not include a battery and draws current from wall power.

15. Detecting the playback session swap trigger corresponding to the playback session includes: Detecting a proximity distance between the first playback device and the second playback device. The method according to any one of claims 1 to 14, comprising:

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

17. A system configured to carry out the method according to any of claims 1 to 16.

18. Any of the first playback device and any of one or more target playback devices configured to carry out the method according to any of claims 1 to 16.

19. A tangible, non-transitory computer-readable medium storing instructions executable by one or more processors to perform the method of any of claims 1 to 16.

20. A program that causes a computer to execute the method according to any one of claims 1 to 16.

21. A portable playback device that is a first 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 formed into (a) earbuds or (b) headphones, carrying the at least one processor, the network interface, the one or more amplifiers, the one or more transducers, and the one or more batteries, and a data storage storing instructions executable by the one or more processors to perform the method of any of claims 1 to 16; A portable playback device comprising:

22. A control device configured to carry out the method according to any one of claims 6 to 10 or any one of claims 11 to 16 which relies on claim 6.

Images