Seamless role switching for real wireless earplug headphones

Abstract

The invention relates to seamless role switching for real wireless earbud headphones. Role switching may be performed between wirelessly paired master / slave devices without perceiving glitches in audio. The device negotiates an anchor point, such as a point in time or a point related to other events, in order to perform role switching. To prepare for role switching prior to the anchor point, the device communicates a variety of information, such as information for communicating with the host device after role switching and information for bit processing after role switching. Slave devices may use such information to serve the master role, without the host knowing that role switching has occurred.

Description

Description of the case

[0001] This application is a divisional application of Chinese invention patent application No. 201980094911.6, filed on June 20, 2019. Technical Field

[0002] The present application relates to seamless role switching of true wireless earbuds. Background Art

[0003] Fully wireless earbuds are two earbuds that are wirelessly connected to each other. Typically, such fully wireless earbuds follow a relay format or a sniff format. In the relay format, one earbud serves the master role, while the other earbud serves the slave role. The master earbud receives audio from a host (e.g., a mobile phone or other audio playback device) and then relays the audio to the slave earbud. In the sniff format, one earbud is the primary earbud and the other is the secondary earbud. The primary earbud receives and acknowledges audio packets from the host, while the secondary earbud only receives audio or "sniffs" without acknowledging to the host. If the secondary earbud loses a packet, it asks the primary earbud to retransmit the packet.

[0004] A role switch between two earbuds occurs when the roles of the earbuds change. For example, for the trunk format earbuds, the master becomes the slave, and the slave becomes the master. For the sniff format earbuds, the primary earbud becomes the secondary earbud, and the secondary earbud becomes the primary earbud.

[0005] A wireless earbud in a relay format typically has a first asynchronous connectionless (ACL) link between a host device and a master earbud, where the master earbud is a Bluetooth slave earbud in the ACL link. A second ACL link exists between the master earbud and the slave earbud. In the second ACL link, the master earbud is a Bluetooth master earbud, and the slave earbud is a Bluetooth slave earbud.

[0006] In this format, it is difficult to achieve seamless role switching. For example, most (if not all) configuration files between the master earbud and the host device in the ACL link need to be silently transmitted to the slave earbud so that after the role switch, the new master earbud can continue to receive audio packets. In addition, when the old master earbud becomes the new slave earbud and the old slave earbud becomes the new master earbud, a Bluetooth role switch is also required, because the master earbud should also be a Bluetooth master earbud to effectively perform Bluetooth transmission. In fact, the master-slave role switch requires the master earbud to first request the host device (e.g., a smart phone) to pause audio playback, and then disconnect from the host. Then, the slave earbud establishes a connection with the host device and becomes the new master earbud. Then, the new master earbud will establish a connection with the new slave earbud and relay the phone audio content to the new slave earbud. So far, the role switch is considered to be complete and the audio can be restored. However, because the audio needs to be stopped without user intervention during this process, the user will hear audio glitches and perceive the audio quality of the earbuds as poor. This is especially true in situations where role switching may occur more frequently. Summary of the invention

[0007] For example, a role switch may be desirable if the slave earbud has a better received signal strength, if the master earbud has a lower battery level than the slave earbud, if the master earbud is removed from the user's ear or placed in a case, etc. The present disclosure provides for role switching between paired accessories such as earbuds in a seamless manner to avoid audio glitches. The host device may be unaware of role switching between accessories.

[0008] One aspect of the present disclosure provides a wireless accessory device, comprising: a wireless communication interface adapted to communicate with a host device and a second wireless accessory device; a memory; and one or more processors in communication with the memory. The one or more processors may be configured to perform a first set of operations to perform a role switch from a master mode to a slave mode, the first set of operations comprising negotiating an anchor point for the role switch, sending logical link information for communicating with the host device to the second wireless device, sending bit processing information to the second wireless device, performing the role switch at the negotiated anchor point, and receiving a packet relayed by the second wireless device after the anchor point.

[0009] The anchor point may be a point in time of a predetermined length in the future, where the predetermined length corresponds to the amount of time required to send the logical link information and to send the bit processing information. In other examples, the anchor point may correspond to a specific event, such as obtaining a specific state or transmission of a packet. According to some examples, sending the bit processing information may include exchanging a cyclic redundancy check state and a header error check state with the second wireless device. The bit processing information may include, for example, a decoder state. The one or more processors may also send an adaptive frequency hopping (AFH) channel map.

