CN115665670A

CN115665670A - Wireless audio system, audio communication method and equipment

Info

Publication number: CN115665670A
Application number: CN202211136691.9A
Authority: CN
Inventors: 朱宇洪; 王良; 郑勇; 张景云
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-11-30
Filing date: 2018-11-30
Publication date: 2023-01-31
Also published as: CN113169915B; CN113169915A; WO2020107491A1

Abstract

The application relates to a wireless audio system, an audio communication method and equipment, and the parameters of isochronous data transmission channels are determined for each audio service by taking the audio service as granularity. Parameter negotiation, such as negotiation of QoS parameters, negotiation of codec parameters, and negotiation of ISO parameters, may be performed between a first audio device (e.g., a handset, a media player) and a second audio device (e.g., a headset) with audio service as granularity, and then an isochronous data transmission channel is created based on the negotiated parameters. No matter which audio service scene is, the stream data can be transmitted through an LE ISO link, and the switching of the service scene does not involve the switching of a transmission frame, so that the efficiency is higher.

Description

Wireless audio system, audio communication method and equipment

Technical Field

The present application relates to the field of wireless technologies, and in particular, to a wireless audio system, an audio communication method, and an apparatus.

Background

Bluetooth (Bluetooth) wireless technology is a short-range communication system intended to replace cable connections between portable and/or stationary electronic devices. The key features of the bluetooth wireless communication technology are stability, low power consumption and low cost. Many features of its core specification are optional, supporting product differentiation.

Bluetooth wireless technology has two forms of systems: basic Rate (BR) and low power consumption (LE). Both forms of systems include device discovery (device discovery), connection establishment (connection establishment) and connection mechanisms. The base rate BR may include an optional Enhanced Data Rate (EDR), and alternating media access control and physical layer extensions (AMPs). Low power LE systems include features designed to implement products requiring lower power consumption, lower complexity, and lower cost than BR/EDR.

A device implementing both BR and LE systems may communicate with other devices that also implement both systems. Some profile and use cases (use cases) are supported by only one of the systems. Thus, devices implementing both systems have the ability to support more use cases.

profile is a specific concept of the bluetooth protocol. In order to achieve interconnection and interworking of different devices under different platforms, the Bluetooth protocol not only specifies a core specification (called Bluetooth core), but also defines various application layer (application) specifications for various application scenarios, which are called Bluetooth profile. In order to achieve interconnection and interworking of different devices under different platforms, bluetooth protocols are various possible and generally meaningful application scenarios, and application layer profiles (profiles) are established, such as bluetooth stereo audio transmission profile (A2 DP), audio/video remote control profile (AVRCP), basic Image Profile (BIP), hands-free profile (HFP), human-computer interface profile (HID), bluetooth headset profile (HSP), serial Port Profile (SPP), file Transfer Profile (FTP), personal Area Network (PAN), and the like.

However, the existing bluetooth protocol defines different protocol frameworks for different profiles, which are independent of each other and incompatible.

Disclosure of Invention

The application provides a wireless audio system, an audio communication method and equipment, which can solve the problem of poor compatibility based on the existing Bluetooth protocol.

In a first aspect, the present application provides an audio communication method, applied to an audio source side, where the method may include: an ACL link is established between an audio source (e.g., cell phone, media player) and an audio recipient (e.g., headset). For a particular first audio service, the audio source may negotiate parameters with the audio recipient over an ACL link. Based on the first parameter determined by the negotiation, an isochronous data transmission channel may be established between the audio source and the audio recipient. The time data transmission channel may be used to transmit streaming data (i.e., audio data) of the first audio service. Wherein a bluetooth low energy connection is established between the audio source and the audio recipient.

In a second aspect, the present application provides an audio communication method, applied to an audio receiving side, where the method may include: the audio receiver and the audio source establish a bluetooth low energy connectionless asynchronous LE ACL link. And the audio receiver executes parameter negotiation for the first audio service through the LE ACL link and the audio source, and the first parameter negotiated by the parameter negotiation corresponds to the first audio service. The audio recipient may create an LE isochronous data transmission channel corresponding to the first audio service based on the first parameter and the audio source. The LE isochronous data transmission channel corresponding to the first audio service is used for an audio receiver to receive audio data of the first audio service sent by an audio source. Wherein a bluetooth low energy connection is established between the audio source and the audio recipient.

In this application, an audio service may refer to a service (service) or an application (application) capable of providing an audio function (such as audio playing, audio recording, etc.). The audio service may relate to audio-related data transmission services, such as the transmission of audio data itself, content control messages for controlling the playing of audio data, flow control messages for creating isochronous data transmission channels, etc.

By implementing the methods provided by the first aspect and the second aspect, parameter negotiation and isochronous data transmission channel establishment can be performed with audio services as granularity, a flow control message and a content control message of each audio service are transmitted through an LE ACL link, and stream data is transmitted through an LE ISO link, so that transmission frames of each service are unified. Rather than adapting different transport frames for different profile applications at the granularity of profile. Therefore, the audio communication method provided by the application can be suitable for more audio services, and the compatibility is better.

In combination with the first or second aspect, in some embodiments, the ACL link may be used to carry flow control messages, such as flow control messages involved in parameter negotiation, parameter configuration, isochronous transport channel establishment. The ACL link may also be used to carry content control messages such as call control (e.g., listen, hang up, etc.) messages, play control (e.g., previous, next, etc.) messages, volume control (e.g., increase volume, decrease volume) messages, and the like.

In combination with the first or second aspect, in some embodiments, the audio source may generate a content control message for the first audio service and may send the content control message for the first audio service to the audio recipient over the LE ACL link.

Correspondingly, the audio receiver may receive a content control message of a first audio service sent by an audio source through the LE ACL link, and may perform content control on the first audio service according to the content control message, where the content control includes one or more of the following: volume control, play control, and call control.

The content control message is used for an audio receiver to perform content control on the first audio service, and the content control comprises one or more of the following items: volume control, play control, and call control.

Alternatively, the audio source may receive user input (e.g., the user presses a phone hang-up button on the audio source) and then generate the content control message for the first audio service based on the user input.

In combination with the first or second aspect, in some embodiments, the audio recipient may generate a content control message for the first audio service and may send the content control message for the first audio service to the audio source over the LE ACL link.

Correspondingly, the audio source may receive a content control message of the first audio service sent by the audio receiver through the LE ACL link, and may perform content control on the first audio service according to the content control message, where the content control includes one or more of the following: volume control, play control, and call control.

Alternatively, the audio recipient may receive user input (e.g., a user pressing a hang-up button on the audio recipient) and then generate a content control message for the first audio service based on the user input.

With reference to the first aspect or the second aspect, in some embodiments, an audio source may generate audio data of a first audio service, and may send the audio data of the first audio service to an audio recipient through an LE isochronous data transmission channel corresponding to the first audio service.

Correspondingly, the audio receiver may receive the audio data of the first audio service sent by the audio source through the LE isochronous data transmission channel corresponding to the first audio service. Alternatively, the audio receiving side may convert the audio data of the first audio service into sound. Optionally, the audio receiver may store audio data of the first audio service.

In combination with the first or second aspect, in some embodiments, the first parameter may include one or more of: qoS parameters, codec parameters, ISO parameters, etc.

The QoS parameter may include a delay, a packet loss rate, a throughput, and other parameters indicating transmission quality. The Codec parameters may include encoding modes, compression rates, and other parameters that affect audio quality. The ISO parameters may include an ID of the CIS, the number of CIS, a maximum data size of master-to-slave transmission, a maximum data size of slave-to-master transmission, a maximum time interval for master-to-slave packet transmission at the link layer, a maximum time interval for slave-to-master packet transmission at the link layer, and the like.

With reference to the first aspect or the second aspect, in some embodiments, the first parameter may be obtained by querying a database according to the first audio service, where the database may store parameters corresponding to each of the plurality of audio services.

Optionally, in the database, the parameter corresponding to the audio service may be designed by comprehensively considering various audio switching situations or mixing situations related to the audio service. The parameter may be applicable to the situations to which the service relates. For example, in a game service, a situation may occur in which a game background sound and a mike speaking sound are switched or superimposed (when a mike is turned on for speaking during a game). The codec parameter and QoS parameter of the game background sound and the mike speaking sound may be different. Parameters suitable for this situation can be designed for the game service, so that when the user turns on the microphone to speak during the game, the hearing experience is not affected.

In combination with the first or second aspect, in some embodiments, the content control message may comprise one or more of: volume control (e.g., volume up, volume down, etc.) messages, play control (e.g., previous, next, etc.) messages, talk control (listen, hang up) messages.

With reference to the first aspect or the second aspect, in some embodiments, when an audio service scenario is switched, taking switching from a music service to a telephone service (listening to a call while listening to music) as an example, parameter negotiation may be performed again between an audio source and an audio receiver, new parameters corresponding to a new audio service (e.g., a telephone service) may be determined through negotiation, and then a new isochronous data transmission channel is created based on the new parameters. The new isochronous data transmission channel may be used to transmit streaming data for the new audio service, such as a telephony service. The isochronous data transmission channel of various services is based on LE. Therefore, the switching of the service scene does not involve the switching of the transmission frame, the efficiency is higher, and obvious pause can not occur.

Optionally, when the audio service scenario is switched, the isochronous data transmission channel corresponding to the old audio service (e.g., music service) may also be reconfigured by using the new parameters corresponding to the new audio service (e.g., telephone service), without creating a new isochronous data transmission channel based on the new parameters. In this way, the efficiency can be further improved.

With reference to the first aspect or the second aspect, in some embodiments, the creation time of the isochronous data transfer channel may include the following options:

in one option, an isochronous data transmission channel may be created at the time of arrival of the audio traffic. For example, when a user opens a game application program (game background sound starts playing at the same time), the application layer of the mobile phone sends a game background sound service creation notification to the Host, and the mobile phone initiates a creation process of an isochronous data transmission channel to the bluetooth headset according to the notification.

In another alternative, a default isochronous data transfer channel may be established first, and the default isochronous data transfer channel may be created based on default CIG parameters. Therefore, when the audio service comes, the default isochronous data transmission channel can be directly used for carrying the streaming data, and the response speed is higher.

In another alternative, a plurality of virtual isochronous data transmission channels may be established first, and the plurality of virtual isochronous data transmission channels may correspond to a plurality of sets of different CIG parameters, and may be adapted to a plurality of audio services. The virtual isochronous data transmission channel refers to an isochronous data transmission channel in which an air interface does not generate data interaction. In this way, when the audio service arrives, the virtual isochronous data transmission channel corresponding to the audio service can be selected, and the first audio device and the second audio device trigger handshake and start communication.

In a third aspect, an audio device is provided, which comprises a plurality of functional units for performing the method provided in any one of the possible implementation manners of the first aspect.

In a fourth aspect, an audio device is provided, comprising a plurality of functional units for performing the method provided in any of the possible embodiments of the second aspect.

In a fifth aspect, an audio device is provided for performing the audio communication method described in the first aspect. The network device may include: a memory and a processor, a transmitter, and a receiver coupled with the memory, wherein: the transmitter is configured to transmit a signal to another wireless communication device, the receiver is configured to receive a signal transmitted by another wireless communication device, the memory is configured to store implementation codes of the audio communication method described in the first aspect, and the processor is configured to execute the program codes stored in the memory, that is, to execute the audio communication method described in any one of the possible implementation manners of the first aspect.

In a sixth aspect, an audio device is provided for performing the audio communication method described in the second aspect. The terminal may include: a memory and a processor, a transmitter, and a receiver coupled with the memory, wherein: the transmitter is configured to transmit a signal to another wireless communication device, the receiver is configured to receive a signal transmitted by another wireless communication device, the memory is configured to store implementation codes of the audio communication method described in the second aspect, and the processor is configured to execute the program codes stored in the memory, that is, to execute the audio communication method described in any one of the possible embodiments of the second aspect.

In a seventh aspect, a chipset is provided, which may include: a first chip and a second chip. The first chip and the second chip communicate through an interface HCI. Wherein, the first chip may include the following modules: a multimedia audio module, a voice module, a background sound module, a content control module, a stream data module, and an L2CAP module. The second chip may include: LE physical layer module, LE link layer module.

