Communication method based on Bluetooth transient disconnection, Bluetooth earphone and terminal equipment

Abstract

The invention discloses a communication method based on Bluetooth transient disconnection, a Bluetooth earphone and terminal equipment, and the method comprises the steps: determining the state of a Bluetooth link at an earphone end side based on Bluetooth signal parameters, starting a first caching mechanism when the state is unstable, recording a disconnection timestamp and a reconnection timestamp when a Bluetooth link disconnection and reconnection event occurs, and starting a second caching mechanism when the disconnection timestamp and the reconnection timestamp are recorded; according to the disconnection timestamp and the reconnection timestamp, obtaining first audio data from the earphone end cache region, and sending the first audio data to the terminal for call sending; and at the terminal side, determining the state of the Bluetooth link based on the Bluetooth signal parameters, starting a second cache mechanism when the state is unstable, recording a disconnection timestamp and a reconnection timestamp when a Bluetooth link disconnection and reconnection event occurs, acquiring second audio data from a terminal cache region according to the disconnection timestamp and the reconnection timestamp, and sending the second audio data to the terminal cache region. And sending to an earphone end for call answering. According to the method, loss and leakage of call content caused by temporary disconnection between the Bluetooth earphone and the terminal equipment can be avoided.

Description

Communication methods based on brief Bluetooth disconnections, Bluetooth headsets and terminal devices Technical Field

[0001] This application relates to the field of mobile communications, and more particularly to a communication method based on Bluetooth brief disconnection, a Bluetooth headset, and a terminal device. Background Technology

[0002] Bluetooth headsets, with their wireless and portable advantages, have become widely used smart devices in people's work, study, and daily life. With the continuous development of wireless audio transmission technology, users' demands for connection stability and audio quality are constantly increasing. However, Bluetooth headsets still face a series of technical challenges affecting stability in practical use, such as short transmission distance, susceptibility to obstruction by obstacles (such as walls), and signal interference from devices like Wi-Fi and microwave ovens. Furthermore, connection interruptions are prone to occur when switching to low-power modes or when the device exceeds its effective communication range. Especially in scenarios requiring highly reliable voice transmission (such as covert communication or secret alarms), brief connection drops and reconnections can lead to audio stuttering, voice data loss resulting in information leakage, severely impacting the user experience and potentially causing the leakage of critical information. For example, when a Bluetooth headset disconnects, the audio path switches to the terminal, changing from headset audio to speakerphone, and the microphone switches from the headset to the terminal's built-in microphone, leading to the leakage and loss of call content. Summary of the Invention

[0003] This application provides a communication method based on temporary Bluetooth disconnection, a Bluetooth headset, and a terminal device, with the aim of avoiding the loss and leakage of call content caused by temporary disconnection between the Bluetooth headset and the terminal device.

[0004] To achieve the above objectives, this application provides the following technical solution:

[0005] A communication method based on brief Bluetooth disconnection, applied to an earphone, the method comprising:

[0006] Based on Bluetooth signal parameters, determine the state of the Bluetooth link between the terminal and the headset.

[0007] When the Bluetooth link is unstable, a first caching mechanism is activated; the first caching mechanism is used to write the user audio data collected in real time by the headset and the corresponding timestamp into the headset buffer; the user audio data includes the voice data conveyed by the user to the caller; the headset buffer includes a preset circular buffer in the local memory of the headset.

[0008] When a Bluetooth link disconnection and reconnection event occurs, record the corresponding disconnection timestamp and reconnection timestamp;

[0009] Based on the disconnection timestamp and the reconnection timestamp, the corresponding first audio data is obtained from the earphone buffer and sent to the terminal for call transmission; the first audio data includes the voice data conveyed by the user to the call recipient within the time of the Bluetooth link disconnection and reconnection event.

[0010] A communication method based on brief Bluetooth disconnection, applied to a terminal, the method comprising:

[0011] Based on Bluetooth signal parameters, determine the status of the Bluetooth link between the headset and the terminal;

[0012] When the Bluetooth link is unstable, a second caching mechanism is activated; the second caching mechanism is used to write the call audio data received by the terminal in real time and the corresponding timestamp into the terminal cache area; the call audio data includes voice data conveyed by the caller to the user; the terminal cache area includes a preset circular buffer in the terminal's local memory;

[0013] When a Bluetooth link disconnection and reconnection event occurs, record the corresponding disconnection timestamp and reconnection timestamp;

[0014] Based on the disconnection timestamp and the reconnection timestamp, the corresponding second audio data is obtained from the terminal buffer and sent to the headset to answer the call; the second audio data includes the voice data conveyed by the caller to the user within the time of the Bluetooth link disconnection and reconnection event.

[0015] A Bluetooth headset is provided for performing a communication method based on a brief Bluetooth disconnection, as shown on the headset end.

[0016] A terminal device for performing a Bluetooth-based communication method with brief disconnections, as shown in the terminal.