[0010] According to some examples, the one or more processors may also be configured to perform a second set of operations to switch the role from the slave mode to the master mode. Such a second set of operations may include: negotiating a second anchor point for role switching; receiving logical link information from the second device to communicate with the host device; receiving bit processing information from the second wireless device; assuming the master mode at the negotiated anchor point; receiving packets directly from the host device after switching the anchor point; and relaying the received packets to the second device.

[0011] Another aspect of the present disclosure provides a method for role switching from a slave role to a master role. The method may include: using one or more processors to negotiate an anchor point for role switching; receiving logical link information from a wirelessly paired device in a master role, the logical link information being used to communicate with a host device; receiving bit processing information from a wirelessly paired device in a master role; establishing direct communication with the host device using the received logical link information at or after the anchor point; and receiving packets directly from the host device after switching the anchor point.

[0012] Another aspect of the present disclosure provides a method for role switching from a master mode to a slave mode, comprising negotiating an anchor point for role switching by one or more processors of a first device operating in the master mode; sending logical link information for communicating with a host device to a second device operating in the slave mode by one or more processors; sending bit processing information to the second device by one or more processors; performing the role switching to the slave mode at the negotiated anchor point; and receiving a packet relayed by the second device after the anchor point. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a block diagram illustrating an example system in accordance with aspects of the present disclosure.

[0014] Figure 2 yes Figure 1 An example visual diagram of a system with

[0015] FIG. 3A to FIG. 3F is a visual diagram illustrating role switching according to aspects of the present disclosure.

[0016] Figure 4 is a block diagram illustrating an example packet header in accordance with aspects of the present disclosure.

[0017] Figure 5 is an example flow chart illustrating an example bit processing process according to aspects of the present disclosure.

[0018] Fig. 6A is an example circuit diagram of a register for generating a HEC status according to aspects of the present disclosure.

[0019] Figure 6B is an example circuit diagram of a register for generating a CRC status according to aspects of the present disclosure.

[0020] Figure 7 is an example circuit diagram of a register for data whitening according to aspects of the present disclosure.

[0021] Figure 8 is an example sequence diagram illustrating role switching according to aspects of the present disclosure.

[0022] Fig. 9 is a functional block diagram illustrating an example system in accordance with aspects of the present disclosure.

[0023] Fig.10 is a flow chart illustrating an example method according to aspects of the present disclosure. DETAILED DESCRIPTION

[0024] The present disclosure provides role switching between earbuds or other paired wireless accessories with master / slave roles in a manner that is transparent to the host device. No audio pause or disconnection is required during the switching process. Therefore, the switching can be performed with perceptible continuity of the audio stream.

[0025] A first wireless accessory device (such as a first earbud) in a master role requests to act as a master device to both a host device and a second device in a slave role. In this regard, the first device may be a master clock for both a host connection between the first device and the host and a device connection between the first device and the second device. Both the first device and the second device listen to the host. The first device in the master role receives audio content from the host and relays the audio content to the second device in the slave role. The second device in the slave role also listens to the host device between receiving relayed audio from the master earbud to monitor the signal strength between the second (slave) device and the host. The second (slave) device need not receive audio content directly from the host.

[0026] When the first device in the master role observes that its signal strength drops below a preset threshold, it sends a message to the second device to request its signal strength. If the second device in the slave role has a better signal strength than the first device within a predefined period of time, the first device can request a role switch with the second device.

[0027] When the role switching process begins, the first device in the master role does not need to request the host device to pause audio or disconnect from the host device. Instead, the first device and the second device communicate information. In particular, the first device and the second device agree on a predetermined switching anchor point (such as a time point for performing the role switching). The first device in the master role also provides an audio link header for communicating the host device to the second device in the slave role. In this regard, the second device can use the audio link header to communicate with the host device starting at the switching anchor point. The first device and the second device also exchange cyclic redundancy check (CRC) and header error check (HEC) states from different randomization cores. This allows continuity of bit processing. The first device also provides its alternative frequency hopping (AFH) channel mapping to the second device. This can be performed at any time when the AFH channel mapping changes so that the second device can listen to the host to determine its updated signal strength with respect to the host. After the role switch, when the second device has become the new master earbud headset, the audio decoder state can be sent from the first device (old master earbud headset) to the second device (new master earbud headset). This may allow continued decoding of audio packets on the second device in the new master role.