In the second chip: LE physical layer module, which may be used to provide a physical channel (often referred to as a channel) for data transmission. Typically, several different types of channels exist in a communication system, such as control channels, data channels, voice channels, and so on. And the LE link layer module can be used for providing a physical independent logical transmission channel (also called a logical link) between two or more devices on the basis of a physical layer. The LE link layer module may be used to control the radio frequency state of the device, which will be in one of five states: wait, advertise, scan, initialize, connect. The broadcasting equipment can send data without establishing connection, and the scanning equipment receives the data sent by the broadcasting equipment; the device initiating the connection responds to the broadcasting device by sending a connection request, and if the broadcasting device accepts the connection request, the broadcasting device and the device initiating the connection enter a connected state. The device that initiates the connection is called the master (master) and the device that accepts the connection request is called the slave (slave). The LE link layer module may include an LE ACL module and an LE Isochronous (ISO) module. The LE ACL module may be used to transmit control messages between devices, such as flow control messages, content control messages, volume control messages, over the LE ACL link. The LE ISO module may be used to transmit isochronous data (such as streaming data itself) between devices over an isochronous data transmission channel.

In the first chip: and the L2CAP module can be used for managing the logical link provided by the logical layer. Based on L2CAP, different upper layer applications can share the same logical link. Like the concept of port (port) in TCP/IP.

The multimedia audio module, the voice module and the background sound module can be modules arranged according to service scenes, and can be used for dividing the audio application of the application layer into several audio services such as multimedia audio, voice, background sound and the like. Not limited to multimedia audio, voice, background sound, etc., audio services can also be classified into: voice, music, games, video, voice assistant, mail alert tone, alarm, alert tone, navigation tone, etc. The content control module may be responsible for encapsulating content control (e.g., previous, next, etc.) messages for various audio services and outputting the content control messages for the audio services to the LE ACL module 411 to transmit the encapsulated content control messages through the LE ACL module 411. The flow control module may be configured to perform parameter negotiation for a specific audio service, such as negotiation of QoS parameters, negotiation of coding (Codec) parameters, negotiation of ISO parameters, and creation of an isochronous data transmission channel for the specific audio service based on the negotiated parameters. An isochronous data transmission channel is created for the particular service that can be used to transmit audio data for the particular audio service. In this application, the specific audio service may be referred to as a first audio service, and the negotiated parameters may be referred to as first parameters. The stream data module may be operable to output audio data of the audio service to an LE Isochronous (ISO) module for transmission of the audio data over the isochronous data transmission channel. The isochronous data transfer channel may be a CIS. The CIS may be used to transfer isochronous data between devices in a connected state. The isochronous data transport channel is ultimately carried on the LE ISO.

In an eighth aspect, a chip is provided, which may include the module in the first chip and the module in the second chip described in the seventh aspect. For the description of each module, reference may be made to the seventh aspect, which is not described herein again.

In a ninth aspect, there is provided a communication system comprising: a first audio device and a second audio device, wherein: the first audio device may be an audio device as described in the third or fifth aspect. The second audio device may be the audio device described in the fourth or sixth aspect.

In a tenth aspect, there is provided a communication system comprising: a first audio device, a second audio device, and a third audio device, wherein: the first audio device may be an audio device as described in the third or fifth aspect. The second audio device and the third audio device may each be the audio device described in the fourth aspect or the sixth aspect.

In an eleventh aspect, there is provided a computer-readable storage medium having stored thereon instructions, which, when run on a computer, cause the computer to perform the audio communication method described in the first aspect above.

In a twelfth aspect, another computer-readable storage medium is provided, which has instructions stored thereon, and when the instructions are executed on a computer, the instructions cause the computer to execute the audio communication method described in the second aspect.

In a thirteenth aspect, there is provided a computer program product containing instructions which, when run on a computer, cause the computer to perform the audio communication method described in the first aspect above.

In a fourteenth aspect, there is provided another computer program product containing instructions which, when run on a computer, cause the computer to perform the audio communication method described in the second aspect above.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments or the background art of the present application, the drawings required to be used in the embodiments or the background art of the present application will be described below.

Fig. 1 is a schematic diagram of an architecture of a wireless audio system provided in the present application;

FIG. 2A is a schematic diagram of a protocol framework of conventional BR/EDR Bluetooth;

2B-2D are protocol stack diagrams of several existing audio profiles;

figure 3 is a schematic diagram of a BLE-based audio protocol framework provided herein;

FIG. 4 is a schematic diagram of several data types of an audio service provided by the present application;

figure 5 is a schematic diagram of an expanded BLE transmission framework;

FIG. 6 is a schematic flowchart of an audio communication method provided herein;

FIG. 7 is a schematic flow diagram of creating an isochronous data transfer channel as provided herein;

FIG. 8 is a schematic flow chart of an audio communication method in a scenario where left and right earphones according to the present application are used together;

figure 9 is a flow diagram of a BLE connection creation process provided herein;

FIG. 10A is a diagram illustrating a hardware architecture of an electronic device according to an embodiment of the present application;

FIG. 10B is a diagram illustrating a software architecture implemented on the electronic device shown in FIG. 10A;

FIG. 11 is a hardware architecture diagram of an audio output device provided by an embodiment of the present application;

FIG. 12 is a block diagram illustrating an architecture of a chipset according to the present disclosure;

fig. 13 is a schematic diagram of a chip architecture according to the present application.

Detailed Description

The terminology used in the description of the embodiments section of the present application is for the purpose of describing particular embodiments of the present application only and is not intended to be limiting of the present application.

Fig. 1 illustrates a wireless audio system 100 provided herein. As shown in fig. 1, the wireless audio system 100 may include a first audio device 101, a second audio device 102, and a third audio device 103. The first audio device 101 may be implemented as any one of the following electronic devices: a cellular phone, a portable game machine, a portable media playback device, a personal computer, a vehicle-mounted media playback device, and the like. The second audio device 102 and the third audio device 103 may be configured as any type of electro-acoustic transducer(s) for converting audio data into sound, such as speakers, in-ear headphones, headsets, etc. The physical forms and sizes of the first audio device 101, the second audio device 102 and the third audio device 103 may also be different from those shown in fig. 1, and the present application does not limit the physical forms and sizes.

The first audio device 101, the second audio device 102 and the third audio device 103 may each be configured with a wireless transceiver that may be used to transmit and receive wireless signals.

There is no cable connection between the second audio device 102 and the third audio device 103. The two may communicate via a wireless communication connection 106 rather than a wired communication connection.

The first audio device 101 may establish a wireless communication connection 104 with the second audio device 102.

In the transmission direction of the first audio device 101 to the second audio device 102, the first audio device 101 may send audio data to the second audio device 102 over the wireless communication connection 104. At this time, the role of the first audio device 101 is an audio source (audio source), and the role of the second audio device 102 is an audio sink (audio sink). Such that the second audio device 102 can convert the received audio data into sound so that the user wearing the second audio device 102 can hear the sound.

In the transmission direction of the second audio apparatus 102 to the first audio apparatus 101, in the case where the second audio apparatus 102 is provided with a sound collecting device such as a receiver/microphone, the second audio apparatus 102 can convert the collected sound into audio data and transmit the audio data to the first audio apparatus 101 through the wireless communication connection 104. At this time, the role of the second audio device 102 is an audio source (audio source), and the role of the first audio device 101 is an audio sink (audio sink). In this way, the first audio device 101 can process the received audio data, such as sending the audio data to other electronic devices (in a voice call scenario), and storing the audio data (in a recording scenario).

In addition to audio data, the first audio device 101 and the second audio device 102 can also interact with each other based on the wireless communication connection 104 to play control (e.g., previous, next, etc.) messages, talk control (e.g., listen, hang up) messages, volume control messages (e.g., volume up, volume down), and so on. Specifically, the first audio device 101 may send a play control message and a call control message to the second audio device 102 through the wireless communication connection 104, so that play control and call control may be performed on the first audio device 101 side. Specifically, the second audio device 102 may send a play control message and a call control message to the first audio device 101 through the wireless communication connection 104, so that play control and call control may be performed on the second audio device 102 side.

Likewise, a wireless communication connection 105 may be established between the first audio device 101 and the third audio device 103, and audio data, play control messages, talk control messages, and the like may be interacted through the wireless communication connection 105.

The first audio device 101 may transmit audio data to the second audio device 102 and the third audio device 103 simultaneously. In order to ensure the integrity of the listening experience, the audio data and control messages transmitted by the first audio device 101 to the second audio device 102 and the third audio device 103 need to be synchronously transmitted point-to-multipoint. Whether the second audio device 102 and the third audio device 103 are synchronized or not has a crucial impact on the integrity of the user's listening experience. When the second audio device 102 and the third audio device 103 are implemented as a left earphone and a right earphone, respectively, if the signals of the left and right ears lose synchronization of about 30 microseconds, it is disconcerting and the user feels a disorder of sound.

The wireless audio system 100 shown in fig. 1 may be a wireless audio system implemented based on the bluetooth protocol. That is, the wireless communication connections (wireless communication connection 104, wireless communication connection 105, wireless communication connection 106) between the devices may adopt bluetooth communication connection. To support audio applications, the existing BR bluetooth protocol provides some profiles, such as A2DP, AVRCP, HFP.

However, there are some problems with the existing bluetooth protocol. The following description is made.

The existing Bluetooth protocol defines different protocol frames for different profiles, which are independent from each other and incompatible.

Fig. 2A illustrates an existing BR/EDR bluetooth protocol framework. As shown in fig. 2A, the existing BR/EDR bluetooth protocol framework may include a plurality of profiles. For simplicity of illustration, only profile for some audio applications is shown in fig. 2A: a2DP, AVRCP, HFP. Without being limited thereto, the existing BR/EDR bluetooth protocol framework may also include other profiles such as SPP, FTP, etc.

The A2DP provides a protocol stack and a using method for transmitting high-quality audio by using a Bluetooth asynchronous transmission channel mode. For example, stereo bluetooth headsets may be used to listen to music from a music player. AVRCP refers to a remote control function, and generally supports remote control operations such as pause (pause), stop (stop), replay (replay), volume control, and the like. For example, a bluetooth headset may be used to perform operations such as pausing, switching to a next song, etc., to control a music player to play music. FHP provides hands-free calling functionality for voice applications.

Fig. 2B-2C show protocol stacks of A2DP, HFP, respectively. Wherein:

protocols and entities included in A2DP protocol stack

An audio source (audio source) is a source of a digital audio stream that is transmitted to an audio sink (audio sink) in a piconet (piconet). An audio sink (audio sink) is a recipient that receives a digital audio stream from an audio source (audio source) in the same piconet. In a music playing scenario, a typical device used as an audio source may be a media playing device, such as MP3, and a typical device used as an audio sink may be headphones. In a recording scenario, the device typically used as an audio source may be a sound collection device, such as a microphone, and the device typically used as an audio sink may be a portable recorder.

A Baseband (Baseband), a Link Management Protocol (LMP), a logical link control and adaptation protocol (L2 CAP), and a Service Discovery Protocol (SDP) are bluetooth protocols defined in a bluetooth core specification. The Audio Video Data Transfer Protocol (AVDTP) comprises a signaling entity for negotiating stream parameters (streaming parameters) and a transport entity for controlling the stream itself. The Application (Application) layer is the entity in which the Application services and transport service parameters are defined, which is also used to adapt the audio stream data into a defined packet format or to adapt the defined packet format into audio stream data.

Protocol and entity included in AVRCP protocol stack

A controller is a device that initiates a transaction by sending a command frame to a target device. Typical controlling parties may be personal computers, cell phones, remote controls, etc. A target is a device that receives a command frame and generates a response frame accordingly. Typical target parties may be audio playing/recording devices, video playing/recording devices, televisions, etc.