[0017] The technical solution provided in this application, on the headset side, determines the Bluetooth link status based on Bluetooth signal parameters. When the status is unstable, a first buffering mechanism is activated. When a Bluetooth link disconnection and reconnection event occurs, the disconnection and reconnection timestamps are recorded. Based on the disconnection and reconnection timestamps, first audio data is retrieved from the headset's buffer and sent to the terminal for call transmission. On the terminal side, based on Bluetooth signal parameters, the Bluetooth link status is determined. When the status is unstable, a second buffering mechanism is activated. When a Bluetooth link disconnection and reconnection event occurs, the disconnection and reconnection timestamps are recorded. Based on the disconnection and reconnection timestamps, second audio data is retrieved from the terminal's buffer and sent to the headset for call answering. This application can avoid the loss and leakage of call content caused by brief disconnections between the Bluetooth headset and the terminal device. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 is a schematic diagram of the first process of a communication method based on a brief Bluetooth disconnection according to an embodiment of this application;

[0020] Figure 2 is a second flowchart of a communication method based on a brief Bluetooth disconnection provided in an embodiment of this application;

[0021] Figure 3 is a schematic diagram of the third process of a communication method based on a brief Bluetooth disconnection provided in an embodiment of this application;

[0022] Figure 4 is a schematic diagram of the fourth process of a communication method based on a brief Bluetooth disconnection provided in an embodiment of this application;

[0023] Figure 5 is a fifth flowchart of a communication method based on temporary Bluetooth disconnection provided in an embodiment of this application;

[0024] Figure 6 is a schematic diagram of the sixth process of a communication method based on a brief Bluetooth disconnection provided in an embodiment of this application;

[0025] Figure 7 is a schematic diagram of the seventh process of a communication method based on a brief Bluetooth disconnection provided in an embodiment of this application;

[0026] Figure 8 is a schematic diagram of the eighth process of a communication method based on a brief Bluetooth disconnection provided in an embodiment of this application;

[0027] Figure 9 is a schematic diagram of the architecture of a communication system provided in an embodiment of this application;

[0028] Figure 10 is a schematic diagram of information interaction between a Bluetooth headset and a terminal device according to an embodiment of this application;

[0029] Figure 11 is a schematic diagram of the architecture of a Bluetooth headset and a terminal device provided in an embodiment of this application;

[0030] Figure 12 is a schematic diagram of the communication process of a communication system provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0032] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0033] Figure 1 shows a first flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, applied to the headset end, including the following steps.

[0034] S101: Determine the status of the Bluetooth link between the terminal and the headset based on Bluetooth signal parameters.

[0035] Among them, when users make calls using the headset, they can manually enable the headset to enter high reliability mode, so that the headset can monitor Bluetooth signal parameters in real time and determine the status of the Bluetooth link between the terminal and the headset.

[0036] In some examples, the high reliability mode also configures the Bluetooth link disconnection and reconnection time so that the headset can identify whether the Bluetooth link disconnection and reconnection event is a short Bluetooth disconnection. In other words, the communication method shown in the embodiments of this application is applicable to the scenario of short Bluetooth disconnection.

[0037] For example, the Bluetooth link disconnection and reconnection time can be controlled within the range of 1 to 10 seconds.

[0038] In some examples, Bluetooth signal parameters include, but are not limited to, signal strength, packet loss rate, and other signal parameters.

[0039] It should be noted that when the Bluetooth signal parameters do not meet the specified threshold, the Bluetooth link between the terminal and the headset is determined to be unstable; when the Bluetooth signal parameters meet the specified threshold, the Bluetooth link between the terminal and the headset is determined to be stable.

[0040] In some examples, the Bluetooth link between the terminal and the headset is determined to be unstable when the signal strength is less than a specified signal strength threshold, and stable when the signal strength is greater than or equal to the specified signal strength threshold.

[0041] In another embodiment, when the packet loss rate reaches a specified threshold within a first preset time period, the Bluetooth link between the terminal and the headset is determined to be unstable. If no packet loss occurs within a second preset time period, the Bluetooth link between the terminal and the headset is determined to be stable.

[0042] It is understandable that when the Bluetooth link between the terminal and the headset is unstable, it can be assumed that the Bluetooth link may be disconnected at any time, or that the probability of a Bluetooth link disconnection and reconnection event is relatively high.

[0043] S102: When the Bluetooth link is unstable, activate the first buffer mechanism.

[0044] The first caching mechanism is used to write the user audio data collected in real time by the headset and the corresponding timestamp into the headset cache area; the user audio data includes the voice data conveyed by the user to the caller; the headset cache area includes a pre-set circular buffer in the local memory of the headset.

[0045] In some examples, the circular buffer can be designed as a first-in, first-out queue, where newly written data replaces old data to save memory space. When the Bluetooth link is unstable, the Bluetooth link disconnection and reconnection event does not occur immediately. Before the Bluetooth link disconnection and reconnection event occurs, in response to the first buffering mechanism, the headphone buffer still has a cache of user audio data. Since it is unknown when the connection will be lost, it can only be cached indefinitely until the Bluetooth link disconnects. The user audio data collected during the brief period until the Bluetooth link reconnects is the data that actually needs to be saved. Therefore, the headphone buffer is designed as a circular buffer to effectively save the first audio data mentioned later.

[0046] It is important to note that, based on the functional principle of the circular buffer, when the headphone buffer is full, newly written data will overwrite the old data, ensuring that the data written to the headphone buffer is always the latest and most relevant user audio data at the current moment.