[0028] Figure 1 An example system 100 is illustrated, including a host device 105 communicatively coupled to a first accessory device 110. The first accessory device 110 may be one of a pair of accessory devices such as earbuds, wireless speakers, etc. The first device 110 may operate in a master role. To this end, in addition to being coupled to the host device, the first device 110 is also communicatively coupled to a second accessory device 120 operating in a slave role.

[0029] The connection between devices 105, 110, 120 can be, for example, a short-range wireless pairing, such as Bluetooth. For example, the host device 105 can be connected to the first device 110 via a host communication link 152 (such as a first asynchronous connectionless (ACL) link, a synchronous connection-oriented (SCO) link, etc.). The first device 110 can be connected to the second device 120 via a relay communication link 154 (such as a second ACL link).

[0030] Figure 2 Pictured Figure 1An example of a system in which the host device is a mobile phone 205, the first device operating in a primary role is a first earbud 210, and the second device operating in a secondary role is a second earbud 220. A host communication link 252 exists between the phone 205 and the first earbud 210, and a relay communication link 254 exists between the first earbud 210 and the second earbud 220.

[0031] Although the host device in this example is illustrated as a mobile phone, it should be understood that the host device can be any of various types of devices suitable for transmitting audio signals. For example, the host device can be a tablet computer, a smart watch, a gaming system, a music player, a notebook computer, a personal digital assistant device, or any other computing device. Similarly, the first accessory and the second accessory, although shown here as earbud headphones 210, 220, can be any combination of speakers or other audio devices, video output displays, etc. in other examples. The first accessory and the second accessory can be paired during manufacturing, or can be sold separately and paired by the user later.

[0032] In some instances, it may be desirable to have the first accessory and the second accessory switch roles. For example, earbuds serving a primary role may have a lower quality signal strength connection with the host than the host may have with a device in a secondary role. Figure 2 In the arrangement of , the first earbud 210 experiences cross-body path loss with respect to the host device 105 because the host device 105 is held on the opposite side of the user's body. In contrast, the second earbud 220 is on the same side of the user's body as the host device 105. Therefore, the second earbud 220 experiences less cross-body path loss than the first earbud 210.

[0033] FIG. 3A to FIG. 3E The figure shows an example of role switching. Figure 3A, the second device 220 operating in slave mode evaluates a potential connection 356 between the host 205 and the second device 220. For example, the second device 220 can listen to the transmission between the host 205 and the first earbud 210 via the host communication link 252. For each transmission, the second earbud 220 can determine a signal quality metric for the potential connection 356 and forward such a metric to the first earbud 210 via the relay link 254. Examples of such a metric can include RSSI, average signal strength, etc. The first earbud 210 can similarly determine such a metric for its communication via the host link 252. The first earbud 210 can forward its determined metric to the second earbud 220. Therefore, the earbuds 210, 220 can negotiate whether to switch roles based on a comparison of the signal quality metrics. According to some examples, the decision whether to switch roles can also be based on other conditions, such as the battery level of the first device and the second device. For example, a device serving a master role may consume more power than a device serving a slave role. Thus, for example, when the battery of the master device is depleted to a predetermined level, it may be desirable to switch roles with the slave device.

[0034] While in some examples the decision whether to swap roles may be made by both the first device 210 and the second device 220, in other examples the decision may be made by only one or a subset of the devices. For example, the second earbud 220 may forward a signal quality metric about the potential connection 356 to the first earbud 210, which compares the signal quality metric with its own metric and decides whether to initiate a role switch. Alternatively, the first earbud 210 may forward its determined metric to the second earbud 220, which performs the comparison and determines whether to initiate a role change.

[0035] like Figure 3A , when the first device 210 and / or the second device 220 decide to swap roles, the first device and the second device communicate information. In particular, the first device 210 and the second device 220 communicate to determine a predefined switching anchor point. The predefined switching anchor point may be a future point in time when the devices will switch roles. The future point in time may be a time when the first device and the second device complete preparations for the switch, a time when the switch has minimal impact on audio quality, or any combination of these or other facts.

[0036] like Figure 3B As shown in , the first device 210 in the master role also provides the second device 220 in the slave role with an audio link header for communicating with the host device 205. In this regard, the second device 220 may use the audio link header to begin communicating with the host device 205 at the handover anchor point.

[0037] like Figure 3C As shown in , the first device and the second device also exchange cyclic redundancy check (CRC) and header error check (HEC) states from different randomization cores. This allows continuity of bit processing. This will be combined with Figures 5 to 7 Further description.

