CN109314738B

CN109314738B - Wireless audio source switching

Info

Publication number: CN109314738B
Application number: CN201780038712.4A
Authority: CN
Inventors: J·T·何; A·S·科尼亚克; G·J·塞尔费
Original assignee: Dolby Laboratories Licensing Corp
Current assignee: Dolby Laboratories Licensing Corp
Priority date: 2016-06-24
Filing date: 2017-06-21
Publication date: 2020-11-17
Anticipated expiration: 2037-06-21
Also published as: CN109314738A; WO2017223165A1

Abstract

Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for wireless audio source switching are disclosed. One of the methods includes receiving, with a wireless audio sink device, a user input selecting a user interface control corresponding to one of a plurality of paired audio source devices, the wireless audio sink device being a slave device connected with a first master/slave of a first paired audio source device of the plurality of paired audio source devices. The wireless audio sink device initiates a request to become a master device connected with a second master/slave of a second paired audio source device corresponding to the selected user interface control. The wireless audio sink device transmitting a request to the second paired audio source device to become a slave device to the second master/slave connection. The wireless audio sink device receives an audio input from the second paired audio source device and outputs the received audio input.

Description

Wireless audio source switching

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from european patent application No. 16176287.7 filed on 2016, 24 and U.S. provisional application No. 62/354,649 filed on 2016, 6, 24, both of which are incorporated herein by reference in their entirety.

Technical Field

This specification relates to wireless audio output devices.

Background

Some wireless communication protocols operate by designating a device as a master or slave. Thus, in any pair of communication devices, one device is a master and the other is a slave. For example, maintained by the Bluetooth Special interest group of Cokland, Washington, USA

In wireless technology standards, a master device may establish connections with up to seven slave devices simultaneously. However, a slave device can only connect to one master device at a time.

A master device and its connected slave devices are called piconets. Multiple piconets may be linked together, which is referred to as a scatternet.

The establish bluetooth connection begins with an inquiry phase in which the device transmits an inquiry request. Devices listening for queries are said to be in a discoverable state. All devices receiving the query respond with their address.

During the paging phase, the device may act as the master. During the paging phase, the two devices synchronize their clocks. One device sends a series of paging messages and listens for a response from another device. Devices that are listening for paging messages are said to be in a connectable state. If another device responds, the first device becomes the master of the connection and the responding device becomes the slave.

After synchronization during the paging phase, the device establishes an asynchronous connection-less (ACL) connection, which is a low-level communication protocol that can carry all data of the higher-level bluetooth network protocol stack.

After establishing the ACL connection, the device opens a logical link control and adaptation (L2CAP) channel. The device may perform service discovery using the L2CAP channel in order to perform pairing and discover supported profiles and features of the master device.

When a connection is first established, the two devices may perform a pairing process. During the pairing process, the sink device sends a pairing request to the master device. The sink device then prompts the user to enter a Personal Identification Number (PIN) at the host device to complete the pairing process.

Once pairing is completed, the sink device may store the address of the master device in a list of trusted devices that have successfully paired with the sink device. Thus, the trusted device list maintains the address of each paired master device and its associated index. Then, the sink device may skip the pairing process of any master device appearing in the trusted device list.

The bluetooth standard defines a number of application profiles that specify services provided by bluetooth-capable devices. A single device may support multiple profiles. Common profiles include an advanced audio distribution profile (A2DP) that defines how audio data may be streamed from one device to another; an Audio Video Remote Control Profile (AVRCP) that provides an interface for controlling televisions and other audio/video devices; and a handsfree profile (HFP) for communicating with the handsfree sink device. The device may open one or more L2CAP channels to support one or more of the supported profiles.

Disclosure of Invention

This specification describes a wireless audio output sink device that can switch between multiple audio source devices using dedicated user interface controls.

Particular implementations of the subject matter described in this specification can be implemented to realize one or more of the following advantages. The sink device can implement intent-based switching that determines from which audio source to receive audio data based on the user's intent. A user can easily and quickly switch between multiple audio source devices with little user input. After requesting the switch, the user need not provide any additional input to the sink device or any source device to begin receiving audio data at the sink device. The sink device may switch between a plurality of different activities of a single audio source device. When a connected source device becomes unavailable, the sink device does not switch to other sources.

The details of one or more embodiments of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

Drawings

FIG. 1 is a diagram of an exemplary system.

Fig. 2 is a flow diagram of an example process for assigning a dedicated user interface control to one of a plurality of audio source devices.

