Patent Description:
By "configuration", it is meant a set of parameters that determines how data are transmitted between the source device and the sink device. These parameters are referred to as "configuration parameters". By "modifying configuration", it is meant modifying one or several configuration parameters among the set of configuration parameters.

In one or several embodiments, the Bluetooth sink device may be a Bluetooth loudspeaker. By "loudspeaker", it is meant any electroacoustic transducer, which converts an electrical audio signal into a corresponding sound. The term "loudspeaker" includes for instance audio speakers of a stereo system, headphones, earbuds, hearing aids, etc. The audio source device (or simply "source device", or "source") may be, for instance, a mobile phone, a portable game player, a portable media player, a computer, a tablet, a television, a control device of a stereo system, etc. In the following, the source device may also be referred to as "master device".

Bluetooth is a communication standard that is well-known to the person skilled in the art, managed by a group of organizations (Bluetooth SIG) that has issued successive versions. Bluetooth enables a short-distance bidirectional exchange of data (this is a piconet network, which designates a network covering a personal zone). Therefore, the range of Bluetooth equipment is limited to a few tens of meters. Bluetooth uses radio waves that are situated in the UHF band (between <NUM> and <NUM>). Bluetooth aims to simplify connections between electronic devices by removing cable connections. Thus Bluetooth enables cables between a source multimedia device (hi-fi system, car radio, computer, tablet, mobile telephone, etc.) to be replaced by wireless communications and multimedia sink devices such as speakers arranged to play a received multimedia stream. Bluetooth speakers have met with a certain success due to their high portability.

In general, the configuration of a Bluetooth link between a source device and a sink device is determined when the connection is established, and is not modified after. For instance, the master device may send a request to obtain the audio capabilities of the sink device and, based on the response, select the suitable audio parameters of the link.

Some methods have been proposed in the prior art to adapt dynamically the audio bit rate based on the available Bluetooth bandwidth. For instance, <CIT> proposes to dynamically change the bit rate used in the Codec based on conditions of the Bluetooth connection. <CIT> relates to a source device wherein the controller is adapted for changing audio parameters based on the bandwidth between the communicating Bluetooth devices.

In other words, techniques of the prior only propose to dynamically adapt audio parameters based on connection parameters, in order to avoid audio choppiness and to improve the user experience.

Other examples and embodiments of the prior art are presented in the documents <CIT> and <CIT>. Further, reference <CIT> discloses a method and device for automatically switching a working mode of a Bluetooth connection.

However, there may be other situations in which it would be interesting to dynamically modify the configuration of the link, because the configuration adopted when establishing the connection between the Bluetooth devices may not be the most suitable in such situations.

An object of the present disclosure is therefore directed to a method for dynamically changing configuration (not only audio parameters) of a communication link between a Bluetooth source device and a Bluetooth multimedia sink device based on parameters that are not necessarily connection parameters.

The invention is defined by an independent method claim <NUM>, a corresponding apparatus claim <NUM>, and a corresponding non-transitory computer readable storage medium claim <NUM>. The method comprises:.

By "Bluetooth communication link", it is meant a communication link established according any Bluetooth protocol (as described for instance in the Bluetooth Core Specification version <NUM> or in earlier versions of the Bluetooth Core Specification), including Bluetooth BR/EDR (Bluetooth Basic Rate/ Enhanced Data Rate), but also Bluetooth low energy (LE).

In one or several embodiments, the operational parameter may be associated with an operating system running on the Bluetooth device or the second device.

Alternatively, the operational parameter may be associated with an application running on the Bluetooth device or the second device.

In one or several embodiments, the modifying of the configuration parameter may be performed by a Bluetooth Host.

Alternatively, the modifying of the configuration parameter may be performed by a Bluetooth Controller.

In one or several embodiments, the configuration parameter may be one of:.

For instance, the configuration parameter may be one audio configuration parameter among:.

Alternatively, the configuration parameter may be one Bluetooth connection parameter among:.

The Bluetooth device comprises a Bluetooth chip, a processor and a memory configured to:.