[0038] like Figure 3D As shown in , the first device also provides its alternative frequency hopping (AFH) channel map to the second device. This can be performed any time the AFH channel map changes so that the second device can listen to the host to determine its updated signal strength with respect to the host.

[0039] exist Figure 3E In the example, the first device 210 and the second device 220 exchange roles so that the second device 220 serves the master role. For example, the first device 210 and the second device 220 may have reached the handover anchor point. To this end, the second device 220 starts using Figure 3B The second device 220 uses the audio link header obtained in the packet header to communicate with the host device 205. Because the second device 220 is using the same logical link address from the first device 210, the host 205 may not know that it has begun communicating with a different device.

[0040] exist Figure 3F In the embodiment, when the second device has become the new master device, the audio decoder state can be sent from the first device 210 (old master device) to the second device 220 (new master device). This can allow the audio packets to be continuously decoded on the second device 220 in the new master device role.

[0041] Figure 4 An example packet header 400 for short-range wireless communication, such as Bluetooth, is illustrated. The packet header 400 may include a plurality of bits in a plurality of different fields. For example, such fields may include a logical transport (LT_ADDR) field 410, a type field 420, a flow field 430, an automatic repeat request number (ARQN) field 440, a sequence number field 450, and a header error check (HEC) field 460. It should be understood that these are merely examples of fields included in the packet header 400, and in other examples, additional, fewer, or different fields may be included in the packet header.

[0042] LT_ADDR field 410 refers to the host communication link between the host device and the main accessory device. For example, when each accessory device is paired with the host device, it can receive a default logical transport. For example, each logical transport can include one or more logical links, which can be distinguished by a logical link identifier.

[0043] A first device in a master role passes an audio link header, such as header 400, for communicating with a host device to a second device in a slave role. Such a link header may be passed between the time of the last packet from the host device to the master earbud and the time of the switch anchor point. The second device may use the LT_ADDR field 410 to communicate over a logical transport. In this way, the second device may become a master device and act as a master device starting from the switch anchor point. For example, a first device and a second device may share a logical transport because either device, when serving the master role, assumes communication over a logical transport using the LT_ADDR from the packet header. The host device may not know which device (the first device or the second device) is communicating over a logical transport at a given time and may not notice the switch.

[0044] Figure 5 The packet bit stream formation process is illustrated. To continue the bit processing, the cyclic redundancy check (CRC) and header error check (HEC) status from different randomization cores are exchanged between the first device and the second device. Each header may have a HEC to check the integrity of the header. The HEC can be, for example, an 8-bit word generated by a HEC generator, as shown below Fig. 6A Before generating the HEC, the HEC generator is initialized with an 8-bit value, such as by using an address or other information related to the first device, the second device, or a packet sent between them. The generated HEC is checked, and if the HEC does not check, the entire packet may be discarded.

[0045] CRC and HEC can be used to form a packet bit stream, such as Figure 5 As shown in . For example, the payload of the packet is input, and after the payload CRC has been added, a header is added in front of the payload. The contents of the header are protected by HEC. In order to transmit the packet, the packet can be encrypted and then whitened. The encryption can be any of a variety of forms of encryption, such as AES-CCM, etc. Whitening can, for example, randomize the bit sequence so that its spectrum is almost like white noise. The result can then be encoded and transmitted to the radio frequency (RF) interface. For example, after the payload has been processed and the header has been added to the physical layer (PHY) packet, the PHY packet can be sent to the RF chain for digital modulation and RF carrier modulation so that the packet can be transmitted at a predefined frequency. For received packets, the packet can be decoded, de-whitened, and decrypted for CRC checking.

[0046] The states of the CRC and HEC change with each incoming packet. For example, the CRC and HEC may be generated by feeding information from a received packet into one or more seed control registers (such as a first linear feedback shift register (LFSR) to generate an updated CRC, and a second LFSR to generate the HEC).

[0047] Fig. 6A An example of a first LFSR circuit for generating HEC is shown. For example, data such as header bits are input to the LFSR with the least significant bit (LSB) first. After all header bits pass through the LFSR, what is read out of the LFSR is the HEC.

[0048] Figure 6B An example of a second LFSR circuit that generates a CRC is illustrated. For example, data such as packet payload bits are input to the LFSR with the least significant bit first. For example, a 16-bit LFSR for the CRC can be constructed similarly to the LFSR for the HEC. According to some examples, the leftmost 8 bits can initially be loaded with an 8-bit UAP, while the rightmost 8 bits can be reset to zero. While the data is shifted in, switch S is set in position 1. After the last bit has entered the LFSR, the switch is set in position 2, and the contents of the register can be transferred from right to left. What is read out of the register is the CRC.