Fig. 3 is a flow diagram of an example process for a sink device to switch to a new source device.

Fig. 4 is a flow diagram of an example process for a sink device to connect to a new audio source device.

Fig. 5 is a flow diagram of an example process for a sink device to switch to a new source device.

Fig. 6 illustrates an example switching of a sink device between two source devices.

Fig. 7 is a flow diagram of an example process for a sink device to connect to a new audio source device.

Fig. 8 is a flowchart of an example process for handling disconnection of a sink device.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

This specification describes an audio sink device having a switching capability based on a user's intention. This means that the user can cause the audio sink device to switch between the plurality of wirelessly connected source devices using user input, which may be one or more dedicated user interface controls. A "sink device" is an audio output device configured to wirelessly receive audio data from a source device using a wireless communication protocol. Common sink devices include a wireless headset set and a stand-alone wireless speaker.

In this specification, a dedicated user interface control means a user input mechanism that maps user input to a particular source device. For example, the dedicated user interface control may be a physical button, toggle, dial, or switch. The dedicated user interface control may also be a soft user interface control in a particular activation region corresponding to a presence-sensitive surface or display.

Fig. 1 is a diagram of an example system 100. The system 100 includes two sink devices: an earphone set 110 and a wireless speaker set 120. The system 100 also includes three source devices: a mobile phone 130, a laptop computer 140, and a television 150.

Source devices

130, 140, and 150 are devices that may use a short-to-medium-range wireless communication protocol (e.g., bluetooth) to provide audio data to one or more sink devices.

Wireless headset 110 has integrated buttons 112 a-112 c, which are dedicated user interface controls for switching between source devices (e.g.,

source devices

130, 140, and 150). For example, if the user presses the button 112a, the headset 110 may switch to receiving audio data from the mobile phone 130. If the user presses button 112b, the headset 110 may switch to receiving audio data from the laptop computer 140. If the user presses button 112c, the headset 110 may switch to receiving audio data from the television 150.

The wireless loudspeaker group 120 has another type of integrated user interface control: a toggle button 122. Toggle button 122 may be used to cycle through the connected source devices. For example, if the wireless speaker group 120 is connected to the television 150, the wireless speaker group 120 may switch to receiving audio data from the mobile phone 130 when the switch button 122 is pressed.

Fig. 2 illustrates the components of an example sink device 210. The sink device 210 has three dedicated user interface controls: a first source button 202, a second source button 204, and a third source button 206.

The sink device 210 has a switching device table 220 that associates user interface control indices with addresses of corresponding source devices. The sink device 210 also has a trusted device table 230 that associates trusted device indices with addresses of corresponding source devices.

The user may associate one of the dedicated user interface controls during the pairing process. The sink device 210 may be configured to distinguish between user inputs requesting pairing with a new audio source device and user inputs requesting switching to a particular audio source device. For example, the sink device 210 may interpret a short press of a button (e.g., less than 1 second) as a request to switch to the audio source device associated with the button, and may interpret a long press of the same button (e.g., 1 second or longer) as a request to pair with a new audio source device to be associated with the button.

Thus, during state 1, the user may provide a long press on the second source button 204. The sink device 210 interprets this user input as a request to associate the second source button 204 with a new audio source device.

Then, the sink device 210 is paired with the new audio source device. This process will be described in more detail below with reference to fig. 3.

After pairing, the sink device 210 treats the paired audio source device as a trusted device. During state 2, the sink device 210 stores the address of the new audio source device in the trusted device table 230. During state 3, the sink device 210 stores the address of the new audio source device in the switching device table 220, which associates the address of the new audio source device with the user interface control index of the second source button 204.

In some implementations, the sink device can associate each of the dedicated user interface controls with a particular activity on the source device. Thus, a single source device may be associated with multiple user interface controls.

For example, a tablet computer may provide a sink device with multiple sources of audio information, each source corresponding to a particular activity, such as music player audio, movie audio, and system notification audio. The user may associate each activity with a user interface control (e.g., one of the

source buttons

202, 204, or 206).

For example, the user may associate music player audio with the first source button 202 and movie audio with the second source button 204. The user may explicitly select the source button corresponding to the desired activity.

To correlate a particular activity of a device, the sink device 210 can store additional column attributes in the switching device table. The additional column attribute corresponds to an activity identifier for the particular activity. Thus, some rows of the switch table 220 will reference the same address but different activity identifiers.