In one or several embodiments, the operational parameter may be associated with an operating system of the Bluetooth device or the second device.

In one or several embodiments, the Bluetooth device may further comprise a Bluetooth Controller and the modifying of the configuration parameter may be performed by the Bluetooth Controller.

The Bluetooth device may further comprise a Bluetooth Host, and, alternatively, the modifying of the configuration parameter may be performed by the Bluetooth Host.

In one or several embodiments, the operational parameter may be one of:.

For instance, the operational parameter may be one audio configuration parameter among:.

Alternatively, the operational parameter may be one Bluetooth connection parameter among:.

The non-transitory computer readable storage medium has stored thereon a computer program comprising program instructions, the computer program being loadable into a data-processing unit and adapted to cause the data-processing unit to carry out the steps of the above method when the computer program is run by the data-processing device. Types of non-transitory computer readable storage medium used in certain embodiments of the invention include magnetic hard disk drives (HDD), fixed optical storage media, field programable gate arrays (FPGA), programmable read-only memory (ROM) or flash-RAM devices. These non-transitory computer readable storage medium may be stand-alone or part of a larger Bluetooth enabled system.

Other features and advantages of the method and apparatus disclosed herein will become apparent from the following description of non-limiting embodiments, with reference to the appended drawings.

The present invention is illustrated by way of example, and not by way of lim itation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which:.

<FIG> is a flow chart describing a possible embodiment of the present invention.

The steps of the flow chart of <FIG> may be performed by the master device and/or by the sink device.

In a first step <NUM>, a wireless communication link is established between the master device and the sink device. This wireless communication link may be a Bluetooth link using the Advanced Audio Distribution Profile (A2DP) constructed from several layers defined by the Bluetooth standard.

Audio information is therefore transported <NUM> over the established communication link. For instance, the audio information may be an audio or a stereo stream including packets incorporating audio data.

The device implementing the method may further be configured to detect <NUM> a change of an operational parameter of at least one Bluetooth device among the master device and the sink device.

This change may occur on the side of the master device or on the side of the sink device, whatever the device implementing the method. For instance, the master device may detect a change of one of its operational parameter, but also a change of an operational parameter of the sink device.

As long as no change of an operational parameter is detected (step <NUM>, "N"), the configuration of the wireless communication link between the master device and the sink device is not modified and audio data continues to be transported <NUM> on this communication link, according to this configuration.

When a change of an operational parameter is detected (step <NUM>, "Y"), a new operating mode is determined <NUM> for the communication link between the master device and the sink device.

The configuration of the communication link is then changed based on the determined operating mode, for the data to be transmitted between the master device and the source device according to this operating mode. To this purpose, at least one configuration parameter of the communication link is modified <NUM>. The audio data is then sent/received <NUM> on this reconfigured link.

By "operational parameter" of a Bluetooth device, it is meant a parameter relating to the operation of the Bluetooth device, for instance a parameter relating to the operating system running on the Bluetooth device.

In one or several embodiments, the operational parameter of a Bluetooth device may be associated with an application running on the Bluetooth device. In that case, the Bluetooth device is usually the master device, i.e. the operational parameter is associated with an application running on the master device. The parameter is a type of application (gaming or video streaming) launched or ended on the Bluetooth device, or a specific application launched on the Bluetooth device (e.g. the user is using Spotify® and launches Youtube® on his smartphone).

Indeed, it may be advantageous to modify the configuration of the link when using a specific application or a specific type of application. For example, two streaming applications may not have the same sampling rates, and it may be advantageous to reconfigure the Bluetooth audio link so its sampling rate matches the one of the applications currently launched on the Bluetooth device (and therefore avoid resampling before sending the audio packets). A gaming application may require to activate a low latency mode.

In one or several embodiments, the operational parameter may be related to a multimedia content played by a Bluetooth device, which is usually the master device.

By "operating mode", it is meant a mode relating to a hardware component of one of the master device and the sink device, or a mode for transmitting data from one device to another. For instance, the operating mode may be relating to a power consumption of the master or the sink device (e.g. a power-saving mode), to a quality of the content (e.g. High-Quality mode), to a latency, etc..