[0049] At the beginning of the first link establishment, the CRC and HEC may have different initial values. As long as the latest status of the CRC / HEC can be written to the seed control register, this process can be implemented on the master earbud headset and the slave earbud headset that have switched roles without the host device knowing.

[0050] Figure 7 An example LFSR for data whitening is illustrated. The original seed value for whitening can be obtained from the master clock. Because the master earbud, slave earbud, and host device are all synchronized with the master clock, the whitening process does not require the master earbud and slave earbud to exchange additional state information.

[0051] Encryption may require information to be exchanged between the master earbud and the slave earbud. To avoid this, before the role switch between the earbuds, the master earbud can request the host device to perform a role switch to stop encryption. The master earbud and host role switch can be scheduled at the same time as the master earbud and slave earbud role switch time to avoid the additional time consumption of disabling encryption. After the role switch, the new master earbud can request the host device to resume encryption. In this way, all encryption seeds can start from an initial state so that the master earbud and slave earbud do not need to exchange encryption engine states. If the role switch process takes longer than the approximate time interval between the delivery of two audio packets from the host to the earbud, the master device can respond to the host device with a negative acknowledgment (NACK). This is true even if the master device has received the packet but wants to provide more time to complete starting or stopping encryption.

[0052] In order for the second device to communicate with the host device on the correct channel, the first device sends its alternative frequency hopping (AFH) channel map to the second device whenever the AFH channel map changes. The second device can use the AFH channel map to listen to the host device before becoming the master device, such as updating its measured signal strength about the host device. If the AFH channel map in the first device changes again before switching the anchor point, the first device sends the new AFH channel map to the second device before switching the anchor point so that the second device can jump to the correct channel to communicate with the host device. In other examples, the first device can send an updated AFH channel map to the second device after the anchor point. The timing of whether the updated channel map is sent before or after the anchor point can depend on, for example, whether the host will send a packet to the master device at or shortly after the anchor point.

[0053] After the role switch, the audio packets should be continuously decoded on the second device in its new master role. Therefore, the audio decoder state can be sent from the first device (old master) to the second device (new master). Depending on the codec used, this may result in different amounts of data to be transmitted. For example, different codecs may have encoder states of different complexity of encoder statistics. By way of example only, the Advanced Audio Coding (AAC) codec may have higher complexity than the Low Complexity Subband (SBC) codec. Therefore, codec state transmission may require different amounts of data, depending on the codec. A simplified version is to place the decoder on the second device (new master) in an initial state. When the first packet enters the second device with its new master role, it will be decoded as if the decoder is starting from scratch. The decoder requires frames to speed up and provide a full-scale pulse code modulation (PCM) stream. Speeding up in the middle of the audio stream will cause the audio stream to be silent for a short period of time. However, the first device and the second device can understand that the short period of silence is because the decoder is initialized. Therefore, for some types of traffic, the second device in its new master role can turn on a packet loss concealment (PLC) algorithm to smooth the data as the decoder starts outputting the first frame coming in from the host device to the second device (the new master).

[0054] Figure 8 An example sequence diagram is provided, illustrating a sequence of events before, during, and after a role switch between a first device and a second device. It should be understood that this is merely an example, and in other examples, the order of events may be different, or events may occur simultaneously.

[0055] As shown, the host device 105 transmits packets to the first device 110 serving the master role, which relays the received packets to the second device 120 serving the slave role. The first device 110 and the second device 120 measure and exchange metrics, such as signal strength, battery life, etc. about the host device. Based on these metrics, the first device and the second device negotiate whether to perform a role switch, and if so, negotiate the switch anchor point.

[0056] The first device 110 and the second device 120 can continue to receive and relay packets from the host 105 as they prepare for the role switch before the anchor point. In preparation for the role switch, the first device 110 can send a packet header including logical link information for communicating with the host device. For example, a packet header can be sent before an audio data packet relayed from the host device. The logical link information can be, for example, a LT_ADDR field.

[0057] The first device 110 and the second device 120 exchange HEC and CRC status information. In addition, the first device 110 sends its AFH channel map. Although the map is illustrated as being sent before the anchor point, it may also be sent after the anchor point in other examples. In addition, it should be understood that the HEC / CRC information and the AFH channel map may be sent multiple times, such as at each update.