[0047] Understandably, when the Bluetooth link is unstable, the terminal and the headset still interact with each other via the Bluetooth link. At this time, the headset not only responds to the first buffering mechanism by writing the real-time collected user audio data and the corresponding timestamp into the headset buffer, but also sends the user audio data to the terminal for call transmission.

[0048] Optionally, to avoid writing invalid data to the headphone buffer and improve the data quality and processing efficiency of the first audio data, the user audio data collected in real time by the headphone can be processed accordingly, as shown in Figure 2.

[0049] In a possible implementation, user audio data can typically be acquired in real time using a microphone on the headset.

[0050] S103: When a Bluetooth link disconnection and reconnection event occurs, record the corresponding disconnection timestamp and reconnection timestamp.

[0051] The Bluetooth link disconnection and reconnection event includes a disconnection event and a reconnection event. Therefore, when a disconnection event occurs, the corresponding disconnection timestamp is recorded, and when a reconnection event occurs, the corresponding reconnection timestamp is recorded.

[0052] S104: Based on the disconnection timestamp and reconnection timestamp, retrieve the corresponding first audio data from the headset buffer and send it to the terminal to initiate the call.

[0053] The first audio data includes voice data conveyed by the user to the other party during the time of the Bluetooth link disconnection and reconnection event.

[0054] It should be noted that the first audio data is determined by aligning the timestamps of the disconnection and reconnection with the timestamps of each user's audio data in the headphone's buffer. In a possible implementation, the Bluetooth link disconnection and reconnection event time can be denoted as T_outage, the disconnection timestamp as T_disconnect, and the reconnection timestamp as T_reconnect. The relationship between the three can be T_outage = T_reconnect - T_disconnect. In this way, the corresponding first audio data can be retrieved from the headphone's buffer based on T_outage.

[0055] Generally speaking, when a terminal sends user audio data during a call, it essentially means sending the user's audio data to the person being called through the call channel.

[0056] Optionally, the process of retrieving the corresponding first audio data from the headset buffer based on the disconnection and reconnection timestamps and sending it to the terminal for call transmission can be seen in the steps shown in Figures 3 and 4.

[0057] On the headset side, users can configure a high-reliability mode, enabling the headset to briefly disconnect and reconnect within a specified time range. This prevents the terminal from switching to its own audio path during brief Bluetooth link outages, effectively preventing call content leakage. Furthermore, when an unstable Bluetooth link is detected, a first-level buffering mechanism is activated. Based on the headset's buffer design, a circular buffer is used to cyclically overwrite old data to save memory space. When a Bluetooth link disconnection and reconnection event occurs, the first audio data in the headset's buffer is played quickly, followed by real-time user audio data. Combined with voice recognition, invalid user audio data is prevented from being written to the headset's buffer, compensating for communication delays during this event.