The "configuration" of a communication link between a source device and a sink device corresponds to a set of configuration parameters that determines how data are transmitted between the source device and the sink device. These configuration parameters may comprise Bluetooth connection parameters associated with the wireless communication link, and applicative parameters.

By Bluetooth connection parameters, it is meant parameters related to low-level building blocks defined by the Bluetooth standard, such as the "Baseband" building block, the "LMP" ("Link Manager Protocol") building block, the "L2CAP" ("Logical Link Control and Adaptation Protocol") building block, or the "SDP" ("Service Discovery Protocol"). For instance, the Bluetooth parameters may include the number of retransmission, the packet type, the MTU, the FTO (or "Flush Timeout") value, which defines the expiration period for a data packet in a buffer memory of a source device, a QoS ("Quality of service") parameter, which defines the maximum latency between the inclusion of a packet to be transmitted in a L2CAP channel and its effective transmission, etc..

By applicative parameters it is meant parameters related to a chosen application, i.e. related to the application layer. In the Bluetooth standard, audio transmission is defined by the Advanced Audio Distribution Profile (A2DP). The A2DP profile is based on the Audio/Video Distribution Transport Protocol (AVDTP) building block which defines the procedures between Bluetooth devices for establishing the audio stream, negotiating the audio stream parameters and transmitting the audio stream data. Therefore, in case of audio transmission, the applicative parameters may be audio configuration parameters and may comprise:.

It is noted that the determination of the new operating mode in case of a change of an operational parameter may be triggered automatically (e.g. if the battery level is under a predefined threshold or if the derivative of the battery level is under a predefined threshold, the saving-power mode is automatically activated), or manually, by a user action (e.g. when a user starts a game, a "gaming mode" may be activated, or when a user ends a game, the operating mode may switch from a "gaming mode" into a "standard mode").

The modification of configuration of the communication link based on the determined operating mode may be done in several ways. In one or several embodiments, the "reconfigure command" of AVDTP (defined in the AVDTP specification) may be used. This command allows devices participating within a stream to change Application Service Capabilities.

For instance, the following procedure may be used. First, a "Suspend Streaming Procedure" may be performed for suspending the stream. Then, a Reconfigure Command may be used for changing current capability settings. After the reconfiguration, the streaming may be restarted by using the "Start Streaming Procedure".

Other techniques may be used for reconfiguring the communication link, which do not require suspending the streaming procedure (for instance by changing the bitpool of the SBC codec to reduce the bitrate). Thus, the communication link is dynamically reconfigured without interrupting the streaming.

For illustration purposes only, some examples of the method of <FIG> are provided below. Some of these examples are based on the table below, presenting different possible operating modes.

It is assumed that a wireless communication link is already established <NUM> and used to transport <NUM> audio data.

In a first example, the operational parameter is a battery level (of the master device or of the sink device). At step <NUM>, the Bluetooth device performing the method may determine that the battery level falls under a predefined threshold. At step <NUM> it is determined that the current operating mode of the communication link may be modified into a "power-saving mode". In consequence, at least one of the following configuration parameters may be modified (step <NUM>):.

Other configuration parameters may be modified (step <NUM>), for instance one parameter among:.

According to the invention, operational parameter is a type of application. When it is detected at step <NUM> that the type of application launched on the master device is a gaming or real-time video application, it is determined at step <NUM> that the current operating mode of the communication link is modified into a "low-latency mode". In consequence, at least one of the following configuration parameters may be modified (step <NUM>):.

Still in the case where the operational parameter is a type of application, when it is detected at step <NUM> that a type of application (e.g. gaming, audio or real-time video application) is ended on the master device, it may be determined at step <NUM> that the current operating mode of the communication link may be switched into a "standard mode", with default configuration parameters.

Such "standard mode" may also be used in the case where the operational parameter is a battery level, and when it is detected at step <NUM> that the battery level again exceeds a predefined threshold.