This additional information may need to be configured by software running on the source device that provides the active identifier to the sink device 210. For example, a mobile phone may install an application that enumerates different activities. Then, during the pairing process, the user can use the application to cause the phone to provide the sink device 210 with the particular active identifier. Then, the sink device 210 stores the received activity identifier in the switching device table 220.

Fig. 3 is a flow diagram of an example process for assigning a dedicated user interface control to one of a plurality of audio source devices. The process may be performed by a suitably programmed wireless audio output device comprising one or more computers. For convenience, the process will be described as being performed by an embedded computer or logic circuit in the sink device. Typically, the audio output device will perform the example process for each of a plurality of primary audio source devices.

The sink device receives a user input requesting pairing of a new audio source device (310).

The sink device determines whether its state is connectable (320). The sink device is in a connectable state when the sink device is listening for paging messages from potential master devices attempting to establish a connection. If the sink device is in a connectable state, the sink device enters a discoverable state (branch to 360).

In the discoverable state, the sink device listens for queries from the master device. The connectable state and discoverable state are not mutually exclusive. Thus, the sink device may already be in a discoverable state. In other words, in step 360, the sink device ensures that it is in a discoverable state in order to discover any new audio source devices within range.

The responsiveness of the sink device can be improved by exiting the connectable state such that the sink device no longer scans for paging messages. Thus, in some embodiments, the sink device exits the connectable state upon entering the discoverable state (360).

Upon entering a discoverable state (360), the sink device is paired with a new audio source device (370). To pair with a new audio source device, the sink device enters a discoverable state to provide its address to the new audio source device. The sink device then enters a connectable state to synchronize with the new audio source device. In some embodiments, the sink device does not need a pairing code in order to pair with the new audio source device.

If the state of the sink device is not connectable (320), the sink device determines whether its state is discoverable (branch to 330). If the status is discoverable, the sink device is ready to be paired with a new source device. Thus, the sink device may then pair with the new audio source device (branch to 380).

If the status of the sink device is not discoverable (330), the sink device may have established a connection with the previous master audio source device and need to tear down this connection before pairing with the new audio source device.

Thus, if the status of the sink device is not discoverable (330), the sink device disconnects all service level connections and all profiles (branch to 340). For example, the sink device may disconnect the ACL and L2CAP connections with the previous master audio source device and disconnect all A2DP and AVRCP profiles.

When these disconnects occur, the sink device will receive a disconnect message from the previous master audio source device (350). Upon receiving the disconnect message, the sink device may then pair with the new audio source device (370).

After pairing, the sink device associates the new paired device with the selected user interface control (380). For example, the sink device can directly associate the address of the new paired device with the user interface control index corresponding to the selected user interface control. For example, if the sink device has multiple buttons, each button can be assigned a respective user interface control index. The sink device can associate each user interface control index with an address of a corresponding paired device in the switching device table.

Table 1 illustrates an example toggle table that associates user interface control indexes with addresses.

User interface control indexing	Address
			1	00025b00ff06
2	00025b00ff01
		3	00025b00ff09

TABLE 1

Thereafter, when the sink device receives a user input requesting to switch to a user interface control that receives audio from a new paired device, the sink device can use the switching device table to obtain the address of the new paired device.

However, in some cases, if the sink device also maintains a trusted device table that associates trusted device indices with addresses, fewer modifications to the wireless protocol stack are required. After pairing, some standard libraries of wireless communication protocols maintain a table of trusted devices. When using these libraries, the sink device assigns a trusted device index to the new paired device and associates the address of the new paired device with the corresponding trusted device index.

Subsequent interaction with the wireless protocol stack uses the trusted device index as input to an Application Programming Interface (API) of the standard library. Thus, instead of using the addresses of the connected devices to perform various operations, the sink device may use the trusted device index.

Table 2 illustrates an example trusted device table that associates trusted device indices with addresses:

trusted device index	Address
			1	00025b00ff09
2	00025b00ff06
		3	00025b00ff01

TABLE 2

By comparing the entries in the table, the sink device can obtain the trusted device index given the user interface control index. This process will be described in more detail below with reference to fig. 7.

The sink device can then optionally store the trusted device table and the switching device table in a persistent memory integrated with the sink device. By storing the trusted device table and the switching device table in persistent memory, the devices need not undergo a pairing process after reboot.

Fig. 4 illustrates components of an example sink device 410. The sink device 410 has three dedicated user interface controls: a first source button 402, a second source button 404, and a third source button 406.