Baseband (Baseband), link Management Protocol (LMP) and logical link control and adaptation protocol (L2 CAP) are the layer 1 and layer 2 bluetooth protocols of the OSI model. The Audio Video Control Transport Protocol (AVCTP) and the Basic Imaging Profile (BIP) define procedures and messages that are used in exchange for a/V device control. SDP is a bluetooth service discovery protocol (service discovery protocol). The object exchange (OBEX) protocol is used to transfer data objects between bluetooth devices, and is derived from an infrared defined protocol and then used by bluetooth. Audio video/control (AV/C) is the entity responsible for device control signaling based on AV/C commands. The Application layer is an ACRVP entity for exchanging control and browse commands defined in the protocol.

Protocol and entity included in HFP protocol stack

An audio gateway (audio gateway) is a device that serves as a gateway for inputting and outputting audio. A typical device that functions as an audio gateway may be a cellular telephone. Hands-Free units (Hands-Free units) are devices that act as remote audio input, output mechanisms for audio gateways. The hands-free unit may provide some remote control method. A typical device used as a hands-free unit may be a vehicle hands-free unit.

Baseband (Baseband), link Management Protocol (LMP) and logical link control and adaptation protocol (L2 CAP) are the layer 1 and layer 2 bluetooth protocols of the OSI model. The RFCOMM is a Bluetooth serial port simulation (emulation) entity. SDP is the bluetooth service discovery protocol. Hands-Free control (Hands-Free control) is the entity responsible for the specific control signals of the Hands-Free unit. The control signal is based on AT commands. The audio port emulation (audio port emulation) layer is an entity that emulates an audio port on an audio gateway (audio gateway), and the audio driver (audio driver) is driver software in the hands-free unit.

It can be seen from the above a-C that A2DP, AVRCP, HFP correspond to different protocol stacks, and different profiles adopt different transmission links and are incompatible with each other. That is, profile is actually a different protocol stack of the bluetooth protocol corresponding to different application scenarios. When the bluetooth protocol needs to support a new application scenario, profile and a protocol stack need to be added following an existing bluetooth protocol framework.

Moreover, different profiles adopt different protocol stacks, and the protocol stacks are independent from each other, so that switching between applications of different profiles is time-consuming and serious, and obvious pause can occur.

For example, a user of Dai Zhaolan a dental headset turns on the microphone and the teammate yell while playing a game (the game will generate a game background sound, such as a game skill triggered sound). In this scenario, the audio transmission may need to switch from A2DP to HFP. Wherein, the background sound transmission at the time of game can be realized by A2 DP-based protocol stack, and the voice transmission of the teammate's shouting can be realized by an HFP-based protocol stack. The game background sound requires higher sound quality than the voice, i.e. the two adopt different encoding parameters (such as compression rate), and the game background sound adopts higher compression rate than the voice. Since A2DP and HFP are independent of each other, switching from A2DP to HFP requires stopping the configuration related to the audio transmission of the game background under A2DP, and performing parameter negotiation, configuration initialization, and the like of audio data transmission under HFP again, which takes a long time, resulting in a pause that can be perceived by the user as being noticeable.

In addition, the existing BR/EDR bluetooth protocol does not implement point-to-multipoint synchronous transmission.

The existing BR/EDR bluetooth protocol defines two bluetooth physical links: an Asynchronous Connection (ACL) link without a connection, a Synchronous Connection Oriented (SCO) or an extended SCO (eSCO) link. Where ACL links support both symmetric (point-to-point) and asymmetric (point-to-multipoint) connections. The ACL link has high transmission efficiency, but the time delay is uncontrollable, the retransmission times are not limited, and the ACL link can be mainly used for transmitting data which is not sensitive to the time delay, such as control signaling, grouped data and the like. SCO/eSCO links support symmetric connections (point-to-point). The SCO/eSCO link has low transmission efficiency, controllable time delay and limited retransmission times, and can mainly transmit delay-sensitive services (such as voice).

The two links of ACL, SCO/eSCO in the existing BR/EDR Bluetooth protocol do not realize the support of isochronous data (isochronous data). That is, in the point-to-multipoint piconet, the data sent by the master device master to the slave devices slave does not implement synchronous transmission, and the signals of the slave devices slave are not synchronous.

In view of the problems of the existing bluetooth protocol, the application provides an audio protocol framework based on low-power-consumption bluetooth BLE.

Existing BLE protocols support point-to-multipoint network topologies. Also, the bluetooth interest group (SIG) has proposed adding support for isochronous data (isochronous data) to BLE to allow BLE devices to transmit isochronous data. isochronous data is time-bounded. isochronous data refers to information in a stream, where each information entity (information entry) is limited by the temporal relationship between it and the preceding and succeeding entities.

However, the existing BLE protocol does not define audio transmission, and BLE profile does not include audio profile (e.g., A2DP, HFP). That is, bluetooth low energy based audio-over-ble (voice-over-ble) is not standardized. The BLE-based audio protocol framework provided herein will support audio transmission.

Figure 3 illustrates a BLE-based audio protocol framework provided herein. As shown in fig. 3, the protocol framework may include: an LE physical layer (LE physical layer) 313, an LE link layer (LE link layer) 310, an L2CAP layer, and an application layer 308.LE physical layer 313 and LE link layer 310 may be implemented in a controller and L2CAP layer 308 may be implemented in a Host. The protocol framework may also include some functional entities implemented in Host: multimedia audio function 302, voice function 303, background sound function 304, content control function 305, stream control function 306, stream data function 307.

In the Controller:

(1) LE physical layer 313 may be responsible for providing the physical channels (commonly referred to as channels) for data transmission. Typically, several different types of channels exist in a communication system, such as control channels, data channels, voice channels, and so on. Bluetooth uses the 2.4GHz Industrial Scientific Medical (ISM) band.

(2) The LE link layer 310 provides a physical independent logical transmission channel (also referred to as a logical link) between two or more devices on a physical layer basis. The LE link layer 310 may be used to control the radio frequency state of the device, which will be in one of five states: wait, advertise, scan, initialize, connect. The broadcasting equipment can send data without establishing connection, and the scanning equipment receives the data sent by the broadcasting equipment; the connection initiating device responds to the broadcaster by sending a connection request, and if the broadcaster accepts the connection request, the broadcaster and the connection initiating device enter a connected state. The device that initiates the connection is called the master (master) and the device that accepts the connection request is called the slave (slave).

LE link layer 310 may include LE ACL link 311 and LE Isochronous (ISO) link 312.LE ACL link 311 may be used to transport inter-device control messages such as flow control messages, content control messages, volume control messages. The LE ISO link 312 may be used to transmit isochronous data (such as streaming data itself) between devices.

In Host:

(1) The L2CAP layer 308 may be responsible for managing the logical links provided by the logical layer. Based on L2CAP, different upper layer applications may share the same logical link. Like the concept of port (port) in TCP/IP.

(2) Multimedia audio function 302, voice function 303, background sound function 304 may

The method is a functional entity set according to a service scene, and can be used for dividing audio applications of an application layer into several audio services such as multimedia audio, voice, background sound and the like. Not limited to multimedia audio, voice, background sound, etc., audio services can also be classified into: voice, music, games, video, voice assistant, mail alert tone, alarm, alert tone, navigation tone, etc.

(3) The content control function entity 305 may be responsible for encapsulating the content of various audio services

Control (e.g., previous, next, etc.) messages and transport the encapsulated content control messages over LE ACL link 311.

(4) The stream control function 306 may be responsible for parameter negotiation, such as negotiation of quality of service (QoS) parameters, negotiation of coding (Codec) parameters, negotiation of isochronous data transmission channel parameters (hereinafter, referred to as ISO parameters), and establishment of isochronous data transmission channels.

(5) The streaming data function 307 may be responsible for transmitting audio data over an isochronous data transmission channel. The isochronous data path may be based on a concatenated isochronous audio stream (CIS). The CIS may be used to transfer isochronous data between devices in a connected state. The isochronous data transfer channel is ultimately carried in LE ISO312. The flow control function 306 may also be configured to perform parameter negotiation before creating the isochronous data transmission channel, and then create the isochronous data transmission channel based on the negotiated parameters.

As shown in figure 3, in the BLE-based audio protocol framework provided herein, audio data from the application layer is finally transmitted over the LE ISO link 312.

In addition, the audio protocol framework shown in fig. 3 may further include a Host Controller Interface (HCI). Host and Controller communicate through HCI, and the communication medium is HCI command. The Host may be implemented in an Application Processor (AP) of the device, and the Controller may be implemented in a bluetooth chip of the device. Optionally, in a small device, the Host and the Controller may be implemented in the same processor or Controller, and in this case, the HCI is optional.

As shown in fig. 4, the BLE-based audio protocol framework provided by the present application can classify data of various audio applications (such as A2DP, HFP, etc.) into three types:

content control: signaling for call control (such as answering, hanging up, etc.), play control (such as previous, next, etc.), volume control (such as increasing volume, decreasing volume), etc.

Flow control: create stream (create stream), terminate stream (terminate stream), etc. for signaling of stream management. The stream may be used to carry audio data.

Streaming data: the audio data itself.

Wherein, the data of content control and flow control is transmitted through LE ACL311 link; streaming data is transmitted over the LE ISO312 link.

In the existing bluetooth protocol, different profiles correspond to different protocol stacks and different transmission frames. For example, A2DP and HFP correspond to different transmission frames, streaming data (such as stereo music data) of the A2DP is finally transmitted through the ACL link because the transmission efficiency of the ACL link is high, and streaming data (such as voice data) of the HFP is finally transmitted through the SCO/eSCO link because the transmission delay of the SCO/eSCO link is controllable. Different from the existing Bluetooth protocol, the audio protocol framework based on BLE provided by the application provides a unified audio transmission framework, data of any audio profile can be divided into three types of content control, flow control and streaming data, the two types of data of content control and flow control are transmitted on an LE ACL link based on the BLE framework, and the streaming data is transmitted on an LE ISO link.

It can be seen that the BLE-based audio protocol framework provided by the application supports audio transmission, can unify service level connection, and divides all upper layer audio profiles into audio services such as multimedia audio, voice, background sound and the like in a service scene. The flow control of each audio service (including the negotiation of QoS parameters, the negotiation of codec parameters, the negotiation of ISO parameters, and the establishment of isochronous data transmission channels) is uniformly handled by a flow control function (stream control) entity in the protocol stack. The content control (such as call control for answering and hanging up, play control for the previous and next audio services, volume control, etc.) of each audio service is uniformly responsible for a content control (content control) function entity in a protocol stack. Both flow control messages and content control messages are transmitted over the LE ACL link and streaming data is transmitted over the LE ISO link. Therefore, different audio profiles can be based on the same transmission frame, and the compatibility is better.

The audio protocol framework provided by the application is based on BLE, namely based on extended BLE transport framework (transport architecture). Compared with the existing BLE transmission framework, the expanded BLE transmission framework mainly comprises the following components: isochronous channel (isochronous channel) characteristics.

Fig. 5 shows an extended BLE transport framework entities (transport architecture entities). Wherein the entities marked by the shadow are newly added logical sublayers, and the newly added logical sublayers jointly provide isochronous channel characteristics. As shown in fig. 5:

(1) LE physical transport (LE physical transport) layer: air interface data transmission is marked by a data packet structure, coding, modulation scheme and the like. The LE physical transport carries all information from the upper layers.

(2) LE physical channel (LE physical channel) layer: the empty physical channel transmitted between the Bluetooth devices bears the channel through the physical layer marked by time domain, frequency domain and space domain, and comprises the concepts of frequency hopping, time slot, event and access code. For an upper layer, one LE physical channel may carry different LE logical transport (LE local transport); for the lower layer, one LE physical channel always maps its unique corresponding LE physical transport.

The LE physical channel layer may include four physical channel entities: LE piconet physical channel (LE piconet physical channel), LE broadcasting physical channel (LE broadcasting physical channel), LE periodic physical channel (LE periodic physical channel), and LE isochronous physical channel (LE isochronous physical channel). Namely, the LE isochronous physical channel is added on the basis of the existing LE physical channel.

Among them, the LE piconet physical channel can be used for communication between devices in a connected state, which employs a frequency hopping technique. The LE advertising physical channel can be used for connectionless broadcast communication between devices, and the broadcast communication can be used for discovery and connection operation of the devices and connectionless data transmission. The LE periodic physical channel may be used for periodic broadcast communication between devices. The LE isochronous physical channel can be used for transmitting isochronous data, and has a one-to-one mapping relation with the LE isochronous physical link of the upper layer.