In yet another example, the operational parameter is a specific audio application (Spotify®, Apple Music®). When it is detected at step <NUM> that one specific audio application is started on the master device, it may be determined at step <NUM> that the current operating mode of the communication link may be switched into a "high-quality mode". In consequence, at least one of the following configuration parameters may be modified (step <NUM>):.

According to yet another example, when the change <NUM> of an operational parameter corresponds to a change in an audio source from a highly compressed source to a less compressed source, the modification <NUM> of a configuration parameter may comprise:.

According to yet another example, when the master device is a smartphone and the slave system <NUM> comprises two earbuds, the change <NUM> of an operational parameter may correspond to a change in the local source of audio data from a higher quality source to a lower quality source. The wireless communication link may then be reconfigured from a higher quality link with a higher data rate to a lower quality link having a reduced data rate in response to the change.

<FIG> and <FIG> represent different possible embodiment of the present invention.

In <FIG> and <FIG>, the master device <NUM> may be an audio or video source device such as a computer, a tablet device or a smartphone. The master device <NUM> may be connected to a slave system <NUM> comprising at least one sink device. The slave system may be for instance a Bluetooth earbud / earphone, a pair of Bluetooth earbuds / earphones, a Bluetooth loudspeaker or a plurality of Bluetooth loudspeakers.

When there is a plurality of sink devices (e.g. a pair of earbuds), the master device <NUM> may comprise a Bluetooth chip (not represented in <FIG>) arranged to generate several SEPs to control the sink devices <NUM> by creating a point-to-multipoint link between the master device <NUM> and the plurality of sink devices <NUM>. For instance, the Bluetooth chip may generate a distinct Source SEP for each Sink SEP (corresponding to each Bluetooth sink device that it must control). This configuration seemingly consists in point-to-point links, from the source <NUM> to each of the sink devices <NUM>. For example, and for this implementation, it is referred to application <CIT>, which proposes a Bluetooth chip configured to implement a modified A2DP profile so as to create such point-to-multipoint link. In such embodiment, each link from the master device <NUM> to each of the sink devices may be reconfigured.

Of course, other solutions may be used for controlling a plurality of sink devices <NUM> from a master device <NUM>.

For instance, a chained connection may be established between the master device <NUM>, a first earbud and a second earbud (in case of a pair of earbuds <NUM>). The first earbud may be connected to the master device <NUM> according to a first wireless link, for instance a Bluetooth link using the Advanced Audio Distribution Profile (A2DP). A stereo stream including packets incorporating stereo data for both left and right channels may be transmitted from the master device <NUM> to the first earbud. The first earbud may be configured:.

Another solution may consist in a wireless link from the master device <NUM> to one of the two earbuds, while the other earbud is configured to "sniff" (or "snoop") the wireless link. According to this solution, the first earbud may be connected to the master device <NUM> according to a first wireless link, for instance a Bluetooth link using the Advanced Audio Distribution Profile (A2DP). A stereo stream including one or more packets incorporating stereo data for both left and right channels may be transmitted from the master device <NUM> to the first earbud. On the other hand, the first earbud may be connected to the second earbud according to a second wireless link (a Bluetooth link for instance). The first earbud and the second earbud can exchange some parameters, including sniffing/decoding parameters for allowing the second earphone to sniff the first link and to retrieve the audio data relative to the right channel. However, no audio data is exchanged via the second link. According to this solution, the second earbud is not connected to the master device <NUM>, and is configured to sniff the first wireless link.

In one or several embodiments, the master device <NUM> may be configured for transmitting audio information to a slave device <NUM> and may comprise:.

For instance, the master device <NUM> may be a Smartphone for transmitting audio information to a pair of earbuds <NUM>, the earbuds comprising a left earbud and a right earbud, the master device comprising:.

<FIG> is a representation of an example not according to the invention.

The slave system <NUM> may be configured for supporting different types of codecs (e.g. SBC, LDAC, Apt-X, etc.), wherein each codec may be associated to one or several possible bit rates (e.g. LDAC at <NUM> kbits/s, kbps, or <NUM> kbps). Alternatively, the slave system <NUM> may be configured for supporting one type of codec, at different possible bit rates.