[0058] At the anchor point, the first device 110 and the second device 120 perform a role switch so that the second device 120 becomes the master device and the first device 110 becomes the slave device with respect to the first device 110. Thus, the second device 120 can start communicating directly with the host 105 using the logical link information received in the packet header.

[0059] The first device 110 may send decoding information to the second device 120 for decoding packets received at the second device 120 from the host 105. Thus, the second device 120 may serve the master role and receive packets from the host 105 and relay the packets to the first device 110.

[0060] Fig. 9 Examples of internal components of a first device 110 and a second device 120 are illustrated. Although several internal components are shown, it should be understood that additional or fewer components may be included. By way of example only, a device may include components typically found in a playback device, such as a speaker, a microphone, and the like. A device may be, for example, a wireless accessory, such as an earbud headset, a speaker, a display, and the like. The device is primarily described below with respect to the first device 110. Although in some examples the second device 120 may be similar or identical to the first device 110, in other examples the second device 120 may be a different type of device. Additionally or alternatively, the second device 120 may have different internal components.

[0061] The first device 110 may include one or more processors 916, one or more memories 912, and other components. For example, the computing device 110 may include one or more sensors 918, a wireless pairing interface 919, and a battery 917.

[0062] The memory 912 may store information accessible to one or more processors 916, including data 914 instructions 915 that may be executed or otherwise used by one or more processors 916. For example, the memory 912 may be any type of memory capable of storing information accessible to a processor, including computing device readable media, or other media storing data that may be read by an electronic device, such as volatile memory, non-volatile memory, and other writable and read-only memory. By way of example only, the memory 912 may be a static random access memory (SRAM) configured to provide fast lookups. The systems and methods may include different combinations of the foregoing, whereby different portions of the instructions and data are stored on different types of media.

[0063] One or more processors 916 may retrieve, store, or modify data 914 in accordance with instructions 915. For example, data 914 may include a short-range wireless communication profile, such as a Bluetooth profile. Data 914 may also include buffered packets, such as an audio buffer with packets received from a host device. Although the claimed subject matter is not limited to any particular data structure, the data may be stored in a computing device register, in a relational database, as a table with multiple different fields and records, an XML document, or a flat file. The data may also be formatted in a format readable by any computing device.

[0064] Instructions 915 may be any set of instructions to be executed directly (such as machine code) or indirectly (such as a script) by one or more processors 916. For example, instructions may be stored as computing device code on a computing device readable medium. In this regard, the terms "instructions" and "programs" may be used interchangeably herein. Instructions may be stored in an object code format to be processed directly by a processor, or in any other computing device language, including scripts or collections of independent source code modules that are interpreted on demand or pre-compiled. The functions, methods, and routines of instructions are explained in more detail below.

[0065] The one or more processors 916 may be a microprocessor, a logic circuit hardwired to the device 110 itself (e.g., logic gates, flip-flops, etc.), or may be a dedicated application specific integrated circuit (ASIC). It should be understood that the one or more processors 916 are not limited to hardwired logic circuits, but may include any commercially available processing unit, or any hardware-based processor, such as a field programmable gate array (FPGA). In some examples, the one or more processors 916 may include a state machine. The processor 916 may be configured to execute instructions 915 to, for example, perform operations such as the following in conjunction with Fig.10 Describe the method.

[0066] One or more sensors 918 may include any of a variety of mechanical or electromechanical sensors for detecting conditions related to role switching. Such sensors may include, for example, accelerometers, gyroscopes, switches, light sensors, barometers, audio sensors (e.g., microphones), vibration sensors, thermal sensors, radio frequency (RF) sensors, etc. In this regard, device 110 may detect conditions indicating that the device should switch roles with its paired device. As an example, a sensor may detect received signal strength, and the received signal strength may be compared to the signal strength of a paired device. Device 110 and its paired device may therefore negotiate whether to switch roles. As another example, a sensor may detect other parameters such as battery life, signal quality, movement, etc.

[0067] The short-range wireless pairing interface 919 can be used to form a connection with other devices, such as a paired second device 120 or a host device, such as a mobile phone providing audio packets. The connection can be, for example, a Bluetooth connection or any other type of wireless pairing. By way of example only, each connection can include an ACL link.