[0058] The processes described in S101-S104 above, based on the first caching mechanism, prevent the terminal from switching to the terminal's own audio path during the brief Bluetooth link disconnection period, effectively preventing the leakage of call content. By combining the disconnection timestamp and reconnection timestamp, the first audio data is obtained from the headset's buffer and sent to the terminal for call transmission, ensuring that the first audio data in the communication transmission state (i.e., the user speaks through the headset's microphone) is not lost, thereby effectively protecting the call content during the brief Bluetooth disconnection period.

[0059] Figure 2 shows a second flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, applied to the headset end, including the following steps.

[0060] S201: After the first caching mechanism is started, speech recognition is performed on the user audio data collected in real time by the headset to determine the semantic state of the user audio data.

[0061] Among them, speech recognition is performed on the user audio data collected in real time at the headset to determine the semantic state of the user audio data. Based on the semantic state, semantically invalid user audio data such as silence, noise, and trailing sounds can be identified.

[0062] S202: If the semantic state of the user audio data is invalid, write the user audio data to the headphone buffer is prohibited.

[0063] If the semantic state of the user's audio data is invalid, the user's audio data is considered to be semantically irrelevant and does not need to be written to the headphone buffer, thus avoiding occupying the buffer space of the headphone buffer. It can also compensate for the delay of the subsequent first audio data and improve the data quality of the first audio data.

[0064] The processes shown in S201-S202 above can avoid writing invalid user audio data into the headphone buffer based on the semantic state of the user audio data, thus saving buffer space in the headphone buffer.

[0065] Figure 3 shows a third flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, applied to the headset end, including the following steps.

[0066] S301: Based on the disconnection timestamp and reconnection timestamp, retrieve the corresponding first audio data from the headphone buffer.

[0067] The headphone-side cache stores the audio data of each user and the corresponding timestamp. Based on the disconnection timestamp and reconnection timestamp, the corresponding first audio data can be retrieved from the headphone-side cache.

[0068] S302: Send the first signaling to the terminal so that the terminal adjusts the call transmission rate.

[0069] The adjusted call sending rate is faster than the default call sending rate.

[0070] It should be noted that the call transmission rate affects the playback rate of the voice conveyed by the user to the other party. That is, the faster the call transmission rate, the faster the user's voice will be heard by the other party. For example, if the default call transmission rate is 1 and the adjusted call transmission rate is 1.5, then the rate at which the user's voice will be heard by the other party will increase by 1.5 times.

[0071] It is understandable that the call transmission rate is a configurable communication parameter in the terminal.

[0072] S303: Send the first audio data to the terminal so that the terminal can send the first audio data for the call according to the adjusted call sending rate.

[0073] The terminal transmits the first audio data according to the adjusted call transmission rate, which speeds up the processing efficiency of the first audio data. In other words, the voice rate of the first audio data heard by the call recipient is accelerated, thereby enabling the communication process of the first audio data to keep up with the real-time progress and ensuring the continuity of communication.

[0074] S304: After the first audio data is sent, a second signaling is sent to the terminal so that the terminal restores the call sending rate to the default call sending rate.

[0075] Specifically, after the first audio data is sent, a second signaling is sent to the terminal so that the terminal can restore the call sending rate to the default call sending rate. This means that the communication process has caught up with the real-time progress, so the call sending rate is restored to the default call sending rate, and subsequent communication returns to normal.

[0076] The process shown in S301-S304 above triggers the terminal to send the first audio data according to the adjusted call sending rate through the first signaling and the second signaling, so that the communication process of the first audio data catches up with the real-time progress. After the first audio data is sent, the terminal is triggered to restore the call sending rate to the default call sending rate, ensuring that subsequent communication returns to normal and effectively improving the continuity of communication.

[0077] Figure 4 shows a fourth flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, applied to the headset end, including the following steps.

[0078] S401: Based on the disconnection timestamp and reconnection timestamp, retrieve the corresponding first audio data from the headphone buffer.

[0079] Specifically, by aligning the disconnection and reconnection timestamps with the timestamps in the headphone buffer, the corresponding first audio data can be determined.

[0080] S402: After sending the first audio data to the terminal to send the call, clear the headset buffer and send the newly collected audio data of the new user to the terminal to send the call.

[0081] The process prioritizes sending the first audio data to the terminal for call transmission, ensuring that the user's audio data can be transmitted to the caller within the time frame of the Bluetooth link disconnection and reconnection event, thus ensuring communication continuity. Then, the headset buffer is cleared to prevent the first audio data from occupying the headset buffer space, and the newly collected user audio data from the headset is sent to the terminal for call transmission, restoring normal communication. The entire process is seamless for both the user and the caller, effectively improving the user experience of Bluetooth communication.

[0082] The processes shown in S401-S402 above achieve a smooth transition during the Bluetooth link disconnection and reconnection event, ensuring the continuity of Bluetooth communication and effectively improving the user experience of Bluetooth communication.

[0083] Figure 5 shows a fifth flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, applied to a terminal, and includes the following steps.

[0084] S501: Determines the status of the Bluetooth link between the headset and the terminal based on Bluetooth signal parameters.

[0085] The terminals include, but are not limited to, mobile communication devices such as mobile phones, smartwatches, and walkie-talkies.

[0086] S502: When the Bluetooth link is unstable, activate the second buffer mechanism.

[0087] The second caching mechanism is used to write the real-time call audio data and corresponding timestamps received by the terminal into the terminal cache area; the call audio data includes the voice data conveyed by the caller to the user; the terminal cache area includes a pre-set circular buffer in the terminal's local memory.

[0088] It should be noted that when the Bluetooth link is unstable, the terminal and the headset still communicate via the Bluetooth link. At this time, the terminal not only responds to the first buffer mechanism by writing the real-time received call audio data and the corresponding timestamp into the terminal buffer, but also sends the call audio data to the headset to answer the call.

[0089] Optionally, to avoid writing invalid data to the terminal buffer and improve the data quality and processing efficiency of the second audio data, the call audio data received by the terminal in real time can be processed accordingly, as shown in Figure 6.

[0090] In a possible implementation, user audio data can typically be acquired in real time using a microphone on the headset.

[0091] S503: When a Bluetooth link disconnection and reconnection event occurs, record the corresponding disconnection timestamp and reconnection timestamp.

[0092] The Bluetooth link disconnection and reconnection event includes a disconnection event and a reconnection event. Therefore, when a disconnection event occurs, the corresponding disconnection timestamp is recorded, and when a reconnection event occurs, the corresponding reconnection timestamp is recorded.

[0093] S504: Based on the disconnection timestamp and reconnection timestamp, retrieve the corresponding second audio data from the terminal buffer and send it to the headset to answer the call.

[0094] The second audio data includes voice data transmitted to the user by the person in the call during the time the Bluetooth link disconnects and reconnects.

[0095] It should be noted that the second audio data is determined by aligning the timestamps of the disconnection and reconnection with the timestamps of each call audio data point in the terminal buffer. In a possible implementation, the Bluetooth link disconnection and reconnection event time can be denoted as T_outage, the disconnection timestamp as T_disconnect, and the reconnection timestamp as T_reconnect. The relationship between the three can be T_outage = T_reconnect - T_disconnect. In this way, the corresponding second audio data can be retrieved from the terminal buffer based on T_outage.

[0096] Generally speaking, when a headset receives and answers a call, it essentially plays the audio data to the user through the headset's speaker.

[0097] Optionally, the process of retrieving the corresponding second audio data from the terminal buffer based on the disconnection timestamp and reconnection timestamp and sending it to the headset for call answering can be seen in the steps shown in Figures 7 and 8.

[0098] At the terminal, by monitoring the Bluetooth link status and using a second buffering mechanism, the terminal is prevented from switching to its own audio path during brief Bluetooth link disconnections, effectively preventing the leakage of call content. Furthermore, when an unstable Bluetooth link is detected, a circular buffer is used to cyclically overwrite old data, based on the terminal's buffer design, to save memory space. When a Bluetooth link disconnection and reconnection event occurs, the second audio data in the terminal buffer is processed quickly before processing the real-time call audio data. Combined with voice recognition, invalid call audio data is prevented from being written to the terminal buffer, compensating for communication delays during this event.

[0099] The processes shown in S501-S504 above, based on the second buffer mechanism, prevent the terminal from switching to the terminal's local audio path during the brief Bluetooth link disconnection period, effectively preventing the leakage of call content. By combining the disconnection timestamp and reconnection timestamp, the second audio data is obtained from the terminal buffer and sent to the headset for call answering, ensuring that the second audio data in the communication receiving state (i.e., the user answers through the headset) is not lost, thereby effectively protecting the call content during the brief Bluetooth disconnection period.

[0100] Figure 6 shows a sixth flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, applied to a terminal, and includes the following steps.

[0101] S601: After the second buffering mechanism is activated, speech recognition is performed on the call audio data received by the terminal in real time to determine the semantic state of the call audio data.

[0102] Among them, speech recognition is performed on the call audio data received by the terminal in real time to determine the semantic state of the call audio data. Based on the semantic state, semantically invalid call audio data such as silence, noise, and tail sounds can be identified.

[0103] S602: If the semantic state of the call audio data is invalid, write the call audio data to the terminal buffer is prohibited.

[0104] If the semantic state of the call audio data is invalid, the call audio data is considered to be semantically irrelevant and does not need to be written to the terminal cache, thus avoiding the occupation of the terminal cache space. It can also compensate for the delay of the subsequent second audio data and improve the data quality of the second audio data.

[0105] The processes shown in S601-S602 above can avoid writing invalid call audio data into the headset buffer based on the semantic state of the call audio data, thus saving buffer space in the headset buffer.

[0106] Figure 7 shows a seventh flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, applied to a terminal, and includes the following steps.

[0107] S701: Based on the disconnection timestamp and reconnection timestamp, retrieve the corresponding second audio data from the terminal buffer.

[0108] The terminal cache stores various call audio data and their corresponding timestamps. Based on the disconnection and reconnection timestamps, the corresponding second audio data can be retrieved from the terminal cache.

[0109] S702: Triggers the terminal to adjust the call answering rate.

[0110] The adjusted call answering speed is faster than the default call answering speed.

[0111] It should be noted that the call answering rate affects the playback rate of the voice transmitted by the caller to the user. That is, the faster the call answering rate, the faster the voice will be heard by the user. For example, if the default call answering rate is 1 and the adjusted call answering rate is 1.5, then the voice will be heard by the user at a rate 1.5 times faster.

[0112] It is understandable that the call answering rate is a configurable communication parameter in the terminal.

[0113] S703: Based on the adjusted call answering rate, send the second audio data to the headset to answer the call.

[0114] The terminal sends second audio data to the headset to answer the call based on the adjusted call answering rate, which speeds up the processing efficiency of the second audio data. In other words, the voice rate of the second audio data heard by the user is faster, so that the communication process of the second audio data catches up with the real-time progress and ensures the continuity of communication.

[0115] S704: After the second audio data is sent, the terminal is triggered to restore the call answering rate to the default call answering rate.

[0116] Specifically, after the first audio data is sent, a second signaling is sent to the terminal so that the terminal can restore the call sending rate to the default call sending rate. This means that the communication process has caught up with the real-time progress, so the call sending rate is restored to the default call sending rate, and subsequent communication returns to normal.

[0117] The process described in S701-S704 above triggers the terminal to send the second audio data to the headset to answer the call according to the adjusted call answering rate, so that the communication process of the second audio data catches up with the real-time progress. After the second audio data is sent, the terminal is triggered to restore the call answering rate to the default call answering rate, ensuring that subsequent communication returns to normal and effectively improving the continuity of communication.

[0118] Figure 8 shows the eighth flowchart of a communication method based on a brief Bluetooth disconnection provided in the application embodiment, which is applied to a terminal and includes the following steps.

[0119] S801: Based on the disconnection timestamp and reconnection timestamp, retrieve the corresponding second audio data from the terminal buffer.

[0120] Specifically, by aligning the disconnection and reconnection timestamps with the timestamps in the terminal buffer, the corresponding second audio data can be determined.

[0121] S802: After sending the second audio data to the headset to answer the call, clear the terminal buffer and send the newly received call audio data to the headset to answer the call.

[0122] The process prioritizes sending the second audio data to the headset for call answering, ensuring that the call audio data during the Bluetooth link disconnection and reconnection event can be delivered to the user, thus ensuring communication continuity. Then, the terminal buffer is cleared to prevent the second audio data from occupying the terminal's buffer space, and the newly received call audio data is sent to the headset for call answering, restoring normal communication. The entire process is seamless for both the user and the caller, effectively improving the user experience of Bluetooth communication.

[0123] The processes shown in S801-S802 above achieve a smooth transition during the Bluetooth link disconnection and reconnection event, ensuring the continuity of Bluetooth communication and effectively improving the user experience of Bluetooth communication.

[0124] Figure 9 shows a schematic diagram of the architecture of a communication system provided in an embodiment of this application. The communication system includes a Bluetooth headset 100 and a terminal device 200.

[0125] In the communication transmission state, the Bluetooth headset 100 is used to: determine the state of the Bluetooth link between the terminal device 200 and the Bluetooth headset 100 based on Bluetooth signal parameters; when the Bluetooth link state is unstable, activate the first buffering mechanism; the first buffering mechanism is used to write the user audio data collected by the Bluetooth headset 100 in real time and the corresponding timestamp into the headset buffer area; the user audio data includes the voice data conveyed by the user to the call recipient; the headset buffer area includes a preset circular buffer in the local memory of the Bluetooth headset 100; when a Bluetooth link disconnection and reconnection event occurs, record the corresponding disconnection timestamp and reconnection timestamp; according to the disconnection timestamp and reconnection timestamp, retrieve the corresponding first audio data from the headset buffer area and send it to the terminal device 200 for call transmission; the first audio data includes the voice data conveyed by the user to the call recipient during the Bluetooth link disconnection and reconnection event.

[0126] Optionally, the Bluetooth headset 100 is also used to: after the first caching mechanism is started, perform speech recognition on the user audio data collected in real time by the Bluetooth headset 100 to determine the semantic state of the user audio data; if the semantic state of the user audio data is invalid, prohibit writing the user audio data to the headset buffer area.

[0127] Optionally, the Bluetooth headset 100 is specifically used to: obtain corresponding first audio data from the headset's buffer based on the disconnection and reconnection timestamps; send a first signaling to the terminal device 200 to cause the terminal device 200 to adjust the call transmission rate; wherein the adjusted call transmission rate is faster than the default call transmission rate; send the first audio data to the terminal device 200 so that the terminal device 200 transmits the first audio data according to the adjusted call transmission rate; and after the first audio data is transmitted, send a second signaling to the terminal device 200 so that the terminal device 200 restores the call transmission rate to the default call transmission rate.

[0128] Optionally, the Bluetooth headset 100 is specifically used to: obtain the corresponding first audio data from the headset buffer based on the disconnection timestamp and reconnection timestamp; after sending the first audio data to the terminal device 200 for call transmission, clear the headset buffer and send the newly collected user audio data currently acquired by the Bluetooth headset 100 to the terminal device 200 for call transmission.

[0129] In the communication receiving state, the terminal device 200 is used to: determine the state of the Bluetooth link between the Bluetooth headset 100 and the terminal device 200 based on Bluetooth signal parameters; when the Bluetooth link state is unstable, activate the second buffering mechanism; the second buffering mechanism is used to write the call audio data received by the terminal device 200 in real time and the corresponding timestamp into the terminal buffer area; the call audio data includes the voice data conveyed by the call subject to the user; the terminal buffer area includes a preset circular buffer in the local memory of the terminal device 200; when a Bluetooth link disconnection and reconnection event occurs, record the corresponding disconnection timestamp and reconnection timestamp; according to the disconnection timestamp and reconnection timestamp, retrieve the corresponding second audio data from the terminal buffer area and send it to the Bluetooth headset 100 to answer the call; the second audio data includes the voice data conveyed by the call subject to the user during the Bluetooth link disconnection and reconnection event.

[0130] Optionally, the terminal device 200 is also used to: after starting the second caching mechanism, perform speech recognition on the call audio data received by the terminal device 200 in real time to determine the semantic state of the call audio data; if the semantic state of the call audio data is invalid, prohibit writing the call audio data into the terminal cache area.

[0131] Optionally, the terminal device 200 is specifically used to: obtain the corresponding second audio data from the terminal buffer based on the disconnection timestamp and reconnection timestamp; trigger the terminal device 200 to adjust the call answering rate; wherein the adjusted call answering rate is faster than the default call answering rate; send the second audio data to the Bluetooth headset 100 to answer the call based on the adjusted call answering rate; and after the second audio data is sent, trigger the terminal device 200 to restore the call answering rate to the default call answering rate.

[0132] Optionally, the terminal device 200 is specifically used to: obtain the corresponding second audio data from the terminal buffer based on the disconnection timestamp and the reconnection timestamp; after sending the second audio data to the Bluetooth headset 100 to answer the call, clear the terminal buffer and send the new call audio data currently received by the terminal device 200 to the Bluetooth headset 100 to answer the call.

[0133] In some examples, the communication system relies on the collaborative work of the terminal device 200 and the Bluetooth headset 100. By establishing corresponding voice data buffers at both ends of the terminal device 200 and the Bluetooth headset 100, and performing precise timestamp alignment and data compensation when the Bluetooth link is disconnected and reconnected, the continuity and integrity of communication can be ensured without increasing hardware costs, fundamentally eliminating the loss of words or information caused by instantaneous fluctuations.

[0134] In some examples, the information interaction process between the terminal device 200 and the Bluetooth headset 100 described above can be summarized as shown in Figure 10.

[0135] In some examples, the module architecture of the terminal device 200 and the Bluetooth headset 100 can be seen in Figure 11.

[0136] For example, the terminal device 200 includes a main control module, an audio I / O module, and a terminal buffer. The main control module is responsible for monitoring Bluetooth signal parameters, determining the mode, and controlling the global buffer. The audio I / O module is responsible for acquiring voice data from the terminal microphone and outputting voice data to the terminal speaker. The terminal buffer is a circular buffer allocated in the terminal's memory, used to buffer call audio data to be sent to the Bluetooth headset during communication reception.

[0137] For example, the Bluetooth headset 100 includes a headset control module, a headset buffer, a headset microphone, and a headset speaker. The headset control module monitors Bluetooth signal parameters and manages the headset buffer, which is a circular buffer opened in the Bluetooth headset's memory to cache user audio data collected from the headset microphone and about to be sent to the terminal device 200 during communication transmission.

[0138] In some examples, the overall execution process of the communication system can be summarized as the steps shown in Figure 12: When the Bluetooth signal strength is detected to weaken to a preset threshold, the terminal receive buffer (equivalent to the second buffer mechanism) and the headset transmit buffer (equivalent to the first buffer mechanism) are activated; when the Bluetooth link is detected to be disconnected, the disconnection timestamp is recorded; when the Bluetooth link is detected to be reconnected, the reconnection timestamp is recorded; the disconnection timestamp and the reconnection timestamp are aligned with the timestamps in the terminal buffer and the headset buffer to determine the first audio data and the second audio data; the first audio data and the second audio data are processed first; the terminal buffer and the headset buffer are cleared, and the communication system resumes normal Bluetooth communication.

[0139] In a possible implementation, assuming that in the communication system, the walkie-talkie equipped with a Bluetooth module is terminal A, the Bluetooth headset paired with terminal A is Bluetooth device M, and the walkie-talkie that makes voice calls with terminal A is terminal B, the size of the circular buffer cache in the memory of terminal A and Bluetooth device M is set to 3 seconds (that is, to cache 3 seconds of voice data), the Bluetooth signal threshold is set to -90dBm, and the trigger condition corresponding to the caching mechanism is that the Bluetooth signal parameter is less than -90dBm, the communication process in the communication system can be divided into 5 stages.

[0140] Phase 1, Normal Call Period: Specifically, during a call, when the Bluetooth signal parameters of terminal A and Bluetooth device M are less than -90dBm, terminal A saves the received call audio data to the terminal buffer, and Bluetooth device M saves the user audio data to the headset buffer. During the data saving process to the buffer, a corresponding high-precision timestamp is added to the data frame. Both the terminal buffer and the headset buffer save the data in chronological order, so that the latest written data overwrites the old data.

[0141] Phase 2, Bluetooth Link Disconnection Detection Period: Specifically, due to external interference, the signal quality of the Bluetooth link between terminal A and Bluetooth device M drops sharply, and the connection is broken. Terminal A's Bluetooth protocol stack reports the connection disconnection event to the audio management module. Terminal A and Bluetooth device M immediately confirm the Bluetooth link disconnection and immediately record the corresponding disconnection timestamp T_disconnect. The call audio data and user audio data they have processed continue to be written to their respective buffers.

[0142] Phase 3, Bluetooth link disconnection period: Specifically, the terminal buffer and the headphone buffer are designed as a continuous circular buffer. The circular buffer only stores valid audio data. Pauses between voices and invalid audio data that is not normal are not written to the circular buffer. This not only makes more efficient use of the buffer, but also compresses the time for faster playback of voice data (including the first audio data and the second audio data) during the disconnection period.

[0143] Phase Four, Bluetooth Link Reconnection and Data Compensation: Specifically, once the signal interference disappears, Bluetooth device M and terminal A automatically and successfully reconnect, recording the corresponding reconnection timestamp T_reconnect. The occurrence time of the Bluetooth link disconnection and reconnection event, T_outage = T_reconnect - T_disconnect, is calculated. All call audio data and user audio data generated within this timeframe, as well as a portion of the context data before the disconnection, are stored in the terminal buffer and headset buffer. Terminal A starts from the data frame with timestamp T_disconnect in the terminal buffer and quickly sends the second audio data accumulated during the disconnection period to Bluetooth device M for call answering. Simultaneously, Bluetooth device M also sends the first audio data accumulated during the disconnection period to terminal A for call transmission. The call transmission rate can be slightly faster than the default call transmission rate to catch up with the real-time communication progress as quickly as possible. After both the first and second audio data have been transmitted, terminal A immediately switches back to the call transmission rate and sends a signaling to Bluetooth device M to notify it to resume normal playback speed.

[0144] Phase 5, Normal Call Restoration: Voice capture, encoding, and Bluetooth transmission paths are fully restored to normal. The terminal buffer and headset buffer are restored to normal mode, that is, only the most recent short period of data (such as 300ms) is retained for jitter buffering, or a 3-second capacity is retained in preparation for the next disconnection.

[0145] In summary, terminal A successfully transformed a potential 3-second communication interruption into a virtually imperceptible "voice supplementation" experience for the user. When using Bluetooth device M, the user might experience a slight delay in sound before it quickly returned to normal, and would hear some key information from before the disconnection, thus ensuring the continuity of communication and the integrity of semantics, fundamentally eliminating the "dropped words" problem.

[0146] The communication system described above has the following advantages: (1) Low cost: It is implemented entirely through software and does not require hardware upgrades; (2) High efficiency: It can effectively compensate for voice loss caused by brief disconnection and greatly improve the reliability in critical communication scenarios; (3) Seamless experience: Through intelligent data compensation and silent discarding mechanism, it realizes a smooth transition during the Bluetooth link disconnection and reconnection process, and the user experience is continuous; (4) Flexible and configurable: Users can adjust the Bluetooth signal threshold, terminal buffer size, and headphone buffer size according to environmental sensitivity and needs.

[0147] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0148] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A communication method based on Bluetooth temporary disconnection, characterized in that, The method, applied to a headset, includes: determining the state of the Bluetooth link between the terminal and the headset based on Bluetooth signal parameters; activating a first caching mechanism when the Bluetooth link state is unstable; the first caching mechanism is used to write the user audio data collected in real time by the headset and the corresponding timestamp into the headset's buffer area; the user audio data includes voice data conveyed by the user to the call recipient; the headset buffer area includes a preset circular buffer in the headset's local memory; when a Bluetooth link disconnection and reconnection event occurs, recording the corresponding disconnection timestamp and reconnection timestamp; retrieving corresponding first audio data from the headset buffer area according to the disconnection timestamp and reconnection timestamp, and sending it to the terminal for call transmission; the first audio data includes the voice data conveyed by the user to the call recipient during the Bluetooth link disconnection and reconnection event.