The slave system <NUM> has a battery level 202a, 202b and is configured to send a low battery signal to the master device <NUM> when the battery level 202a, 202b falls under a predefined threshold (e.g. <NUM>% of the maximum battery level). For instance, the low battery signal may be sent by using a BLE (Bluetooth Low Energy) transmission or AVRCP (Audio/Video Remote Control Profile) profile.

In this example, the operational parameter is the battery level 202a, 202b, of the slave system <NUM>. The fact that the battery level 202a, 202b falls below the predefined threshold corresponds to the change of the operational parameter, as defined above with reference to <FIG>. The new operating mode may be a power-saving mode, and the reconfiguration of the link (or the links in case of point-to-multipoint transmission) may include modifying the type of codec and/or the bit rate (e.g. reducing the bit rate).

According to an example, while the battery level 202a of the slave system <NUM> is above a predefined threshold, the master device <NUM> may send <NUM> to the slave system <NUM> audio packets processed via a first codec type (e.g. stereo LDAC at <NUM> kbps). When the battery level 202b of the slave system <NUM> falls under the predefined threshold, the slave system <NUM> sends <NUM> a low battery signal to the master device <NUM>. Upon reception <NUM> of this low battery signal, it is determined, at the master device <NUM>, that the Bluetooth audio link has to be switched into a power-saving mode, in which the audio packets to be sent <NUM> to the slave system <NUM> are processed via a second codec type (e.g. stereo SBC at <NUM> kbps).

Optionally, upon reception <NUM> of the low battery signal, a message may be displayed on a screen of the master device <NUM> for requesting a confirmation from the user that the master device <NUM> may be switched into the power-saving mode. In this case, the modification of the configuration of the link / links is triggered by an explicit action of the user.

Alternatively, the master device <NUM> may be automatically switched into the power-saving mode, without any confirmation of the user. In this case, the modification of the configuration of the link / links is triggered without any action of the user.

According to another example, while the battery level 202a of the slave system <NUM> is above a predefined threshold, the master device <NUM> may send <NUM> to the slave system <NUM> audio packets processed via a first codec type (e.g. stereo LDAC at <NUM> kbps). When the battery level 202b of the slave system <NUM> falls under the predefined threshold, it is determined, at the slave system <NUM>, that the communication link has to be switched into a power-saving mode. The slave system <NUM> may then send to the master device <NUM> information relative to configuration parameter(s) modified based on this new operating mode. After receiving the information, the master device <NUM> may process audio packets with a second codec type before sending them to the slave system <NUM>.

Of course, a similar reconfiguration method may be applied in the case where the operational parameter is the battery level of the master device <NUM>. In such case, a low-power level of the battery of the master device <NUM> may be detected. Upon such detection, some configuration parameters may be modified. For instance, a data rate for the wireless link may be reduced.

<FIG> is a representation of an embodiment of the present invention.

The slave system <NUM> may be configured for supporting different types of codecs (e.g. SBC, LDAC, Apt-X, etc.), wherein each codec may be associated to one or several possible bit rates (e.g. LDAC at <NUM> kbit/s, kbps, or <NUM> kbps). Alternatively, the slave system <NUM> may be configured for supporting one type of codec, at different possible bit rates.

In this embodiment, the operational parameter is a specific application launched on the master device <NUM>. A change of the operational parameter is detected when the user changes the application launched on the master device <NUM> (for instance, the user uses Spotify® instead of Youtube®). Indeed, two applications, even if they belong to a same type of application (for instance, a streaming application) may not have the same sampling rates, and it may be advantageous to reconfigure the Bluetooth audio link so its sampling rate matches the one of the applications currently launched. Such reconfiguration avoids the audio server of the master device <NUM> to have to resample the audio data, which degrades the audio quality.

In this embodiment, the modification of the configuration of the link / links is implicitly triggered by an action of the user (the change of application).