[0068] Although Fig. 9 The processor, memory, and other elements of the device 110 are functionally illustrated as being within the same block, but one of ordinary skill in the art will appreciate that the processor and memory may actually include multiple processors and memories that may or may not be stored within the same physical housing. For example, the memory 912 may be a volatile memory or other type of memory located in a housing different from that of the computing device 110. Furthermore, the various components described above may be part of one or more electronic devices.

[0069] In this example, the second device 120 has an internal architecture similar to that of the device 110. For example, the second device 120 includes a memory 922 that stores data 924 and instructions 925 that can be executed by one or more processors 926. The second device 120 also includes a battery 927, a sensor 928, a communication interface 929 (such as a Bluetooth interface), etc. Although the second device 120 is shown as executing an instruction set 925 that is different from the instructions 915 of the first device 110, it should be understood that both devices 110, 120 can be programmed to perform role switching from primary to secondary and from secondary to primary.

[0070] As mentioned above, instructions 915 and 925 may be executed to perform a seamless role switch. The role switch may be performed at a negotiated anchor point and may be performed without notification, updating, or otherwise involving the host device.

[0071] Fig.101 is a flow chart illustrating an example method 1000 of performing a role switch between a first wireless accessory and a second wireless accessory. As mentioned above, the first device and the second device can be any of several types of devices. For example, the first device and the second device can be a pair of earbuds, surround sound speakers, etc. Although the operations are illustrated and described in a particular order, it should be understood that the order can be modified and operations can be added or added.

[0072] In blocks 1005, 1010, the first device and the second device negotiate whether to switch roles. For example, one or both devices may compare their signal strengths or other conditions measured by the first device and the second device. When the devices determine that a role switch should be performed, the devices further negotiate a switching time anchor point. For example, the anchor point may be selected based on a predetermined delay that allows sufficient time to prepare for the role switch, a random time, a time when the role switch will have a minimal impact on signal quality, or any of a variety of other factors.

[0073] In block 1015, the first device sends logical link information, which is received by the second device in block 1020. For example, the logical link information may be sent in a packet header. For example, the logical link information may be included in an LT_ADDR field of a packet header. The logical link information may be information used by the first device to communicate with the host device. By sharing the information with the second device, the first device allows the second device to communicate with the host device using the logical link information after the role switch.

[0074] In blocks 1025 , 1030 , the first device and the second device exchange HEC / CRC status, thereby supporting continued bit error handling after the role switch.

[0075] In block 1035, the first device sends an AFH channel map, which is received by the second device in block 1040. In block 1045, the first device sends a decoder state, which is received by the second device in block 1050. After the role switch, the second device may use such decoder state to decode packets received from the host device.

[0076] When the devices reach a predetermined switching anchor point, they may switch roles. Thus, in block 1060, the second device begins communicating directly with the host device using the logical link information received in block 1020. The first device transitions to a slave role. To this end, packets received from the host at the second device are relayed to the first device. The host device may not be aware that a role switch has occurred.

[0077] An advantage of the foregoing systems and methods is that they provide role switching without perceptible audio glitches. To this end, it would be beneficial to be able to switch the master / slave role between paired devices as frequently as possible without compromising audio quality. Such switching may be necessary to preserve battery life, improve audio quality (e.g., due to improved signal strength), etc.

[0078] Unless otherwise stated, the foregoing alternative examples are not mutually exclusive, but can be implemented in various combinations to achieve unique advantages. Because these and other variations and combinations of the features discussed above can be utilized without departing from the subject matter defined by the claims, the foregoing description of the embodiments should be understood by way of illustration rather than by the limitation of the subject matter defined by the claims. In addition, the provision of the examples described herein and statements expressed as "such as", "including", etc. should not be interpreted as limiting the subject matter of the claims to specific examples; on the contrary, the examples are intended to illustrate only one of many possible embodiments. In addition, the same reference numerals in different figures can identify the same or similar elements.

Claims

1. A wireless accessory device, comprising: a wireless communication interface adapted to communicate with a host device and a second wireless accessory device; Memory; One or more processors, the one or more processors in communication with the memory, the one or more processors configured to execute a first set of operations to perform a role switch from a slave mode to a master mode, the first set of operations comprising: negotiating with the second wireless accessory device a first anchor point for the role switch from the slave mode to the master mode; receiving, from the second wireless accessory device through the wireless communication interface, logical link information for communicating with the host device; receiving bit processing information from the second wireless accessory device via the wireless communication interface, the bit processing information comprising a cyclic redundancy check status and a header error check status; and In response to receiving the bit processing information, performing the role switch from the slave mode to the master mode at the first anchor point, the role switch from the slave mode to the master mode comprising: receiving a packet from the host device directly after the first anchor point; and The received packet is relayed to the second wireless accessory device.