2. The method according to claim 1, characterized in that, The method further includes: after activating the first caching mechanism, performing speech recognition on the user audio data collected in real time by the headset to determine the semantic state of the user audio data; if the semantic state of the user audio data is invalid, prohibiting the writing of the user audio data into the headset cache area.

3. The method according to claim 1, characterized in that, Based on the disconnection timestamp and the reconnection timestamp, the corresponding first audio data is retrieved from the headset buffer and sent to the terminal for call transmission, including: retrieving the corresponding first audio data from the headset buffer based on the disconnection timestamp and the reconnection timestamp; sending a first signaling to the terminal to cause the terminal to adjust the call transmission rate; wherein the adjusted call transmission rate is faster than the default call transmission rate; sending the first audio data to the terminal to cause the terminal to transmit the first audio data for call transmission according to the adjusted call transmission rate; and after the first audio data transmission is completed, sending a second signaling to the terminal to cause the terminal to restore the call transmission rate to the default call transmission rate.

4. The method according to claim 1, characterized in that, Based on the disconnection timestamp and the reconnection timestamp, the corresponding first audio data is obtained from the headset buffer and sent to the terminal for call transmission, including: obtaining the corresponding first audio data from the headset buffer based on the disconnection timestamp and the reconnection timestamp; firstly sending the first audio data to the terminal for call transmission, then clearing the headset buffer and sending the newly collected user audio data from the headset to the terminal for call transmission.