The sink device 410 has a switching device table 420 that associates user interface control indices with addresses of corresponding source devices. The sink device 410 also has a trusted device table 430 that associates trusted device indices with addresses of corresponding source devices.

The user may cause the sink device to switch to a new audio source device by pressing any of the

source buttons

402, 404, or 406.

For example, during state 1, the user may press the second source button 404. During state 2, the sink device 410 can use the user interface control index corresponding to the selected second source button 404 as an index to the switch device table 420 to obtain the address of the requested audio source device.

During state 3, the sink device 410 searches the trusted device table 430 for a matching address. During state 4, after finding the matching address, the sink device 410 obtains the trusted device index of the requested audio source device. The sink device 410 can then use the trusted device index to connect to the requested audio source device.

If the sink device 410 is configured to switch between particular activities of a single source device, the sink device 410 will use the activity identifier stored in the switching device table 420 when establishing a connection with the requested audio source device. However, if the sink device 410 is already connected to the audio source device, the sink device 410 may not need to establish a new connection with the requested source device.

Fig. 5 is a flow diagram of an example process for a sink device to switch to a new source device. The process may be performed by a suitably programmed wireless audio output device comprising one or more computers. For convenience, the process will be described as being performed by an embedded computer or logic circuit in the sink device.

The sink device is paired with two or more audio source devices (510). For example, the sink device may use the process described above with reference to fig. 2-3 for each of the plurality of audio source devices.

The sink device receives a user input requesting a switch from a first paired audio source device to a different second paired audio source device (520). When the sink device receives a request to switch devices, the sink device will typically be a slave device connected to the master/slave of the first paired audio source device.

The sink device can receive user input at a dedicated user interface control. The sink device may also receive user input as voice commands. The sink device can then determine a paired audio source device corresponding to the user input.

As described above, in some cases, if the sink device maintains the switching device table and a separate trusted device table, fewer modifications to the wireless protocol software stack are required. The sink device can then use both tables to obtain the trusted device index for the particular user input. To this end, the sink device obtains a user interface control index for the dedicated user interface control. The sink device then searches the switching device table using the user interface control index to obtain the address of the second paired audio source device. After obtaining the address of the second paired audio source device, the sink device searches the trusted device table to obtain a trusted device index for the second paired audio source device. For example, the system may compare the address of the second paired audio source device to each entry in the trusted device table. When a matching entry is found, the sink device may use the trusted device index of the matching entry as the trusted device index of the second paired audio source device.

The sink device initiates a request to become a master device connected to a master/slave of the second paired audio source device (530). As described above, to become the master device, the sink device may send a paging message and wait for a response from the second paired audio source device. The sink device may then establish a connection with a second paired audio source device.

The sink device can then establish a connection with the second paired audio source device using the trusted device index. However, the sink device does not need to use the trusted device index to establish this connection. In some embodiments, the sink device can directly use the address of the second paired audio source device. In addition, the sink device does not need to use two separate tables to obtain the trusted device index. In some embodiments, the sink device can directly associate the user interface control index with the corresponding trusted device index.

The sink device determines to establish a master/slave connection with a second paired audio source device (540).

The sink device sends a request to a second paired audio source device to become a slave device of the master/slave connection (550). In other words, the sink device sends a request to swap roles in connection with the second paired audio source device.

Fig. 6 illustrates an example switching of a sink device 620 between two source devices 610 and 630. During state 1, the sink device 620 is a slave device in a master/slave connection with the first source device 610. During state 2, the sink device initiates a connection with the second source device 630 as a master device. During state 3, the sink device 620 requests a swap, and the sink device 620 becomes a connected slave device with the second source device 630.

As shown in fig. 5, upon swapping roles, the sink device begins receiving audio input from the second paired audio source device and outputs the received audio input (560). Because the sink device has been paired with multiple master devices, switching to the second paired audio source device requires no further user input after the initial request. For example, if the user interface control is a button, the user can switch the audio source device by simply pressing the button on the sink device. The sink device then seamlessly switches to the second audio source device without any further input by the user at either the sink device or the audio source device.

To explain the function, consider the situation of a user pairing a sink device with a television, a tablet computer, and a mobile phone. The sink device has three buttons, which are respectively assigned to the three devices.

To listen to the television, the user simply presses the first button on the sink device. A connection is established with the television and no other devices are affected.

To listen to the tablet, the user presses a second button on the sink device. The sink device terminates the connection with the television and connects to the tablet computer. The television reacts to the disconnection by restoring the previous audio playback state. The mobile phone is not affected.