2. The wireless accessory device of claim 1, wherein the bit processing information further comprises a decoder status.

3. The wireless accessory device of claim 1, wherein the one or more processors further transmit an adaptive frequency hopping (AFH) channel map.

4. The wireless accessory device of claim 1 , wherein the one or more processors are further configured to execute a second set of operations to perform a role switch from the master mode to the slave mode, the second set of operations comprising: negotiating a second anchor point for the role switch from the master mode to the slave mode; transmitting, via the wireless communication interface, logical link information for communicating with the host device to the second wireless accessory device; transmitting the bit processing information to the second wireless accessory device via the wireless communication interface; as well as In response to transmitting the bit handling information, performing the role switch from the master mode to the slave mode at the second anchor point, the role switch from the master mode to the slave mode comprising receiving a packet relayed by the second wireless accessory device.

5. The wireless accessory device of claim 4, wherein receiving the bit processing information comprises exchanging a cyclic redundancy check status and a header error check status with the second wireless accessory device.

6. The wireless accessory device of claim 4, wherein the bit processing information includes a decoder status.

7. The wireless accessory device of claim 4, wherein the one or more processors further receive an adaptive frequency hopping (AFH) channel map.

8. The wireless accessory device of claim 1, wherein the first anchor point is located a predetermined length of time in the future, wherein the predetermined length corresponds to an amount of time required to receive the logical link information and to receive the bit processing information.

9. The wireless accessory device of claim 1, wherein the anchor point corresponds to a specific event.

10. A method for performing a role switch from a slave role to a master role, comprising: negotiating, using one or more processors, with a wirelessly paired device, an anchor point for a role switch, the anchor point being a future point in time; receiving logical link information from the wirelessly paired device in the primary role, the logical link information being used to communicate with a host device; receiving bit processing information from a wirelessly paired device in the primary role, the bit processing information comprising a cyclic redundancy check status and a header error check status; establishing direct communication with the host device using the received logical link information at or after the anchor point; as well as Packets are received from the host device directly after the anchor point.

11. The method of claim 10, wherein the anchor point is located a predetermined length of time in the future, wherein the predetermined length corresponds to an amount of time required to receive the logical link information and to receive the bit processing information.

12. The method according to claim 10 also includes determining by the one or more processors that the role switch will be performed, and the determination is based on the signal strength of the wirelessly paired device in the master role, the signal strength of the wirelessly paired device in the slave role, the battery level of the wirelessly paired device in the master role, or the battery level of the wirelessly paired device in the slave role. The method of claim 10 , wherein the anchor point corresponds to a specific event.

14. The method of claim 10, further comprising initiating the role switch from the slave role to the master role based on sensor data from one or more sensors.

15. The method of claim 14, wherein the one or more sensors are one or more of: an accelerometer, a gyroscope, a switch, a light sensor, a barometer, an audio sensor, a vibration sensor, a thermal sensor, and a radio frequency (RF) sensor.

16. A method performed by a wireless accessory device for role switching from a master mode to a slave mode, the method comprising: negotiating, by one or more processors of the wireless accessory device operating in the master mode, with a second wireless accessory device, an anchor point for a role switch, the anchor point being a future point in time; transmitting, by the one or more processors, logical link information for communicating with a host device to the second wireless accessory device operating in the slave mode; transmitting, by the one or more processors, bit processing information to the second wireless accessory device, the bit processing information comprising a cyclic redundancy check status and a header error check status; performing a role switch to the slave mode at the negotiated anchor point; and A packet relayed by the second wireless accessory device is received after the anchor point.

17. The method of claim 16, wherein the anchor point is located a predetermined length of time in the future, wherein the predetermined length corresponds to an amount of time required to send the logical link information and to send the bit processing information.

18. The method of claim 16, further comprising determining, by the one or more processors, that the role switch will be performed, the determination being based on a signal strength of the wirelessly paired device in the master mode, a signal strength of the wirelessly paired device in the slave mode, a battery level of the wirelessly paired device in the master mode, or a battery level of the wirelessly paired device in the slave mode. The method of claim 16 , wherein the anchor point corresponds to a specific event.

20. The method of claim 16, further comprising initiating the role switch from the master mode to the slave mode based on sensor data from one or more sensors.

Images