5. A communication method based on Bluetooth temporary disconnection, characterized in that, The method, applied to a terminal, includes: determining the state of the Bluetooth link between the headset and the terminal based on Bluetooth signal parameters; activating a second caching mechanism when the Bluetooth link state is unstable; the second caching mechanism is used to write the real-time call audio data received by the terminal and the corresponding timestamp into the terminal cache area; the call audio data includes voice data conveyed by the call subject to the user; the terminal cache area includes a preset circular buffer in the terminal's local memory; when a Bluetooth link disconnection and reconnection event occurs, recording the corresponding disconnection timestamp and reconnection timestamp; retrieving corresponding second audio data from the terminal cache area according to the disconnection timestamp and reconnection timestamp, and sending it to the headset for call answering; the second audio data includes voice data conveyed by the call subject to the user within the time of the Bluetooth link disconnection and reconnection event.

6. The method according to claim 5, characterized in that, The method further includes: after activating the second caching mechanism, performing speech recognition on the call audio data received by the terminal in real time to determine the semantic state of the call audio data; if the semantic state of the call audio data is invalid, prohibiting the writing of the call audio data into the terminal cache area.

7. The method according to claim 5, characterized in that, Based on the disconnection timestamp and the reconnection timestamp, the corresponding second audio data is retrieved from the terminal buffer and sent to the headset for call answering, including: retrieving the corresponding second audio data from the terminal buffer based on the disconnection timestamp and the reconnection timestamp; triggering the terminal to adjust the call answering rate; wherein the adjusted call answering rate is faster than the default call answering rate; sending the second audio data to the headset for call answering based on the adjusted call answering rate; and after the second audio data is sent, triggering the terminal to restore the call answering rate to the default call answering rate.

8. The method according to claim 5, characterized in that, Based on the disconnection timestamp and the reconnection timestamp, the corresponding second audio data is retrieved from the terminal buffer and sent to the headset for call answering, including: retrieving the corresponding second audio data from the terminal buffer based on the disconnection timestamp and the reconnection timestamp; first sending the second audio data to the headset for call answering, then clearing the terminal buffer and sending the newly received call audio data from the terminal to the headset for call answering.

9. A Bluetooth headset, characterized in that, The Bluetooth headset is used to perform the communication method based on temporary Bluetooth disconnection as described in any one of claims 1-4.

10. A terminal device, characterized in that, The terminal device is used to execute the communication method based on Bluetooth temporary disconnection as described in any one of claims 5-8.

Images