To listen to the mobile phone, the user presses a third button on the sink device. The sink device terminates the connection with the tablet computer and connects with the mobile phone.

Fig. 7 is a flow diagram of an example process for a sink device to connect to a new audio source device. The process may be performed by a suitably programmed wireless audio output device comprising one or more computers. For convenience, the process will be described as being performed by an embedded computer or logic circuit in the sink device.

The sink device receives a user input requesting switching to an audio source device (710). For example, the sink device can receive user input at a dedicated user interface control. In some embodiments, the sink device determines the trusted device index of the requested audio source device, e.g., as described above with reference to fig. 2-3. The sink device can then interact with the corresponding audio source device using the trusted device index.

The sink device determines whether its state is connectable (720). If its state is connectable, the sink device cancels all service level connections (branch to 750). In so doing, the sink device clears the random access memory space occupied by one or more previous connections.

The sink device then sends a connection request to the audio source device (770). As discussed above with reference to fig. 5, the sink device may initiate a connection as a master device and then send a request to exchange roles with the audio source device.

If the state of the sink device is not connectable 720, the sink device determines whether its state is discoverable 730. If its state is discoverable, the sink device enters a connectable state (760) and sends a connection request to the audio source device (770).

If the status of the sink device is not discoverable 730, the sink device disconnects all service level connections and profiles 740 and sends a connection request 770 to the audio source device. By disconnecting all service level connections and profiles, the sink device can clear memory occupied by one or more previous connections.

Fig. 8 is a flowchart of an example process for handling disconnection of a sink device. The process may be performed by a suitably programmed wireless audio output device comprising one or more computers. For convenience, the process will be described as being performed by an embedded computer or logic circuit in the sink device.

The sink device receives a user input selecting a paired audio source device (810). Typically, the sink device will have multiple paired audio source devices. As described above, the sink device may store the address of the paired audio source device in the trusted device table.

The sink device establishes a connection with the selected audio source device (820).

The sink device determines that the connection with the audio source device has been lost (830). The connection may be lost for any of a variety of reasons. For example, the audio source device may be out of range, encounter electromagnetic interference, or be powered down.

The sink device waits to reestablish connection with the audio source device without switching to other counterpart devices (840). In other words, instead of searching for the most recently connected device or searching for the next paired audio source device to connect through the trusted device table, the intent-based switching mechanism of the sink device means that the sink device waits for the device to be reconnected. In some embodiments, the sink device is not connected to another source device without explicit user input selecting the other source device.

The sink device determines that the audio source device is available again 850. For example, the audio source device may be powered back on or brought back into range.

The sink device reestablishes a connection with the audio source device (860). The sink device may automatically request establishment of a connection as the master device and then request switching of roles, as described above with reference to fig. 5 to 6.

After reestablishing the connection, the sink device may again receive audio input from the connected audio source device.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in computer software or firmware embodied in tangible media, in computer hardware (including the structures disclosed in this specification and their structural equivalents), or in combinations of one or more of them. Embodiments of the subject matter described in this specification can also be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a tangible, non-transitory storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium can be a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory device, or a combination of one or more thereof. Alternatively or additionally, the program instructions may be encoded in an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.