Referring again to <FIG>, the user may use a first application for which the audio packets are processed by a first codec at a first sampling rate (e.g. a stereo SBC at a sampling frequency of <NUM> and a bit rate of <NUM> kbps) and sent <NUM> to the audio slave system <NUM>. When the user launches <NUM> a new application on the master device <NUM>, the sampling frequency and/or the bit rate of the codec may be changed. After this change, the audio packets are processed by a second codec at a second sampling rate (e.g. a stereo SBC at a sampling frequency of <NUM> and a bit rate of <NUM> kbps).

<FIG> is a representation of a second possible embodiment of the present invention.

In this embodiment, the operational parameter is a type of application launched on the master device <NUM>, for instance a gaming application (e.g. PlayerUnknown's Battlegrounds® - PUBG, Fortnite®, etc.). A change of the operational parameter is detected when the user starts a given type of application on the master device <NUM>. Indeed, some types of application require specific operating modes: for instance, a low-latency mode may be necessary to have a better gaming experience. Therefore, if the Bluetooth slave system <NUM> supports such low-latency mode, it is advantageous to reconfigure the link between the master device <NUM> and the slave system <NUM> into a low latency configuration.

In this embodiment, the modification of the configuration of the link / links is implicitly triggered by an action of the user (starting a specific type of application).

Before starting the application, the Bluetooth communication link between the master device <NUM> and the slave system <NUM> may correspond to a first operating mode (e.g. a standard mode in which the latency between the source and the decoded audio may be relatively high), in which the audio packets are processed by a first codec having a first latency and sent <NUM> to the audio slave system <NUM>. When the user launches <NUM> a specific type of application (e.g. gaming) on the master device <NUM>, the codec may be changed to have a second latency which is much lower than the first latency. The audio packets are then processed by the new codec and sent <NUM> from the master device <NUM> to the slave system <NUM>.

Such low latency mode may be activated in other situations, for instance, when the operational parameter is a local source of audio data, and when the change of this operational parameter corresponds to a change of application (e.g. switching from music playing to video gaming).

Alternatively or in complement, in such situations, one or several of the following configuration parameters may be modified:.

Of course, more than one configuration parameters may be modified. For instance, it is possible to modify both the MTU and the sampling rate.

In this example, the slave system <NUM> may consist of a pair of earbuds 201a, 201b.

By default, each earpiece may be configured for outputting respective audio data. For instance, for a stereo audio content, the first earbud 201a may be configured to play audio data relative to one of the two channels (for instance, the right channel), and the second earbud 201b may be configured to play audio data relative to the other one of the two channels (for instance, the left channel).

When two users <NUM>, <NUM> want to share an audio content with another user <NUM>, each user <NUM>, <NUM> may use a respective earbud 201a, 201b among the pair of earbuds connected to a master device <NUM>. However, in the default configuration described above, there is a lack of auditory comfort for the users <NUM>, <NUM>, since each user <NUM>, <NUM> only receives audio content corresponding to one of the two channels.

Therefore, it may be interesting to activate a "sharing mode", in which the audio data sent <NUM>, <NUM> to each earbud 201a, 201b incorporate stereo data.

For example, in the default configuration, the transmission of audio packets may be performed based on a first codec (e.g. an SBC codec), the right earbud 201a being configured for playing audio data corresponding to the right channel and the left earbud 201b being configured for playing audio data corresponding to the left channel. For instance, the first codec may be a stereo codec in case of a forwarding architecture, or a mono codec in a point-to-multipoint architecture.

In the sharing mode, the transmission of audio packets may be performed based on a second codec (e.g. an SBC codec), wherein each packet includes data corresponding to both of the left and the right channel and is sent <NUM>, <NUM> to both earbuds 201a and 201b. Therefore, both earbuds 201a and 201b are configured to play a same audio content based on the received packets. The second codec may be a mono codec, or a stereo codec with a same audio content on the two channels. An audio content may correspond for instance to a downmixed channel of a left channel and a corresponding right channel.

In a possible example, the user may select the "sharing mode" on the master device <NUM> or on the slave system <NUM>. In this case, the modification of the configuration of the link / links is explicitly triggered by an action of the user.

Alternatively, the sharing mode may be automatically activated, for instance, when it is detected that the distance between the two earbuds 201a, 201b is above a predefined threshold.

<FIG> is a possible embodiment for a device that enables the present invention. Such device may be incorporated into the master device or into the slave device.

In this embodiment, the device <NUM> comprises a computer, this computer comprising a memory <NUM> to store program instructions loadable into a circuit and adapted to cause circuit <NUM> to carry out the steps of the present invention when the program instructions are run by the circuit <NUM>.

The memory <NUM> may also store data and useful information for carrying the steps of the present invention as described above.

This computer may comprise an input interface <NUM> for receiving information relative to a change of value of an operational parameter in either the Bluetooth device or the second device according to the invention, and an output interface <NUM> for providing a configuration parameter of the Bluetooth communication link based on a new operating mode.

To ease the interaction with the computer, a screen <NUM> and a keyboard <NUM> may be provided and connected to the computer circuit <NUM>.

Furthermore, the block diagram represented in <FIG> is a typical example of a program which some instructions can be performed by the device described <NUM>. <FIG> may thus correspond to the flowchart of the general algorithm of a computer program within the meaning of the invention.

In one embodiment of the invention the Bluetooth operation is conducted by a Bluetooth driver stored in a first section of the memory <NUM>, while the operational parameters are determined with an operating system stored in a second section of memory <NUM>. Additionally, the operating system may interface with one or more applications to determine one or more operational parameters, where the application is located in a third section of memory <NUM>. This advantageously separation of these functions allows for independent development of each without the need to alter the other functions at the same time.

Of course, the present invention is not limited to the embodiments described above as examples. It extends to other variants and other situations than those presented above.

For example, when the change of an operational parameter corresponds to a change in an audio source application from a conferencing application to a streaming application, the modification of a configuration parameter may comprise changing a sound quality configuration parameter of an audio codec to a higher quality, wherein the audio codec processes information associated with the streaming application.

The sound quality configuration parameter may be for instance a sampling rate for an audio codec, an audio codec selection parameter, or a configuration parameter changing the channel configuration from mono to stereo.

According to another example, when the change of an operational parameter corresponds to a change in an audio source application from a streaming application to a conferencing application, the modification of a configuration parameter may comprise changing a channel configuration parameter from a unidirectional audio link to a bidirectional audio link.

When the slave system <NUM> consists in two earbuds 201a, 201b, it can happen that one of the two earbuds is disabled (e.g. if the communication link is interrupted to this earbud). In such a situation, it may be detected that one earbud is deactivated, and the channel configuration may be switched from stereo to mono. The deactivation of one earbud may be performed, for instance, by receiving a message on the master device.

A similar change may be performed when a change in the local source of audio data from a stereo source to a mono source is detected. The wireless communication link may be reconfigured from a stereo link to a mono link in response to said change, and the audio data are then transmitted to the earbuds in mono format.

Depending on the embodiment chosen, certain acts, actions, events or functions of each of the methods described herein may be performed or occur in a different order from that in which they were described, or may be added, merged or not to be performed or not to occur, as the case may be. In addition, in some embodiments, certain acts, actions or events are performed or occur concurrently and not successively.

Claim 1:
A method for operating a Bluetooth device (<NUM>), the method comprising:
transporting (<NUM>) audio information over a Bluetooth communication link established (<NUM>) with a second device;
determining (<NUM>), upon a change (<NUM>) of value of an operational parameter in either the Bluetooth device (<NUM>) or the second device, a new operating mode for said Bluetooth communication link;
modifying (<NUM>) a configuration parameter of said Bluetooth communication link based on the new operating mode;
transporting (<NUM>) audio information on said Bluetooth communication link according to the modified configuration parameter;
wherein the operational parameter is a launch (<NUM>) of a tagged gaming or real-time video application on the Bluetooth device or the second device and the new operating mode is a low-latency mode.