(3) LE physical link (LE physical link) layer: the baseband connection between bluetooth devices is a virtual concept, and there is no corresponding field representation in the air interface data packet. For the upper LE local transport, one LE local transport will map to only one LE physical links. For the lower layer, one LE physical link can be carried by different LEphysical channels, but one transmission is always mapped onto one LEphysical channel.

The LE physical link is further packaging of the LE physical channel. The LE physical link layer may include four physical link entities: the LE active physical link (LE active physical link), the LE broadcasting physical link (LE broadcasting physical link), the LE periodic physical link (LE periodic physical link), and the LE isochronous physical link (LE isochronous physical link, namely, the LE isochronous physical link is added on the basis of the existing LE physical link.

The LE isochronous physical link can be used for transmitting isochronous data, bears LE-BIS and LE-CIS of an upper layer, and has a one-to-one mapping relation with the LE physical channel.

(4) LE logical transport (LE logical transport) layer: can be responsible for flow control, ACK/NACK confirmation mechanism, retransmission mechanism and scheduling mechanism. This information is typically carried in a data packet header. For the upper layer, one logical transport may correspond to a plurality of logical links. For the lower layer, one logical transport maps to only one corresponding logical link.

The LE local transport layer may include the following logical transport entities: LE-ACL, ADVB, PADVB, LE-BIS, LE-CIS. Namely, LE-BIS and LE-CIS are added on the basis of the existing LE local transport.

Wherein, LE-CIS is a point-to-point local transport between Master and a designated Slave, and each CIS supports a local link of LE-S. The CIS may be at a symmetric rate or an asymmetric rate. LE-CIS is built on top of LE-ACL. LE-BIS is a point-to-multipoint Logical transport, each BIS supporting a local link for the LE-S. LE-BIS is built on top of PADVB. Here, BIS refers to a broadcast isochronous stream (broadcast isochronous stream), and CIS refers to a connection-based isochronous stream (connected isochronous stream).

LE ISO link 312 in FIG. 3 may be a LE CIS, and LE ACL link 311 in FIG. 3 may be a LE ACL.

(5) LE logical link (LE local link) layer: may be used to support different application data transfers. For the lower layer, each logical link may map to multiple logical transport, but only one logical transport is selected to map to at a time.

The LE local link layer may include the following logical link entities: LE-C, LE-U, ADVB-C, ADVB-U, low power broadcast control (LEB-C), low power stream (LE-S). Here, "-C" denotes a control (control) and "-U" denotes a user (user). Namely, LEB-C and LE-S are added on the basis of the existing LE local link. Wherein LEB-C is used to carry control information of BIS, LE-S is used to carry isochronous data stream.

Based on the audio protocol framework shown in fig. 3, the present application provides an audio communication method.

The main inventive idea can include: and determining parameters of the isochronous data transmission channel for each audio service by taking the audio service as granularity. Parameter negotiation, such as negotiation of QoS parameters, negotiation of codec parameters, and negotiation of ISO parameters, may be performed between a first audio device (e.g., a mobile phone or a media player) and a second audio device (e.g., a headset) with audio service as granularity, and then an isochronous data transmission channel (isochronous data path) may be created based on the negotiated parameters. An isochronous data transfer channel may be used to transfer streaming data.

In the present application, an audio service may refer to a service (service) or an application (application) capable of providing an audio function (such as audio playing, audio recording, and the like). The audio service may relate to audio-related data transmission services, such as the transmission of audio data itself, content control messages for controlling the playing of audio data, flow control messages for creating isochronous data transmission channels, etc.

Different from the prior art, the audio communication method provided by the application does not perform parameter negotiation with profile as granularity any more, but performs parameter negotiation with audio service as granularity. When a service scene is switched, the data transmission channel can be configured based on the renegotiated parameters, switching among different profile protocol stacks is not needed, the efficiency is higher, and obvious pause is avoided.

For example, switching from a music service scenario to a telephone service scenario (listening to a call while listening to music). In the existing bluetooth protocol, the switching involves switching from A2DP (music service) to HFP (telephone service). A2DP and HFP correspond to different transmission frames respectively, streaming data (such as stereo music data) of the A2DP is finally transmitted through an ACL link, and streaming data (such as voice data) of the HFP is finally transmitted through an SCO/eSCO link. Therefore, in the existing bluetooth protocol, the switching may result in switching of the underlying transport frame, which is time-consuming. However, the BLE-based audio protocol framework provided by the application provides a unified audio transmission framework, no matter which audio service scenario, streaming data can be transmitted through an LE ISO link, and the switching of the service scenarios does not involve the switching of the transmission framework, so that the efficiency is higher.

In the present application, the QoS parameter may include a parameter indicating transmission quality, such as a time delay, a packet loss rate, and throughput. The Codec parameters may include encoding modes, compression rates, and other parameters that affect audio quality. The ISO parameters may include an ID of the CIS, a number of CIS, a maximum data size of master-to-slave transmission, a maximum data size of slave-to-master transmission, a maximum time interval of master-to-slave packet transmission at a link layer, a maximum time interval of slave-to-master packet transmission at a link layer, and the like.

Fig. 6 shows an overall flow of the audio communication method provided by the present application. In figure 6, a BLE connection is established between a first audio device (e.g., a cell phone, a media player) and a second audio device (e.g., a headset). The following is developed:

1. establishing ACL links (S601)

S601, an ACL link is established between a first audio device (such as a mobile phone and a media player) and a second audio device (such as a headset).

Specifically, the ACL link may be used to carry flow control messages, such as flow control messages involved in parameter negotiation, parameter configuration, and isochronous transport channel establishment in the flow control process (S602-S604).

Specifically, the ACL link may also be used to carry content control messages, such as call control (e.g., answering, hanging up, etc.) messages, play control (e.g., previous, next, etc.) messages, volume control (e.g., volume up, volume down) messages, and the like in the content control process (S605-S607).

2. Flow control process (S602-S604)

S602, for a specific audio service, the first audio device and the second audio device may perform parameter negotiation through an ACL link.

Specifically, the parameter negotiation may be performed with the granularity of audio service. Different audio services all need to perform parameter negotiation, such as negotiation of QoS parameters, negotiation of codec parameters, and negotiation of ISO parameters. An audio service may correspond to a set of parameters, and the set of parameters may include one or more of: qoS parameters, codec parameters, ISO parameters.

Specifically, the specific process of parameter negotiation may include:

step a, the first audio equipment can send a parameter negotiation message to the second audio equipment through an ACL link, and the message can carry a set of parameters corresponding to a specific audio service. The set of parameters may be obtained by querying a database according to the specific audio service, and the database may store parameters corresponding to each of the plurality of audio services.

And b, the second audio equipment receives the parameter negotiation message sent by the first audio equipment through the ACL link. If the second audio equipment agrees to the parameters carried in the message, returning a confirmation message to the first audio equipment; and if the second audio equipment does not agree or partially agree with the parameters carried in the parameter negotiation message, returning a continuous negotiation message to the first audio equipment so as to return to continue the parameter negotiation with the first audio equipment.

Here, the specific audio service may be a phone, a game, a voice assistant, music, and the like.

S603, the first audio device may perform parameter configuration to the second audio device through the ACL link. The parameter configuration is directed to a parameter determined by the second audio device configuration negotiation.

In a specific implementation, the first audio device may send a parameter configuration message to the second audio device through the ACL link, where the parameter configuration message may carry a parameter that has been negotiated and determined by both the first audio device and the second audio device. Accordingly, after receiving the parameter configuration message through the ACL link, the second audio device can perform reception or transmission of stream data according to the parameter negotiated and determined by both parties.

And S604, establishing an isochronous data transmission channel between the first audio equipment and the second audio equipment based on the parameters determined by negotiation.

In particular, isochronous data transfer channels may be used to transfer streaming data (i.e., audio data). The following contents will be developed and described to show a specific process for establishing an isochronous data transmission channel between the first audio device and the second audio device, which is not described herein again.

In the above-described flow control process, the first audio device may be an audio source (audio source), and the second audio device may be an audio sink (audio sink). I.e. parameter negotiation, isochronous data channel creation can be initiated by the audio source. In the above-described flow control process, the first audio device may also be an audio source (audio sink) and the second audio device may be an audio sink (audio source). Namely, the audio receiver can initiate parameter negotiation and isochronous data channel creation.

3. Content control Process (S605-S607)

And S605-S607, the content control message can be interacted between the first audio equipment and the second audio equipment based on the ACL link.

S605, the first audio device and the second audio device may exchange call control messages, such as control messages of answering and hanging up, based on the ACL link.

In one mode, the first audio device can send a call control (such as answering, hanging up, etc.) message to the second audio device (such as an earphone) through the ACL link, so that the call control can be performed on the first audio device (such as a mobile phone). A typical application scenario for this approach may be: when a user makes a call using the bluetooth headset, the user clicks a hang-up button on the handset to hang up the call. In another mode, the second audio device (e.g., the headset) may send a call control (e.g., answer, hang up, etc.) message to the first audio device (e.g., the mobile phone) through the ACL link, which may enable call control on the second audio device (e.g., the headset) side. A typical application scenario for this approach may be: when a user places a call using a bluetooth headset, the user presses a hang-up button on the bluetooth headset to hang up the call. The user can also hang up the phone on the bluetooth headset through other operations, such as tapping the headset, without pressing the hang-up button.

S606, the first audio device and the second audio device may interactively play control messages, such as the previous control message, the next control message, and the like, based on the ACL link.

In one mode, a first audio device (e.g., a mobile phone) may send a play control (e.g., previous, next, etc.) message to a second audio device (e.g., a headset) via an ACL link, which may enable play control on the first audio device (e.g., the mobile phone) side. A typical application scenario for this approach may be: while listening to music using a bluetooth headset, the user clicks the last/next button on the handset to switch songs. In another mode, the second audio device (e.g., the headset) may send a play control (e.g., previous, next, etc.) message to the first audio device (e.g., the mobile phone) through the ACL link, so that play control on the second audio device (e.g., the headset) side may be implemented. A typical application scenario for this approach may be: when listening to music using a bluetooth headset, the user presses the last/next button on the bluetooth headset to switch songs.

S607, the first audio device and the second audio device may interact with the volume control message based on the ACL link, and increase the volume, decrease the volume, and so on.

In one approach, a first audio device (e.g., a cell phone) may send a volume control (e.g., increase volume, decrease volume, etc.) message to a second audio device (e.g., a headset) over an ACL link, which may enable volume control on the first audio device (e.g., cell phone) side. A typical application scenario for this approach may be: when listening to music using a bluetooth headset, the user clicks a volume adjustment button on the handset to adjust the volume. In another approach, the second audio device (e.g., headset) may send a volume control (e.g., volume up, volume down, etc.) message to the first audio device (e.g., handset) via an ACL link, which may enable volume control on the second audio device (e.g., headset) side. A typical application scenario for this approach may be: when listening to music using a bluetooth headset, the user presses a volume adjustment button on the bluetooth headset to adjust the volume.

In the above-described content control process, the first audio device may be an audio source (audio source), and the second audio device may be an audio sink (audio sink). I.e. content control can be performed on the audio source side. In the above-described content control process, the first audio device may also be an audio source (audio sink) and the second audio device may be an audio recipient (audio source). I.e. content control can be performed at the audio receiver side.

4. Streaming data Transmission Process (S608)

S608, stream data may be exchanged between the first audio device and the second audio device based on the created isochronous data transmission channel. The stream data is the stream data of the aforementioned specific audio service. The created isochronous data transmission channel corresponds to the aforementioned specific audio service.

In one approach, a first audio device (e.g., a handset) may send streaming data to a second audio device (e.g., a headset) over an isochronous data transmission channel. At this time, the role of the first audio device (e.g., a handset) is an audio source (audio source), and the role of the second audio device (e.g., a headset) is an audio sink (audio sink). Such that the second audio device (e.g., a headset) can convert the received audio data into sound. A typical application scenario for this approach may be: the user wears the Bluetooth headset to listen to music played on the mobile phone.

In another approach, a second audio device (e.g., a headset) may transmit streaming data to a first audio device (e.g., a cell phone) over an isochronous data transmission channel. The role of the second audio device (e.g. the headset) is then the audio source (audio source) and the role of the first audio device (e.g. the handset) is the audio sink (audio sink). Thus, the first audio device (e.g., a mobile phone) can process the received audio data, such as converting the audio data into sound, sending the audio data to other electronic devices (in a voice call scenario), and storing the audio data (in a recording scenario). A typical application scenario for this approach may be: when a user wears a Bluetooth headset (provided with a receiver/microphone and other sound acquisition devices) to make a call, the Bluetooth headset acquires the speaking sound of the user, converts the speaking sound into audio data and transmits the audio data to the mobile phone.

The present application does not limit the execution sequence of the content control process and the streaming data transmission process, and the streaming data transmission process may be executed before the content control process, or both of the content control process and the streaming data transmission process may be executed simultaneously.

The first audio device, the second audio device in the method shown in fig. 6 may implement the BLE-based audio protocol framework shown in fig. 3. At this time, the flow control processes (S602-S604) in fig. 6 may be performed by the flow control functional entity 306 in fig. 3; the content control process (S605-S607) in fig. 6 may be performed by the content control function entity 305 in fig. 3. The ACL link referred to in the method of fig. 6 can be LE ACL311 of fig. 3, and the isochronous data transfer channel referred to in the method of fig. 6 can be LE ISO312 of fig. 3.

When the audio service scenario is switched, taking switching from the music service to the telephone service (listening to the phone while listening to music) as an example, parameter negotiation may be performed again between the first audio device and the second audio device, a new parameter corresponding to a new audio service (e.g., a telephone service) is determined by the negotiation, and then a new isochronous data transmission channel is created based on the new parameter. The new isochronous data transmission channel may be used to transmit streaming data for the new audio service, such as a telephony service. The isochronous data transmission channel of various services is based on LE. Therefore, the switching of the service scene does not involve the switching of the transmission frame, the efficiency is higher, and obvious pause can not occur.

The audio communication method provided by the application carries out parameter negotiation and isochronous data transmission channel establishment by taking audio services as granularity, flow control messages and content control messages of all the audio services are transmitted through an LE ACL link, and flow data are transmitted through an LE ISO link, so that transmission frames of all the services are unified. Rather than adapting different transport frames for different profile applications at the granularity of profile. Therefore, the audio communication method provided by the application can be suitable for more audio services, and the compatibility is better. Moreover, when a service scene is switched, the data transmission channel is configured based on the renegotiated parameters, and the like, so that switching among different profile protocol stacks is not needed, a transmission frame is not needed to be switched, the method is more efficient, and obvious pause can be avoided.

The following describes the creation process of the isochronous data transfer channel mentioned in the method flow shown in fig. 6.

Fig. 7 shows a process of creating an isochronous data transfer channel. The isochronous data transmission channel is based on a connected isochronous data channel, i.e., the first audio device and the second audio device are already in a connected (Connection) state. The first audio device and the second audio device both have a Host and a link layer LL (in a controller), and the Host and the LL communicate with each other through the HCI. As shown in fig. 7, the process may include:

S701-S702, host a (Host of the first audio device) sets relevant parameters based on a Connected Isochronous Group (CIG) through an HCI instruction.

Wherein the CIG related parameters may include parameters (QoS parameters, codec parameters, ISO parameters) that have been previously negotiated for creating an isochronous data transmission channel.

Specifically, host a may send HCI instructions "LE Set CIG parameters" to LL a (LL of the first audio device) through HCI. Accordingly, LL a may return a response message "Command Complete".

S703-S704, host A initiates the creation of CIS through HCI instruction.

Specifically, host a may send the HCI instruction "LE CreateCIS" to LL a (LL of the first audio device) through HCI. Accordingly, LL a may return a response message "HCI Command Status".

S705, LL a may request LL B (LL of the second audio device) to create a CIS stream through the air interface request message LL _ CSI _ REQ.

And S706-S708, the LL B informs Host B (Host of the second audio device) through the HCI instruction, and the Host B agrees with the CIS link establishment flow of the first audio device.

And S709, replying that LL A agrees with a CIS link establishment flow by LL B through an air interface response message LL _ CIS _ RSP.

And S710, the LL A informs the LL B of completing the link establishment through an air interface notification message LL _ CIS _ IND.

And S711, the LL B informs the Host B, and the CIS completes the chain establishment.

And S712, the LL A informs the Host A through the HCI instruction, and the CIS completes the link establishment.

To this end, the establishment of CIS between the first audio device and the second audio device is completed. Based on the established CIS, the first audio device, the second audio device may create an isochronous data transmission channel.

It can be seen that the isochronous data transfer channel is carried by the CIS. CIS is a connection-based stream that can be used to carry isochronous data.

In the present application, the creation time of the isochronous data transfer channel (i.e., when to perform the process shown in fig. 7) may include various options. In one option, an isochronous data transmission channel may be created at the arrival of the audio traffic. For example, when the user opens the game application (the game background sound starts playing at the same time), the application layer of the mobile phone sends a game background sound service creation notification to the Host, and according to the notification, the mobile phone initiates the flow shown in fig. 7 to the bluetooth headset. In another alternative, a default isochronous data transfer channel may be established first, and the default isochronous data transfer channel may be created based on default CIG parameters. Therefore, when the audio service arrives, the default isochronous data transmission channel can be directly used for carrying the streaming data, and the response speed is higher. In another alternative, a plurality of virtual isochronous data transmission channels may be established first, and the plurality of virtual isochronous data transmission channels may correspond to a plurality of sets of different CIG parameters, and may be adapted to a plurality of audio services. The virtual isochronous data transmission channel refers to an isochronous data transmission channel in which an air interface does not generate data interaction. In this way, when the audio service arrives, the virtual isochronous data transmission channel corresponding to the audio service can be selected, and the first audio device and the second audio device trigger handshake and start communication.

The method flow shown in fig. 6 describes a method for connection-based peer-to-peer audio communication between a first audio device and a second audio device. The first audio device may be the first audio device 101 in the wireless audio system 100 shown in fig. 1 and the second audio device may be the second audio device 102 in the wireless audio system 100 shown in fig. 1. The first audio device 101 and the third audio device 103 in the wireless audio system 100 can also communicate with each other by using the audio communication method shown in fig. 6.

In one case, the first audio device 101 may communicate with both the second audio device 102 and the third audio device 103. The first audio device 101 may be implemented as a cell phone and the second audio device 102 and the third audio device 103 may be implemented as a left earphone and a right earphone, respectively. This situation corresponds to a typical application scenario: the left earphone and the right earphone are used together. Such a typical application scenario may be referred to as a "binaural use together" scenario.

Fig. 8 illustrates an audio communication method in a "binaural use together" scenario. The following is developed:

1. establishing BLE connection (S801-S803)

And S801, the BLE connection is established between the left earphone and the right earphone.

And S802, the BLE connection is established between the left earphone and the mobile phone.

And S803, the right earphone and the mobile phone establish BLE connection.

The present application does not limit the execution sequence of the above-mentioned S801 to S803, and the sequence between them may be changed. The BLE connection establishment procedure is expanded in the following, and will not be described herein again.

2. Establishing ACL links (S804)

And S804, respectively establishing an ACL link between the mobile phone and the left earphone and the right earphone.

Specifically, the establishment of the ACL link is handled by the link layer LL. An ACL link can be established between the LL of the mobile phone and the LL of the left earphone, and the ACL link can be established between the LL of the mobile phone and the LL of the right earphone.

Specifically, the ACL link may be used to carry flow control messages, such as flow control messages involved in parameter negotiation, parameter configuration, and isochronous transport channel establishment in the flow control process (S805-S813). The ACL link may also be used to carry content control messages, such as call control (e.g., listen, hang up, etc.) messages, play control (e.g., previous, next, etc.) messages, volume control (e.g., volume up, volume down) messages, etc., in the content control process (S814-S819).

3. Flow control process (S805-S813)

S805-S806, when the audio service arrives, the mobile phone may determine a parameter (QoS parameter, codec parameter, ISO parameter, etc.) corresponding to the audio service.

Specifically, the Host of the mobile phone receives an audio service establishment notification from the application layer, and then determines a parameter corresponding to the audio service. The audio service establishment notification may be generated by the handset upon detecting that the user opened an audio-related application (e.g., a game).

Specifically, the parameter corresponding to the audio service may be obtained by querying the mobile phone from a database according to the service type of the audio service, and the database may store parameters corresponding to multiple audio services.

And S807, the Host of the mobile phone sends the parameters corresponding to the audio service to the LL of the mobile phone through the HCI.

S808, for the audio service, the LL of the handset and the LL of the left earphone may perform parameter negotiation through the established ACL link. The specific process of parameter negotiation may refer to the related content in the embodiment of the method in fig. 6, and is not described herein again.

And S809, after the parameter negotiation is completed, the mobile phone can configure the parameters to the left earphone through the established ACL link. The parameter configuration refers to configuring the negotiated parameters for the left earphone.

In a specific implementation, the LL of the mobile phone may send a parameter configuration message to the LL of the left earphone through the ACL link, where the parameter configuration message may carry a parameter that has been negotiated and determined by both parties. Correspondingly, after receiving the parameter configuration message through the ACL link, the left earphone can perform receiving or sending of the streaming data according to the parameter negotiated and determined by the two parties.

Based on the parameters determined by the negotiation, an isochronous data transmission channel may be established between the handset and the left earpiece S810. The process of creating the isochronous data transfer channel may refer to the related contents in the embodiment of the method shown in fig. 6, and will not be described herein again.

S811, for the audio service, the LL of the handset and the LL of the right earphone may perform parameter negotiation through the established ACL link. The specific process of parameter negotiation may refer to the related content in the embodiment of the method in fig. 6, and is not described herein again.

And S812, after the parameter negotiation is completed, the mobile phone can perform parameter configuration to the right earphone through the established ACL link. The parameter configuration refers to configuring the negotiated parameters for the left earphone.

In a specific implementation, the LL of the mobile phone may send a parameter configuration message to the LL of the right earphone through the ACL link, where the parameter configuration message may carry parameters that have been negotiated and determined by both parties. Correspondingly, after receiving the parameter configuration message through the ACL link, the right earphone can execute the receiving or sending of the streaming data according to the parameters which are determined by the negotiation of the two earphones.

Based on the parameters determined by negotiation, an isochronous data transmission channel can be established between the handset and the right earphone S813. The process of creating isochronous data transmission channel refers to the related contents in the embodiment of the method shown in fig. 6, and is not repeated herein.

It can be seen that in order to maintain the integrity of the binaural parameters (QoS parameters, codec parameters, ISO parameters, etc.), the parameter determination can be determined in units of binaural, and then negotiated and configured one by one.

S808-S810 describe the process of the handset performing parameter negotiation, configuration and isochronous data transmission channel creation on the left earphone, and S811-S813 describe the process of the handset performing parameter negotiation, configuration and isochronous data transmission channel creation on the right earphone. The present application does not limit the execution sequence of the two processes, and the two processes may be performed simultaneously.

Content control Process (S814-S819)

S814-S816, content control messages can be interacted between the mobile phone and the left earphone based on the ACL link. The specific implementation may refer to related contents in the method embodiment of fig. 6, and details are not repeated here.

And S817-S819, the content control message can be interacted between the mobile phone and the right earphone based on the ACL link. The specific implementation may refer to related contents in the method embodiment of fig. 6, and details are not repeated here.

When the mobile phone transmits the content control message to the left earphone and the right earphone, the content control message transmission from the mobile phone to the left earphone and the right earphone needs to be synchronized, so that the left earphone and the right earphone are synchronously controlled, and the user is prevented from feeling auditory disorder. To achieve this, the left and right earphones may regenerate the content control after receiving the content control message in synchronization.

5. Stream data transmission process (S820-S821)

And S820, the mobile phone and the left earphone can interact streaming data based on the created isochronous data transmission channel. The stream data is stream data of the aforementioned audio service.

S821, the handset and the right earphone may exchange streaming data based on the created isochronous data transmission channel. The stream data is stream data of the aforementioned audio service.

It can be seen that the audio communication method shown in fig. 8 can be applied to a scene of using both ears, and the audio communication method between a mobile phone and a single ear (a left earphone or a right earphone) can refer to the method shown in fig. 6, and can be applied to more audio services, and has better compatibility. When a service scene is switched, the isochronous data transmission channel between the mobile phone and the earphone is configured based on the renegotiated parameters, switching between different profile protocol stacks is not needed, a transmission frame is not needed to be switched, the method is more efficient, and obvious pause can be avoided.

The BLE connection establishment procedure is explained below in conjunction with figure 9. As shown in fig. 9, the BLE connection establishment procedure may include:

1. BLE connection is established between the left earphone and the right earphone (S902-S907)

And S902-S903, the Host of the left earphone initiates BLE connection establishment through an HCI instruction. Specifically, the Host of the left headphone may send an HCI command "LE create connection" to the LL of the left headphone through the HCI. Accordingly, the LL of the left earpiece may return a response message "HCI Command Status".

S904, the right earphone transmits the broadcast.

And S905, the left earphone initiates connection to the right earphone. Specifically, the LL of the left earpiece sends a connection request to the LL of the right earpiece.

And S906, after receiving the connection request, the LL of the right earphone informs the Host of the right earphone through an HCI instruction, and the BLE connection is established.

And S907, after sending the connection request, the LL of the left earphone informs the Host of the left earphone through an HCI instruction, and BLE connection establishment is completed.

In summary, the BLE establishment connection procedure described in S902-S907 is as follows: the right earphone sends the broadcast, and the left earphone initiates the connection to the right earphone. Optionally, the left earphone may also send a broadcast, and the right earphone initiates a connection to the left earphone.

2. BLE connection is established between the left earphone and the mobile phone (S909-S914)

And S909-S910, the Host of the mobile phone initiates BLE connection establishment through an HCI instruction. Specifically, the Host of the mobile phone may send an HCI instruction "LE create connection" to the LL of the mobile phone through the HCI. Accordingly, the LL of the handset may return a response message "HCI Command Status".

And S911, the left earphone sends the broadcast.

S912, the mobile phone initiates connection to the left earphone. Specifically, a connection request is sent to the LL of the left earphone of the mobile phone.

And S913, after receiving the connection request, the LL of the left earphone informs the Host of the left earphone through an HCI instruction, and BLE connection establishment is completed.

And S914, after sending the connection request, the LL of the mobile phone informs the Host of the mobile phone through the HCI instruction, and the BLE connection is established.

In summary, the BLE establishment connection procedure described in S909-S914 is: the left earphone sends broadcast, and the mobile phone initiates connection to the left earphone. Optionally, the mobile phone may also send a broadcast, and the left earphone initiates a connection to the mobile phone.

3. BLE connection is established between the right earphone and the mobile phone (S916-S921)

And S911, the right earphone sends the broadcast.

S912, the mobile phone initiates connection to the right earphone. Specifically, a connection request is sent to the LL of the handset to the LL of the right earphone.

And S913, after receiving the connection request, the LL of the right earphone informs the Host of the right earphone through the HCI instruction, and the BLE connection is established.

In summary, the BLE establishment connection procedure described in S916-S921 is: the right earphone sends the broadcast, and the mobile phone initiates connection to the right earphone. Optionally, the mobile phone may also send a broadcast, and the right earphone initiates a connection to the mobile phone.

An exemplary electronic device 200 provided in an embodiment of the present application is described below. The electronic device 200 may be implemented as the first audio device mentioned in the above embodiments, and may be the first audio device 101 in the wireless audio system 100 shown in fig. 1. The electronic device 200 may be generally used as an audio source (audio source), such as a mobile phone, a tablet computer, etc., and may transmit audio data to other audio sink (audio sink), such as an earphone, a sound box, etc., so that the other audio sink may convert the audio data into sound. In some scenarios, the electronic device 200 may also be used as an audio sink (audio sink) to receive audio data (e.g., audio data captured by a headset into which a user's spoken voice is converted) transmitted by another device audio source (e.g., a headset with a microphone).

Fig. 10A shows a schematic structural diagram of the electronic device 200.

The electronic device 200 may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identity Module (SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the electronic device 200. In other embodiments of the present application, the electronic device 200 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processor (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), among others. Wherein, the different processing units may be independent devices or may be integrated in one or more processors. In some embodiments, the electronic device 200 may also include one or more processors 110.

The controller may be, among other things, a neural center and a command center of the electronic device 200. The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 110. If the processor 110 needs to use the instruction or data again, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the electronic device 200.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The I2C interface is a bidirectional synchronous serial bus including a serial data line (SDA) and a Serial Clock Line (SCL). In some embodiments, the processor 110 may include multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces, respectively. For example: the processor 110 may be coupled to the touch sensor 180K through an I2C interface, so that the processor 110 and the touch sensor 180K communicate through an I2C bus interface to implement a touch function of the electronic device 200.

The I2S interface may be used for audio communication. In some embodiments, processor 110 may include multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 through an I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through the I2S interface, so as to implement a function of answering a call through a bluetooth headset.

The PCM interface may also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled by a PCM bus interface. In some embodiments, the audio module 170 may also transmit the audio signal to the wireless communication module 160 through the PCM interface, so as to implement the function of answering a call through the bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus used for asynchronous communications. The bus may be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is generally used to connect the processor 110 with the wireless communication module 160. For example: the processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. In some embodiments, the audio module 170 may transmit the audio signal to the wireless communication module 160 through a UART interface, so as to implement the function of playing music through a bluetooth headset.

MIPI interfaces may be used to connect processor 110 with peripheral devices such as display screen 194, camera 193, and the like. The MIPI interface includes a Camera Serial Interface (CSI), a Display Serial Interface (DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the capture functionality of electronic device 200. The processor 110 and the display screen 194 communicate through the DSI interface to implement the display function of the electronic device 200.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal and may also be configured as a data signal. In some embodiments, a GPIO interface may be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, and the like. The GPIO interface may also be configured as an I2C interface, I2S interface, UART interface, MIPI interface, and the like.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 200, and may also be used to transmit data between the electronic device 200 and a peripheral device. And the earphone can also be used for connecting an earphone and playing audio through the earphone. The interface may also be used to connect other electronic devices, such as AR devices and the like.

It should be understood that the connection relationship between the modules according to the embodiment of the present invention is only illustrative, and is not limited to the structure of the electronic device 200. In other embodiments, the electronic device 200 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The charging management module 140 is configured to receive charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive a wireless charging input through a wireless charging coil of the electronic device 200. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be used to monitor parameters such as battery capacity, battery cycle count, battery state of health (leakage, impedance), etc. In some other embodiments, the power management module 141 may also be disposed in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be disposed in the same device.

The wireless communication function of the electronic device 200 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 200 may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution including wireless communication of 2G/3G/4G/5G, etc. applied to the electronic device 200. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 150 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the demodulated low frequency baseband signal to a baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs a sound signal through an audio device (not limited to the speaker 170A, the receiver 170B, etc.) or displays an image or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional modules, independent of the processor 110.

The wireless communication module 160 may provide a solution for wireless communication applied to the electronic device 200, including Wireless Local Area Networks (WLANs) (e.g., wireless fidelity (Wi-Fi) networks), bluetooth (bluetooth, BT), global Navigation Satellite System (GNSS), frequency Modulation (FM), near Field Communication (NFC), infrared (IR), and the like. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, perform frequency modulation and amplification on the signal, and convert the signal into electromagnetic waves through the antenna 2 to radiate the electromagnetic waves. Illustratively, the wireless communication module 160 may include a bluetooth module, a Wi-Fi module, and the like.

In some embodiments, antenna 1 of electronic device 200 is coupled to mobile communication module 150 and antenna 2 is coupled to wireless communication module 160 so that electronic device 200 can communicate with networks and other devices through wireless communication techniques. The wireless communication technology may include global system for mobile communications (GSM), general Packet Radio Service (GPRS), code division multiple access (code division multiple access, CDMA), wideband Code Division Multiple Access (WCDMA), time-division code division multiple access (time-division code division multiple access, TD-SCDMA), long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and/or IR technologies, etc. The GNSS may include a Global Positioning System (GPS), a global navigation satellite system (GLONASS), a beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and/or a Satellite Based Augmentation System (SBAS).

The electronic device 200 may implement display functions via the GPU, the display screen 194, and the application processor, etc. The GPU is a microprocessor for image processing, and is connected to the display screen 194 and an application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute instructions to generate or change display information.

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and the like. In some embodiments, the electronic device 200 may include 1 or N display screens 194, N being a positive integer greater than 1.

The electronic device 200 may implement a photographing function through the ISP, the camera 193, the video codec, the GPU, the display screen 194, and the application processor, etc.

The ISP is used to process the data fed back by the camera 193. For example, when a user takes a picture, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, an optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing and converting into an image visible to the naked eye. The ISP can also carry out algorithm optimization on the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then transmits the electrical signal to the ISP to be converted into a digital image signal. And the ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into image signal in standard RGB, YUV and other formats. In some embodiments, the electronic device 200 may include 1 or N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process digital image signals and other digital signals. For example, when the electronic device 200 selects a frequency bin, the digital signal processor is used to perform fourier transform or the like on the frequency bin energy.

Video codecs are used to compress or decompress digital video. The electronic device 200 may support one or more video codecs. In this way, the electronic device 200 may play or record video in a variety of encoding formats, such as: moving Picture Experts Group (MPEG) -1, MPEG-2, MPEG-3, MPEG-4, and so on.

The NPU is a neural-network (NN) computing processor that processes input information quickly by using a biological neural network structure, for example, by using a transfer mode between neurons of a human brain, and can also learn by itself continuously. The NPU can implement applications such as intelligent recognition of the electronic device 200, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to extend the memory capability of the electronic device 200. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, data such as music, photos, video, etc. are stored in an external memory card.

Internal memory 121 may be used to store one or more computer programs, including instructions. The processor 110 may execute the above instructions stored in the internal memory 121, so as to enable the electronic device 200 to perform the method for data sharing provided in some embodiments of the present application, and various functional applications, data processing, and the like. The internal memory 121 may include a program storage area and a data storage area. Wherein, the storage program area can store an operating system; the storage area may also store one or more application programs (e.g., gallery, contacts, etc.), etc. The storage data area may store data (e.g., photos, contacts, etc.) created during use of the electronic device 200. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like.

The electronic device 200 may implement audio functions via the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D, and the application processor. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or some functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also called a "horn", is used to convert the audio electrical signal into an acoustic signal. The electronic apparatus 200 can listen to music through the speaker 170A or listen to a handsfree call.

The receiver 170B, also called "earpiece", is used to convert the electrical audio signal into an acoustic signal. When the electronic apparatus 200 receives a call or voice information, it is possible to receive voice by placing the receiver 170B close to the human ear.

The microphone 170C, also referred to as a "microphone," is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can input a voice signal to the microphone 170C by speaking near the microphone 170C through the mouth. The electronic device 200 may be provided with at least one microphone 170C. In other embodiments, the electronic device 200 may be provided with two microphones 170C to achieve a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 200 may further include three, four or more microphones 170C to collect sound signals, reduce noise, identify sound sources, perform directional recording, and the like.

The earphone interface 170D is used to connect a wired earphone. The headset interface 170D may be the USB interface 130, or may be a 3.5mm open mobile electronic device platform (OMTP) standard interface, a cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

The pressure sensor 180A is used for sensing a pressure signal, and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194. The pressure sensor 180A can be of a wide variety, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, and the like. The capacitive pressure sensor may be a sensor comprising at least two parallel plates having an electrically conductive material. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 200 determines the intensity of the pressure from the change in capacitance. When a touch operation is applied to the display screen 194, the electronic apparatus 200 detects the intensity of the touch operation according to the pressure sensor 180A. The electronic apparatus 200 may also calculate the touched position from the detection signal of the pressure sensor 180A. In some embodiments, the touch operations that are applied to the same touch position but have different touch operation intensities may correspond to different operation instructions. For example: and when the touch operation with the touch operation intensity smaller than the first pressure threshold value acts on the short message application icon, executing an instruction for viewing the short message. And when the touch operation with the touch operation intensity larger than or equal to the first pressure threshold value acts on the short message application icon, executing an instruction of newly building the short message.

The gyro sensor 180B may be used to determine the motion attitude of the electronic device 200. In some embodiments, the angular velocity of the electronic device 200 about three axes (i.e., x, y, and z axes) may be determined by the gyroscope sensor 180B. The gyro sensor 180B may be used for photographing anti-shake. Illustratively, when the shutter is pressed, the gyro sensor 180B detects a shake angle of the electronic device 200, calculates a distance to be compensated for by the lens module according to the shake angle, and allows the lens to counteract the shake of the electronic device 200 through a reverse movement, thereby achieving anti-shake. The gyroscope sensor 180B may also be used for navigation, somatosensory gaming scenes.

The air pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 200 calculates altitude, aiding in positioning and navigation, from barometric pressure values measured by the barometric pressure sensor 180C.

The magnetic sensor 180D includes a hall sensor. The electronic device 200 may detect the opening and closing of the flip holster using the magnetic sensor 180D. In some embodiments, when the electronic device 200 is a flip, the electronic device 200 may detect the opening and closing of the flip according to the magnetic sensor 180D. And then according to the detected opening and closing state of the leather sheath or the opening and closing state of the flip, the characteristics of automatic unlocking of the flip and the like are set.

The acceleration sensor 180E may detect the magnitude of acceleration of the electronic device 200 in various directions (typically three axes). The magnitude and direction of gravity can be detected when the electronic device 200 is stationary. The method can also be used for recognizing the posture of the electronic equipment, and is applied to horizontal and vertical screen switching, pedometers and other applications.

A distance sensor 180F for measuring a distance. The electronic device 200 may measure the distance by infrared or laser. In some embodiments, taking a picture of a scene, the electronic device 200 may utilize the distance sensor 180F to range to achieve fast focus.

The proximity light sensor 180G may include, for example, a Light Emitting Diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The electronic apparatus 200 emits infrared light to the outside through the light emitting diode. The electronic device 200 detects infrared reflected light from nearby objects using a photodiode. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 200. When insufficient reflected light is detected, the electronic device 200 may determine that there are no objects near the electronic device 200. The electronic device 200 can utilize the proximity light sensor 180G to detect that the user holds the electronic device 200 close to the ear for talking, so as to automatically turn off the screen to achieve the purpose of saving power. The proximity light sensor 180G may also be used in a holster mode, a pocket mode automatically unlocks and locks the screen.

The ambient light sensor 180L is used to sense the ambient light level. The electronic device 200 may adaptively adjust the brightness of the display screen 194 based on the perceived ambient light level. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking a picture. The ambient light sensor 180L may also cooperate with the proximity light sensor 180G to detect whether the electronic device 200 is in a pocket to prevent accidental touches.

The fingerprint sensor 180H is used to collect a fingerprint. The electronic device 200 can utilize the collected fingerprint characteristics to unlock the fingerprint, access the application lock, photograph the fingerprint, answer an incoming call with the fingerprint, and the like.

The temperature sensor 180J is used to detect temperature. In some embodiments, the electronic device 200 implements a temperature processing strategy using the temperature detected by the temperature sensor 180J. For example, when the temperature reported by the temperature sensor 180J exceeds the threshold, the electronic device 200 performs a reduction in performance of the processor located near the temperature sensor 180J, so as to reduce power consumption and implement thermal protection. In other embodiments, the electronic device 200 heats the battery 142 when the temperature is below another threshold to avoid the low temperature causing the electronic device 200 to shut down abnormally. In other embodiments, the electronic device 200 performs boosting of the output voltage of the battery 142 when the temperature is below a further threshold value to avoid abnormal shutdown due to low temperature.

Touch sensor 180K, which may also be referred to as a touch panel or touch sensitive surface. The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is used to detect a touch operation acting thereon or nearby. The touch sensor can communicate the detected touch operation to the application processor to determine the touch event type. Visual output associated with the touch operation may be provided through the display screen 194. In other embodiments, the touch sensor 180K may be disposed on the surface of the electronic device 200 at a different position than the display screen 194.

The bone conduction sensor 180M may acquire a vibration signal. In some embodiments, the bone conduction sensor 180M may acquire a vibration signal of the human vocal part vibrating the bone mass. The bone conduction sensor 180M may also contact the human body pulse to receive the blood pressure pulsation signal. In some embodiments, the bone conduction sensor 180M may also be disposed in a headset, integrated into a bone conduction headset. The audio module 170 may analyze a voice signal based on the vibration signal of the bone mass vibrated by the sound part acquired by the bone conduction sensor 180M, so as to implement a voice function. The application processor can analyze heart rate information based on the blood pressure beating signal acquired by the bone conduction sensor 180M, so as to realize the heart rate detection function.

The keys 190 include a power-on key, a volume key, and the like. The keys 190 may be mechanical keys. Or may be touch keys. The electronic apparatus 200 may receive a key input, and generate a key signal input related to user setting and function control of the electronic apparatus 200.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration cues, as well as for touch vibration feedback. For example, touch operations applied to different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects. The motor 191 may also respond to different vibration feedback effects for touch operations applied to different areas of the display screen 194. Different application scenes (such as time reminding, receiving information, alarm clock, game and the like) can also correspond to different vibration feedback effects. The touch vibration feedback effect may also support customization.

Indicator 192 may be an indicator light that may be used to indicate a state of charge, a change in charge, or a message, missed call, notification, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card can be brought into and out of contact with the electronic apparatus 200 by being inserted into the SIM card interface 195 or being pulled out of the SIM card interface 195. The electronic device 200 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 195 may support a Nano SIM card, a Micro SIM card, a SIM card, etc. The same SIM card interface 195 can be inserted with multiple cards at the same time. The types of the plurality of cards may be the same or different. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 may also be compatible with external memory cards. The electronic device 200 interacts with the network through the SIM card to implement functions such as communication and data communication. In some embodiments, the electronic device 200 employs esims, namely: an embedded SIM card. The eSIM card can be embedded in the electronic device 200 and cannot be separated from the electronic device 200.

The electronic device 200 exemplarily illustrated in fig. 10A may display various user interfaces described in various embodiments below through the display screen 194. The electronic device 200 may detect a touch operation in each user interface through the touch sensor 180K, such as a click operation in each user interface (e.g., a touch operation on an icon, a double-click operation), an upward or downward sliding operation in each user interface, or an operation of performing a circle-making gesture, and so on. In some embodiments, the electronic device 200 may detect a motion gesture performed by the user holding the electronic device 200, such as shaking the electronic device, through the gyro sensor 180B, the acceleration sensor 180E, and so on. In some embodiments, the electronic device 200 may detect the non-touch gesture operation through the camera 193 (e.g., 3D camera, depth camera).

In some implementations, an end Application Processor (AP) included in the electronic device 200 may implement Host in the audio protocol framework shown in fig. 3, and a Bluetooth (BT) module included in the electronic device 200 may implement controller in the audio protocol framework shown in fig. 3, which communicate therebetween through HCI. I.e. the functionality of the audio protocol framework shown in fig. 3 is distributed over two chips.

In other embodiments, the electronic device 200 terminal Application Processor (AP) may implement the Host and controller in the audio protocol framework shown in fig. 3. That is, all functions of the audio protocol framework shown in fig. 3 are placed on one chip, that is, the host and the controller are placed on the same chip, and since the host and the controller are both on the same chip, there is no necessity for a physical HCI, and the host and the controller interact directly through an application programming interface API.

The software system of the electronic device 200 may employ a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention uses an Android system with a hierarchical architecture as an example to exemplarily explain a software structure of the electronic device 200.

Fig. 10B is a block diagram of the software configuration of the electronic apparatus 200 according to the embodiment of the present invention.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer from top to bottom.

The application layer may include a series of application packages.

As shown in FIG. 10B, the application packages may include games, voice assistants, music players, video players, mailboxes, conversations, navigation, file browsers, and like applications.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 10B, the application framework layers may include a window manager, content provider, view system, phone manager, resource manager, notification manager, and the like.

The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

Content providers are used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and answered, browsing history and bookmarks, phone books, etc.

The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

The phone manager is used to provide communication functions of the electronic device 200. Such as management of call status (including on, off, etc.).

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, prompting text information in the status bar, sounding a prompt tone, vibrating the electronic device, flashing an indicator light, etc.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

The core library comprises two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), and the like.

The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. The media library may support a variety of audio-video encoding formats such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

The following describes exemplary workflow of the software and hardware of the electronic device 200 in connection with capturing a photo scene.

When the touch sensor 180K receives a touch operation, a corresponding hardware interrupt is issued to the kernel layer. The kernel layer processes the touch operation into an original input event (including touch coordinates, a time stamp of the touch operation, and other information). The raw input events are stored at the kernel layer. And the application program framework layer acquires the original input event from the kernel layer and identifies the control corresponding to the input event. Taking the touch operation as a touch operation, and taking the control corresponding to the touch operation as the control of the camera application icon as an example, the camera application calls an interface of the application framework layer to start the camera application, and then starts the camera drive by calling the kernel layer, and captures a still image or a video through the camera 193.

An exemplary audio output device 300 provided in the embodiments of the present application is described below. The audio output device 300 may be implemented as the second audio device or the third audio device mentioned in the above embodiments, and may be the second audio device 102 or the third audio device 103 in the wireless audio system 100 shown in fig. 1. The audio output device 300 may be generally used as an audio sink (e.g., a headphone, a speaker), may transmit audio data to another audio source (e.g., a mobile phone, a tablet computer, etc.), and may convert the received audio data into sound. In some scenarios, if a sound collection device such as a microphone/receiver is configured, the audio output device 300 may also be used as an audio source (audio source) to transmit audio data (e.g., audio data converted from a user's speech collected by a headset) to an audio sink (e.g., a mobile phone) of another device.

Fig. 11 schematically shows a structure of an audio output device 300 provided in the present application.

As shown in fig. 11, the audio output device 300 may include a processor 302, a memory 303, a bluetooth communication processing module 304, a power supply 305, a wear detector 306, a microphone 307, and an electric/acoustic transducer 308. These components may be connected by a bus. Wherein:

processor 302 may be used to read and execute computer readable instructions. In particular implementations, processor 302 may primarily include a controller, an operator, and registers. The controller is mainly responsible for instruction decoding and sending out control signals for operations corresponding to the instructions. The arithmetic unit is mainly responsible for executing fixed-point or floating-point arithmetic operation, shift operation, logic operation and the like, and can also execute address operation and conversion. The register is mainly responsible for storing register operands, intermediate operation results and the like temporarily stored in the instruction execution process. In a Specific implementation, the hardware architecture of the processor 302 may be an Application Specific Integrated Circuits (ASIC) architecture, an MIPS architecture, an ARM architecture, or an NP architecture, for example.

In some embodiments, the processor 302 may be configured to parse signals received by the bluetooth communication processing module 304, such as signals encapsulating audio data, content control messages, flow control messages, and so forth. The processor 302 may be configured to perform corresponding processing operations according to the parsing result, such as driving the electric/acoustic converter 308 to start or pause or stop converting the audio data into sound, and so on.

In some embodiments, the processor 302 may also be configured to generate signals sent out by the bluetooth communication processing module 304, such as bluetooth broadcast signals, beacon signals, and audio data converted from collected sounds.

Memory 303 is coupled to processor 302 for storing various software programs and/or sets of instructions. In particular implementations, memory 303 may include high speed random access memory and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. The memory 303 may store an operating system, such as an embedded operating system like uCOS, vxWorks, RTLinux, etc. The memory 303 may also store communication programs that may be used to communicate with the electronic device 200, one or more servers, or additional devices.

The Bluetooth (BT) communication processing module 304 may receive signals transmitted by other devices, such as the electronic device 200, such as scanning signals, broadcast signals, signals encapsulating audio data, content control messages, flow control messages, and so forth. The Bluetooth (BT) communication processing module 304 may also transmit signals such as broadcast signals, scanning signals, signals encapsulating audio data, content control messages, flow control messages, and the like.

The power supply 305 may be used to power the processor 302, memory 303, bluetooth communication processing module 304, wear detector 306, electric/acoustic transducer 308, and other internal components.

The wearing detector 306 may be used to detect a state in which the audio output device 300 is worn by the user, such as an unworn state, a worn state, and may even include a wearing tightness state. In some embodiments, wear detector 306 may be implemented by one or more of a distance sensor, a pressure sensor, and the like. The wear detector 306 may transmit the detected wear status to the processor 302 so that the processor 302 may power up when the audio output device 300 is worn by the user and power down when the audio output device 300 is not worn by the user to save power consumption.

The microphone 307 may be used to collect sounds, such as the voice of a user speaking, and may output the collected sounds to the electric/acoustic transducer 308, so that the electric/acoustic transducer 308 may convert the sounds collected by the microphone 307 into audio data.

The electric/acoustic transducer 308 may be used to convert sound into an electrical signal (audio data), for example, convert sound collected by the microphone 307 into audio data, and may transmit the audio data to the processor 302. In this way, the processor 302 may trigger the Bluetooth (BT) communication processing module 304 to transmit the audio data. The electric/acoustic transducer 308 may also be used to convert electrical signals (audio data) into sound, for example, audio data output by the processor 302 into sound. The audio data output by the processor 302 may be received by a Bluetooth (BT) communication processing module 304.

In some implementations, the processor 302 may implement Host in the audio protocol framework shown in fig. 3, and the Bluetooth (BT) communication processing module 304 may implement controller in the audio protocol framework shown in fig. 3, which communicate with each other through HCI. I.e. the functionality of the audio protocol framework shown in fig. 3 is distributed over two chips.

In other embodiments, the processor 302 may implement Host and controller in the audio protocol framework shown in FIG. 3. That is, all functions of the audio protocol framework shown in fig. 3 are placed on one chip, that is, the host and the controller are placed on the same chip, and since the host and the controller are both on the same chip, there is no necessity for a physical HCI, and the host and the controller interact directly through an application programming interface API.

It is to be understood that the configuration illustrated in fig. 11 does not constitute a specific limitation to the audio output device 300. In other embodiments of the present application, the audio output device 300 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Referring to fig. 12, fig. 12 is a schematic diagram illustrating a chip set according to the present disclosure. As shown in fig. 12, the chip set 400 may include a chip 1 and a chip 2. The chip 1 and the chip 2 communicate with each other through an interface HCI 409. The chip 1 may include the following modules: a multimedia audio module 402, a voice module 403, a background sound module 404, a content control module 405, a stream control module 406, a stream data module 407, and an L2CAP module 408. The chip 2 may include: LE physical layer module 413, LE link layer module 410.

In chip 2:

(1) LE physical layer module 413 may be used to provide a physical channel (often referred to as a channel) for data transmission. Typically, several different types of channels exist in a communication system, such as control channels, data channels, voice channels, and so on.

(2) The LE link layer module 410 may be configured to provide a physical independent logical transmission channel (also referred to as a logical link) between two or more devices on a physical layer basis. The LE link layer module 410 may be used to control the radio frequency state of a device, which will be in one of five states: wait, advertise, scan, initialize, connect. The broadcasting equipment can send data without establishing connection, and the scanning equipment receives the data sent by the broadcasting equipment; the device initiating the connection responds to the broadcasting device by sending a connection request, and if the broadcasting device accepts the connection request, the broadcasting device and the device initiating the connection enter a connected state. The device that initiates the connection is called the master (master) and the device that accepts the connection request is called the slave (slave).

LE link layer module 410 may include LE ACL module 411 and LE Isochronous (ISO) module 412.LE ACL module 411 may be used to transmit inter-device control messages, such as flow control messages, content control messages, volume control messages, over the LE ACL link. The LE ISO module 412 may be used to transmit isochronous data (such as streaming data itself) between devices over an isochronous data transmission channel.

In chip 1:

(1) The L2CAP module 408 may be configured to manage the logical link provided by the logical layer. Based on L2CAP, different upper layer applications may share the same logical link. Like the concept of port (port) in TCP/IP.

(2) The multimedia audio module 402, the voice module 403, and the background sound module 404 may be modules set according to service scenes, and may be used to divide the audio application of the application layer into several audio services, such as multimedia audio, voice, background sound, and so on. Not limited to multimedia audio, voice, background sound, etc., audio services can also be classified into: voice, music, games, video, voice assistant, mail alert tone, alarm, alert tone, navigation tone, etc.

(3) The content control module 405 may be responsible for encapsulating the content of various audio services

Control (e.g., previous, next, etc.) messages and output content control messages for audio traffic to LE ACL module 411 for transmission of encapsulated content control messages by LE ACL module 411.

(4) The stream control module 406 may be used to perform parameter negotiation for a specific audio service, such as negotiation of QoS parameters, negotiation of coding (Codec) parameters, negotiation of ISO parameters, and creation of an isochronous data transmission channel for the specific service based on the negotiated parameters. An isochronous data transmission channel is created for the particular service that can be used to transmit audio data for the particular audio service. In this application, the specific audio service may be referred to as a first audio service, and the negotiated parameters may be referred to as first parameters.

(5) The stream data module 407 may be configured to output audio data of the audio service to an LE Isochronous (ISO) module 412 for transmission of the audio data over an isochronous data transmission channel. The isochronous data transfer channel may be a CIS. The CIS may be used to transfer isochronous data between devices in a connected state. The isochronous data transport channel is ultimately carried in the LE ISO 412.

In specific implementation, the chip 1 may be implemented as an Application Processor (AP), and the chip 2 may be implemented as a bluetooth processor (or referred to as a bluetooth module, a bluetooth chip, etc.). In this application, chip 1 may be referred to as a first chip and chip 2 may be referred to as a second chip. The chip set 400 may be included in the first audio device in the foregoing method embodiment, or may be included in the first audio device and the second audio device in the foregoing method embodiment.

It is to be understood that the structure illustrated in fig. 12 does not constitute a specific limitation on the chipset 400. In other embodiments of the present application, chipset 400 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Referring to fig. 13, fig. 13 shows a schematic structural diagram of a chip provided in the present application. As shown in fig. 13, the chip 500 may include: multimedia audio module 502, voice module 503, background sound module 504, content control module 505, stream control module 506, stream data module 507, L2CAP module 508, LE physical layer module 513, LE link layer module 510. The description of each module may refer to the corresponding module in fig. 12, and is not repeated here.

Unlike the chip architecture shown in fig. 12, the chip architecture shown in fig. 13 is implemented by placing the Host and the Controller in the audio protocol framework shown in fig. 3 on one chip. Since the Host and the Controller are implemented on the same chip, the HCI may not be required inside the chip. The chip architecture shown in fig. 12 is that Host and Controller in the audio protocol framework shown in fig. 3 are implemented in two chips, respectively.

The chip 500 may be included in the first audio device in the foregoing method embodiment, or may be included in the first audio device and the second audio device in the foregoing method embodiment.

It is to be understood that the structure illustrated in fig. 13 does not constitute a specific limitation on the chip 500. In other embodiments of the present application, chip 500 may include more or fewer components than shown, or some components may be combined, some components may be split, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims

1. An audio communication method, comprising:

an audio source and an audio receiver establish a low-power Bluetooth connectionless asynchronous LE ACL link; a low-power Bluetooth connection is established between the audio source and the audio receiver, and the LE ACL link is used for transmitting control messages;

the audio source executes parameter negotiation for a first audio service through the LE ACL link and the audio receiver, wherein a first parameter negotiated by the parameter negotiation corresponds to the first audio service;

the audio source creates an LE isochronous data transmission channel corresponding to the first audio service based on the first parameter and the audio receiver; and the LE isochronous data transmission channel corresponding to the first audio service is used for the audio source to send the audio data of the first audio service to the audio receiver.

2. The method of claim 1, comprising:

the audio source generating a content control message for the first audio service;

the audio source sends a content control message of the first audio service to the audio receiver through the LE ACL link; the content control message is used for the audio receiver to perform content control on the first audio service, and the content control comprises one or more of the following items: volume control, play control, call control.

3. The method of any one of claims 1-2, comprising:

the audio source receives a content control message of the first audio service sent by the audio receiver through the LE ACL link;

the audio source performs content control on the first audio service according to the content control message, wherein the content control comprises one or more of the following items: volume control, play control, and call control.

4. The method of any one of claims 1-2, comprising:

the audio source generates audio data of the first audio service;

and the audio source sends the audio data of the first audio service to the audio receiver through an LE isochronous data transmission channel corresponding to the first audio service.

5. The method of claim 2, wherein the content control message comprises one or more of: volume control messages, play control messages, call control messages.

6. The method of any one of claims 1-2, wherein the first parameter comprises one or more of: quality of service QoS parameters, codec parameters, isochronous data transmission channel parameters.

7. An audio communication method, comprising:

the audio receiver and the audio source establish a low-power Bluetooth connectionless asynchronous LE ACL link; a low-power Bluetooth connection is established between the audio source and the audio receiver, and the LE ACL link is used for transmitting control messages;

the audio receiver executes parameter negotiation for a first audio service through the LE ACL link and the audio source, wherein a first parameter negotiated by the parameter negotiation corresponds to the first audio service;

the audio receiving party creates an LE isochronous data transmission channel corresponding to the first audio service based on the first parameter and the audio source; and the LE isochronous data transmission channel corresponding to the first audio service is used for the audio receiver to receive the audio data of the first audio service sent by the audio source.

8. The method of claim 7, comprising:

the audio receiver receives a content control message of the first audio service sent by the audio source through the LE ACL link;

the audio receiver performs content control on the first audio service according to the content control message, wherein the content control comprises one or more of the following items: volume control, play control, and call control.

9. The method of claim 7 or 8, comprising:

the audio receiver generates a content control message of the first audio service;

the audio receiver sends a content control message of the first audio service to the audio source through the LE ACL link; the content control message is used for the audio source to perform content control on the first audio service, and the content control comprises one or more of the following items: volume control, play control, and call control.

10. The method of any one of claims 7-8, comprising:

and the audio receiver receives the audio data of the first audio service sent by the audio source through an LE isochronous data transmission channel corresponding to the first audio service.

11. The method of claim 8, wherein the content control message comprises one or more of: volume control messages, play control messages, call control messages.

12. The method of any one of claims 7-8, wherein the first parameter comprises one or more of: quality of service (QoS) parameters, coding codec parameters, isochronous data transmission channel parameters.

13. An audio device, comprising: a transmitter and a receiver, a memory for storing instructions executable by the processor, and a processor coupled to the memory for invoking the instructions in the memory to perform the method of any of claims 1-6.

14. An audio device, comprising: a transmitter and a receiver, a memory for storing instructions executable by the processor, and a processor coupled to the memory for invoking the instructions in the memory to perform the method of any one of claims 7-12.

15. A chipset, comprising: a first chip and a second chip; the first chip comprises a flow control module, a content control module and a stream data module; the second chip comprises an LE ACL module and an LE isochronous module; wherein:

the flow control module is used for performing parameter negotiation for a first audio service, and creating an LE isochronous data transmission channel corresponding to the first audio service based on a first parameter negotiated by the parameter negotiation;

the content control module is used for outputting a content control message of the first audio service to the LE ACL module;

the stream data module is used for outputting the audio data of the first audio service to the LE isochronous module;

the LE ACL module is used for transmitting the content control message of the first audio service through an LE ACL link;

and the LE isochronous module is used for transmitting the audio data of the first audio service through an LE isochronous data transmission channel corresponding to the first audio service.

16. A chip, comprising: the system comprises a flow control module, a content control module, a stream data module, an LE ACL module and an LE isochronous module; wherein:

the flow control module is used for performing parameter negotiation for a first audio service and creating an LE isochronous data transmission channel corresponding to the first audio service based on a first parameter negotiated by the parameter negotiation;

17. A communication system, comprising: a first audio device and a second audio device, wherein:

the first audio device is the audio device of claim 13 and the second audio device is the audio device of claim 14.

18. A communication system, comprising: a first audio device, a second audio device, and a third audio device, wherein:

the first audio device is the audio device of claim 13, and the second and third audio devices are the audio devices of claim 14.