The term "data processing apparatus" refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further comprise, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (-application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for the computer program (e.g., code that constitutes processor firmware), a protocol stack, a database management system, an operating system, or a combination of one or more of them.

A computer program (also known as or described as a program, software application, module, software module, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a data communication network.

As used in this specification, "engine" or "software engine" refers to a software-implemented input/output system that provides outputs that are distinct from inputs. The engine may be an encoded functional block, such as a library, platform, software development kit ("SDK"), or object. Each engine may be implemented on any suitable type of computing device, such as a server, mobile phone, headset, portable speaker, tablet computer, notebook computer, music player, e-book reader, laptop or desktop computer, PDA, smart phone, or other fixed or portable device that includes one or more processors and computer-readable media. In addition, two or more engines may be implemented on the same computing device or on different computing devices.

The programs and logic flows described in this specification can be executed by one or more programmable computers executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and in particular by, special purpose logic circuitry, e.g., an FPGA or an ASIC, or a combination of special purpose logic circuitry and one or more programmed computers.

A computer suitable for executing a computer program may be based on a general purpose or special purpose microprocessor or both, or any other kind of central processing unit. Typically, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for executing or carrying out instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, the computer need not have such devices. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, such as a Universal Serial Bus (USB) flash drive, to name a few.

Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input may be received from the user in any form, including acoustic, speech, or tactile input.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a described combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, but rather should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the exemplary embodiments (EEEs) listed below. For example, the actions described in the EEE may be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

Various aspects of the invention can be appreciated from the EEEs listed below:

a wireless audio headset comprising one or more audio output devices, a plurality of dedicated user interface controls, one or more data processing apparatus, and one or more storage devices storing instructions operable when executed by the one or more data processing apparatus to cause the one or more data processing apparatus to perform operations comprising:

receiving an indication of a user input selecting one of the dedicated user interface controls, wherein the selected dedicated user interface control corresponds to one of a plurality of paired audio source devices paired with the wireless audio headset, wherein the wireless audio headset is a slave device connected with a first master/slave of a first paired audio source device of the plurality of paired audio source devices;

identifying a second paired audio source device corresponding to the selected user interface control;

initiating a request to become a master device connected with a second master/slave of the second paired audio source device corresponding to the selected user interface control;

determining that the second master/slave connection has been established with the second paired audio source device;

in response to the determination, sending, by the wireless audio headset, a request to the second paired audio source device to become a slave device of the second master/slave connection;

receiving, by the wireless audio headset, an audio input from the second paired audio source device and outputting the received audio input on the one or more audio output devices.

EEE 2. the wireless audio headset of EEE 1, wherein the plurality of dedicated user interface controls are a plurality of physical buttons, each button of the plurality of buttons being assigned to a respective paired audio source device of the plurality of paired audio source devices.

EEE 3. the wireless audio headset of EEE 1 or EEE 2, wherein after receiving the user input selecting the user interface control, no other user input is received by the wireless audio sink device.

EEE 4. the wireless audio headset of EEE 3, wherein no user input is received by any of the plurality of paired audio source devices.

The wireless audio headset of any preceding EEE, wherein identifying the second paired audio source device corresponding to the selected user interface control comprises:

identifying a user interface control index corresponding to the user interface control;

identifying a wireless protocol address associated with the user interface control index;

searching a trusted device table for an entry having the wireless protocol address; and

identifying a trusted device index corresponding to the second paired audio source device; and

initiating the request to become a master device for a second master/slave connection with the second paired audio source device using the trusted device index.

The wireless audio headset of any preceding EEE, wherein the operations further comprise maintaining a separate switch table that associates user interface control indices with wireless protocol addresses.

The wireless audio headset of any preceding EEE, wherein the operations further comprise storing the switch table associating a user interface control index with a wireless protocol address in a persistent data store integrated with the wireless audio headset.

The wireless audio headset of any preceding EEE, wherein the operations further comprise:

determining that a connection with an audio source device has been lost; and

switching to another paired audio source if and only if other user input is received selecting a different audio source device.

EEE 9. the wireless audio headset of EEE 8, wherein the operations further comprise:

determining that the audio source device is again available; and

in response, a connection with the audio source device is automatically reestablished.

identifying a particular activity identifier of the second paired audio source device corresponding to the selected user interface control; and

providing the particular activity identifier to the second paired audio source device, and

wherein receiving the audio input from the second paired audio source device comprises receiving an audio input corresponding to the particular activity identifier.

EEE 11. a method comprising:

receiving, at a wireless audio sink device, a user input selecting a user interface control of the wireless audio sink device, the user interface control corresponding to one of a plurality of paired audio source devices, wherein the wireless audio sink device is a slave device connected to a first master/slave of a first paired audio source device of the plurality of paired audio source devices;

identifying, by the wireless audio sink device, a second paired audio source device corresponding to the selected user interface control;

initiating, by the wireless audio sink device, a request to become a master device connected with a second master/slave of the second paired audio source device corresponding to the selected user interface control;

determining, by the wireless audio sink device, that the second master/slave connection has been established with the second paired audio source device;

in response to the determination, sending, by the wireless audio sink device, a request to the second paired audio source device to become a slave device of the second master/slave connection; and

receiving, by the wireless audio sink device, an audio input from the second paired audio source device, and outputting the received audio input.

EEE 12. the method of EEE 11, wherein after receiving the user input selecting the user interface control, the wireless audio sink device does not receive other user input.

EEE 13. the method of EEE 11 or EEE 12, wherein no user input is received by any of the plurality of paired audio source devices.

EEE 14. the method of any of EEEs 11-13, wherein identifying the second paired audio source device corresponding to the selected user interface control comprises:

EEE 15. the method according to any of EEEs 11 to 14, further comprising maintaining a separate switch table that associates user interface control indices with wireless protocol addresses.

EEE 16. the method of any of EEEs 11-15, further comprising storing the switching device table associating a user interface control index with a wireless protocol address in a persistent data storage area integrated with the sink device.

EEE 17. the method of any of EEEs 11-16, wherein the user interface control is a physical button of a plurality of physical buttons of the sink device, each button of the plurality of buttons being assigned to a respective paired audio source device of the plurality of paired audio source devices.

EEE 18. the method of any of EEEs 11-16, wherein the user interface control is a physical user interface of the sink device that cycles through the plurality of paired audio source devices in response to a subsequent user input.

EEE 19. the method according to any one of EEEs 11 to 18, further comprising:

determining, by the wireless audio sink device, that a connection with an audio source device has been lost; and

switching to another paired audio source by the wireless audio sink device if and only if other user input is received selecting a different audio source device.

EEE 20. the method according to EEE 19, further comprising:

determining, by the wireless audio sink device, that the audio source device is available again; and

EEE 21. the method according to any one of EEEs 11 to 20, further comprising:

identifying, by the wireless audio sink device, a particular activity identifier of the second paired audio source device corresponding to the selected user interface control; and

wherein receiving, by the wireless audio sink device, the audio input from the second paired audio source device comprises receiving an audio input corresponding to the particular activity identifier.

A wireless audio sink device comprising one or more audio output devices, a plurality of dedicated user interface controls, one or more data processing apparatus, and one or more storage devices storing instructions operable when executed by the one or more data processing apparatus to cause the one or more data processing apparatus to perform operations comprising:

receiving, at the wireless audio sink device, a user input selecting a user interface control of the wireless audio sink device, the user interface control corresponding to one of a plurality of paired audio source devices, wherein the wireless audio sink device is a slave device connected to a first master/slave of a first paired audio source device of the plurality of paired audio source devices;

receiving, by the wireless audio sink device, an audio input from the second paired audio source device and outputting the received audio input on the one or more audio output devices.

EEE 23. the wireless audio sink device of EEE 22, wherein after receiving the user input selecting the user interface control, the wireless audio sink device does not receive other user input.

EEE 24. the wireless audio sink device of EEE 22 or EEE 23, wherein no user input is received by any of the plurality of paired audio source devices.

EEE 25. the wireless audio sink device of any of EEEs 22-24, wherein identifying the second paired audio source device corresponding to the selected user interface control comprises:

EEE 26. the wireless audio sink device of any of EEEs 22-25, wherein the operations further comprise maintaining a separate switching device table that associates user interface control indices with wireless protocol addresses.

EEE 27. the wireless audio sink device of any of EEEs 22-26, wherein the operations further comprise storing the switching device table associating a user interface control index with a wireless protocol address in a persistent data storage area integrated with the sink device.

EEE 28. the wireless audio sink device of any one of EEEs 22-27, wherein the user interface control is a physical button of a plurality of physical buttons of the sink device, each button of the plurality of buttons being assigned to a respective counterpart audio source device of the plurality of counterpart audio source devices.

EEE 29. the wireless audio sink device of any one of EEEs 22-27, wherein the user interface control is a physical user interface of the sink device that cycles through the plurality of paired audio source devices in response to a subsequent user input.

EEE 30. the wireless audio sink device according to any one of EEEs 22 to 29, wherein the operations further comprise:

EEE 31. the wireless audio sink device according to EEE 30, wherein the operations further comprise:

The wireless audio sink device according to any one of the EEEs 22 to 31, wherein the operations further comprise:

EEE 33 a computer storage medium encoded with a computer program, the program comprising instructions operable, when executed by data processing apparatus, to cause the data processing apparatus to perform a method according to any one of EEEs 11 to 21.

Claims

1. A wireless audio headset comprising one or more audio output devices, a plurality of dedicated user interface controls, one or more data processing apparatus, and one or more storage devices storing instructions operable when executed by the one or more data processing apparatus to cause the one or more data processing apparatus to perform operations comprising:

identifying a second paired audio source device corresponding to the selected dedicated user interface control;

initiating a request to become a master device connected with a second master/slave of the second paired audio source device corresponding to the selected dedicated user interface control;

2. The wireless audio headset of claim 1, wherein the plurality of dedicated user interface controls are a plurality of physical buttons, each button of the plurality of buttons being assigned to a respective paired audio source device of the plurality of paired audio source devices.

3. The wireless audio headset of claim 1 or claim 2, wherein after receiving the user input selecting the dedicated user interface control, no other user input is received by the wireless audio sink device.

4. The wireless audio headset of claim 3, wherein no user input is received by any of the plurality of paired audio source devices.

5. The wireless audio headset of claim 1 or claim 2, wherein identifying the second paired audio source device corresponding to the selected dedicated user interface control comprises:

identifying a user interface control index corresponding to the selected dedicated user interface control;

6. The wireless audio headset of claim 1 or claim 2, wherein the operations further comprise maintaining a separate switch table that associates user interface control indices with wireless protocol addresses.

7. The wireless audio headset of claim 6, wherein the operations further comprise storing the separate switch device table associating a user interface control index with a wireless protocol address in a persistent data store integrated with the wireless audio headset.

8. The wireless audio headset of claim 1 or claim 2, wherein the operations further comprise:

determining that a connection with an audio source device has been lost; and

9. The wireless audio headset of claim 8, wherein the operations further comprise:

determining that the audio source device is again available; and

10. The wireless audio headset of claim 1 or claim 2, wherein the operations further comprise:

identifying a particular activity identifier of the second paired audio source device corresponding to the selected dedicated user interface control; and

11. A method for outputting audio, comprising:

12. The method of claim 11, wherein after receiving the user input selecting the user interface control, no other user input is received by the wireless audio sink device.

13. The method of claim 11 or claim 12, wherein any of the plurality of paired audio source devices does not receive user input.

14. The method of claim 11 or claim 12, wherein identifying the second paired audio source device corresponding to the selected user interface control comprises:

15. The method of claim 11 or claim 12, further comprising maintaining a separate switching device table that associates user interface control indices with wireless protocol addresses.

16. The method of claim 15, further comprising storing the separate switching device table associating user interface control indices with wireless protocol addresses in a persistent data store integrated with the sink device.

17. The method of claim 11 or claim 12, wherein the user interface control is a physical button of a plurality of physical buttons of the sink device, each button of the plurality of buttons being assigned to a respective paired audio source device of the plurality of paired audio source devices.

18. The method of claim 11 or claim 12, wherein the user interface control is a physical user interface of the sink device that cycles through the plurality of paired audio source devices in response to a subsequent user input.

19. The method of claim 11 or claim 12, further comprising:

20. The method of claim 19, further comprising:

21. The method of claim 11 or claim 12, further comprising:

22. A wireless audio sink device comprising one or more audio output devices, a plurality of dedicated user interface controls, one or more data processing apparatus, and one or more storage devices storing instructions operable when executed by the one or more data processing apparatus to cause the one or more data processing apparatus to perform operations comprising:

23. The wireless audio sink device of claim 22, wherein after receiving the user input selecting the user interface control, the wireless audio sink device does not receive other user input.

24. The wireless audio sink device of claim 22 or claim 23, wherein any one of the plurality of paired audio source devices does not receive user input.

25. The wireless audio sink device of claim 22 or claim 23, wherein identifying the second paired audio source device corresponding to the selected user interface control comprises:

identifying a user interface control index corresponding to the selected user interface control;

26. The wireless audio sink device of claim 22 or claim 23, wherein the operations further comprise maintaining a separate switching device table that associates user interface control indices with wireless protocol addresses.

27. The wireless audio sink device of claim 26, wherein the operations further comprise storing the separate switching device table associating a user interface control index with a wireless protocol address in a persistent data store integrated with the sink device.

28. The wireless audio sink device of claim 22 or claim 23, wherein the user interface control is a physical button of a plurality of physical buttons of the sink device, each button of the plurality of buttons being assigned to a respective counterpart audio source device of the plurality of counterpart audio source devices.

29. The wireless audio sink device of claim 22 or claim 23, wherein the user interface control is a physical user interface of the sink device that cycles through the plurality of paired audio source devices in response to a subsequent user input.

30. The wireless audio sink device of claim 22 or claim 23, wherein the operations further comprise:

31. The wireless audio sink device of claim 30, wherein the operations further comprise:

32. The wireless audio sink device of claim 22 or claim 23, wherein the operations further comprise:

33. A computer readable storage medium having stored thereon instructions which, when executed by data processing apparatus, cause the data processing apparatus to perform the method of any of claims 11 to 21.