Audio data processing method, system, electronic device and program product

Abstract

The present disclosure provides an audio data processing method, system, electronic device and program product. The audio data processing method of the present disclosure is applied to a second device, comprising: establishing a first connection with a first device; receiving audio data sent by the first device according to the first connection, the audio data being collected by the first device for environmental sound or conversation sound; storing the audio data to a local storage space; and sending the stored audio data to a network side for storage.

Description

Technical Field

[0001] This disclosure relates to an audio data processing method, system, electronic device, and program product. Background Technology

[0002] With the rapid development of smart wearable devices, recording has become an important function of Bluetooth communication devices, in addition to audio playback. However, current technology limits the storage capacity of Bluetooth communication devices used for recording due to size and power consumption constraints, making it difficult to support long-term recording needs. Furthermore, there is a considerable waiting time after recording to transfer the file to the terminal, resulting in low transmission efficiency. Summary of the Invention

[0003] This disclosure provides an audio data processing method, system, electronic device, and program product.

[0004] According to one aspect of this disclosure, an audio data processing method is provided, applied to a second device, the method comprising: establishing a first connection with a first device; receiving audio data sent by the first device according to the first connection, the audio data being collected by the first device for ambient sound or call audio; storing the audio data in local storage space; and sending the stored audio data to a network side for storage.

[0005] According to one technical solution, by separating the audio acquisition and data processing functions, with the first device focusing on audio acquisition and the second device responsible for data storage and synchronization, not only is the recording time greatly extended, but the transmission efficiency of audio data is also improved.

[0006] According to at least one embodiment of the audio data processing method of this disclosure, the stored audio data is sent to the network side for storage, including: sending the stored audio data to the cloud server for storage based on a second connection with the cloud server; if the second connection is unavailable, sending the stored audio data to the mobile terminal based on a third connection with the mobile terminal, and the mobile terminal sending the audio data to the cloud server for storage based on a fourth connection with the cloud server.

[0007] According to the technical solution of this embodiment, through the dual-path synchronization mechanism, even if the second device is not directly connected to the cloud server, data synchronization can still be completed through the mobile terminal, avoiding the risk of data loss due to network problems and significantly improving the reliability and continuity of data synchronization.

[0008] The audio data processing method according to at least one embodiment of the present disclosure further includes: updating the synchronization status identifier of the transmitted audio data, the synchronization status identifier including unsynchronized or synchronized; and transmitting the audio data in the second device whose synchronization status identifier is unsynchronized to the network side.

[0009] According to the technical solution of this embodiment, through the synchronization status identification mechanism, the system can accurately track the transmission status of each audio data, ensure that all audio data is successfully synchronized to the network side, avoid data loss due to network interruption or transmission failure, and improve the reliability of data synchronization.

[0010] The audio data processing method according to at least one embodiment of the present disclosure further includes: during the transmission of audio data to a mobile terminal, if a third connection is disconnected, sending a first reconnection request to the mobile terminal, the first reconnection request being used to instruct the third connection to be re-established with the mobile terminal; in response to a first interruption resume instruction sent by the mobile terminal, continuing to transmit audio data to the mobile terminal based on the re-established third connection, the first interruption resume instruction being used to instruct a second device to continue transmission according to the interruption position of the latest audio data in the mobile terminal.

[0011] According to the technical solution of this embodiment, the interrupted transmission mechanism can ensure the complete transmission of audio data even in environments with unstable Bluetooth connections or severe signal interference, avoiding transmission failure and data loss caused by connection interruption, and significantly improving the reliability of data transmission.

[0012] According to at least one embodiment of the audio data processing method of this disclosure, receiving audio data sent by a first device according to a first connection includes: detecting the occurrence of a first operation event indicating the start of recording, sending a status query request to the first device, and having the first device provide feedback on its own working status according to the status query request; when the first device is in a target working state, starting a recording mode and receiving audio data sent by the first device according to the first connection.

[0013] According to the technical solution of this embodiment, the recording function is activated when the first device is in a suitable state through a status query mechanism, thereby avoiding recording failure due to an unsuitable device state.

[0014] An audio data processing method according to at least one embodiment of the present disclosure further includes: during the process of receiving audio data transmitted by a first device, if a first connection is broken, receiving a second reconnection request sent by the first device; re-establishing the first connection with the first device according to the second reconnection request; after determining that the first device is still in the target working state, sending a second breakpoint resumption instruction to the first device, the second breakpoint resumption instruction being used to instruct the first device to continue transmission according to the transmission interruption position of the latest audio data in the second device; and receiving audio data that the first device continues to transmit according to the second breakpoint resumption instruction according to the re-established first connection.

[0015] According to the technical solution of this embodiment, the interrupted transmission mechanism can ensure the complete transmission of audio data between the first and second devices even in environments with unstable Bluetooth connections or severe signal interference, avoiding transmission failure and data loss caused by connection interruption, and significantly improving the reliability of data transmission.

[0016] The audio data processing method according to at least one embodiment of the present disclosure further includes: when a second operation event is detected, sending a recording control command to a first device, the recording control command being used to instruct the first device to pause or resume recording; and receiving the working status fed back by the first device after executing the recording control command.

[0017] According to the technical solution of this embodiment, through precise command control, the system can accurately control the start, pause and resume of recording, ensuring that the recording process meets the user's needs and avoiding recording errors caused by misoperation or system delay.

[0018] The audio data processing method according to at least one embodiment of the present disclosure further includes: when a third operation event is detected, sending a recording stop command to a first device, and the first device stopping recording according to the recording stop command; continuing to receive audio data being transmitted by the first device until the audio data being transmitted is completed.

[0019] According to the technical solution of this embodiment, all audio data before the user stops recording can be completely saved, avoiding the problem of recording data loss due to immediate disconnection.

[0020] According to at least one embodiment of the audio data processing method of this disclosure, after continuing to receive audio data being transmitted by the first device until the audio data being transmitted is completed, the method further includes: obtaining a first audio data list of the first device, the first audio data list including relevant information of audio data already stored by the first device; comparing the first audio data list with a second audio data list of the second device to determine target audio data that the first device has not yet transmitted, the second audio data list including relevant information of audio data already stored by the second device; sending a transmission instruction to the first device to instruct the transmission of the target audio data, and receiving the target audio data transmitted by the first device according to the transmission instruction.

[0021] According to the technical solution of this embodiment, by periodically comparing the audio data list, any audio data that may be missed can be detected and transmitted in a timely manner, avoiding data loss due to transmission interruption or abnormality, and ensuring the integrity and reliability of the recording data.

[0022] According to one aspect of this disclosure, an audio data processing system is provided, comprising: a first device for acquiring ambient sound or call audio; a second device for performing the audio data processing method as described in any of the above embodiments; and a network side for receiving and storing audio data transmitted by the second device.

[0023] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform a method according to any embodiment of this disclosure.

[0024] According to another aspect of this disclosure, a readable storage medium is provided that stores executable instructions, which, when executed by a processor, are used to implement the method of any embodiment of this disclosure.

[0025] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a method according to any embodiment of this disclosure. Attached Figure Description

[0026] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0027] Figure 1 A schematic diagram of the framework of an audio data processing system according to one embodiment of the present disclosure is shown.

[0028] Figure 2A schematic flowchart of an audio data processing method according to one embodiment of the present disclosure is shown.

[0029] Figure 3 A flowchart illustrating step S240 of an audio data processing method according to one embodiment of the present disclosure is shown.

[0030] Figure 4 A flowchart illustrating the updating of a synchronization status identifier is shown in an audio data processing method according to one embodiment of the present disclosure.

[0031] Figure 5 A schematic diagram of the process of reconnecting a second device to a mobile terminal is shown in an audio data processing method according to one embodiment of the present disclosure.

[0032] Figure 6 A flowchart illustrating step S220 of an audio data processing method according to one embodiment of the present disclosure is shown.

[0033] Figure 7 A schematic diagram of the reconnection process between a first device and a second device is shown in an audio data processing method according to one embodiment of the present disclosure.

[0034] Figure 8 A schematic flowchart illustrating a recording state control component further included in an audio data processing method according to one embodiment of the present disclosure is shown.

[0035] Figure 9 A schematic diagram of a process for stopping recording is shown in an audio data processing method according to one embodiment of the present disclosure.

[0036] Figure 10 A schematic flowchart illustrating a file comparison process in an audio data processing method according to an embodiment of the present disclosure, including a first device and a second device, is shown.

[0037] Figure 11 A schematic flowchart of an audio data processing method according to another embodiment of the present disclosure is shown.

[0038] Figure 12 A schematic flowchart illustrating the reconnection process between a first device and a second device in an audio data processing method according to another embodiment of the present disclosure is shown.

[0039] Figure 13 A schematic diagram of the reconnection process between a second device and a mobile terminal in an audio data processing method according to another embodiment of the present disclosure is shown.

[0040] Figure 14A schematic flowchart illustrating recording state control in an audio data processing method according to another embodiment of the present disclosure is shown.

[0041] Figure 15 A schematic diagram of the process of stopping recording is shown in an audio data processing method according to another embodiment of the present disclosure.

[0042] Figure 16 A schematic diagram of the interaction between a mobile terminal and a second device after recording ends is shown in an audio data processing method according to one embodiment of the present disclosure.

[0043] Figure 17 A schematic diagram of the process of a mobile terminal interacting with a second device using a Wi-Fi hotspot after recording ends is shown in another embodiment of the audio data processing method according to this disclosure.

[0044] Figure 18 A schematic diagram of the process of interaction between a second device and the cloud after recording ends is shown in an audio data processing method according to one embodiment of the present disclosure.

[0045] Figure 19 A schematic structural block diagram of an electronic device according to one embodiment of the present disclosure is shown. Detailed Implementation

[0046] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0047] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0048] With the rapid development of smart wearable devices, Bluetooth headsets and other devices have evolved from simple audio playback tools into multifunctional smart terminals. Recording functionality has become an important application scenario for Bluetooth headsets, including meeting minutes, voice memos, and call recording.

[0049] Currently, Bluetooth headset recording systems on the market mainly adopt the following two technical solutions:

[0050] The first approach is to distribute the recording function across multiple devices. For example, call recordings can be stored in the earphone itself, while ambient recordings can be stored in the charging case. While this approach alleviates the storage pressure on a single device to some extent, it results in fragmented storage of recording files, making user management inconvenient. Furthermore, the earphone's storage space remains limited, making it unsuitable for long-duration call recordings.

[0051] The second approach is to integrate all recording functions into the earphone itself. However, due to the strict limitations of earphone size and power consumption, even with this approach, the earphone's storage capacity is small, making it difficult to meet the needs of long-term recording. Furthermore, the limited internal space of the earphone makes it difficult to integrate high-speed transmission modules such as Wi-Fi, resulting in the export of recorded files relying entirely on Bluetooth transmission. This leads to slow transfer speeds, requiring users to wait several hours after recording to transfer files to their phones, severely impacting the user experience.

[0052] To this end, the present disclosure proposes the following technical solution, in which the audio acquisition and data processing functions are separated, with the first device focusing on audio acquisition and the second device responsible for data storage and synchronization, which not only greatly extends the recording time but also improves the transmission efficiency of audio data.

[0053] Figure 1 A schematic diagram of the framework of an audio data processing system according to one embodiment of the present disclosure is shown.

[0054] like Figure 1 As shown, the audio data processing system may include a first device 110, a second device 120, and a network side 130.

[0055] Specifically, the first device 110, acting as an audio acquisition terminal, has the core function of acquiring and initially processing audio signals. In one example, the first device 110 may include an audio acquisition module, a classic Bluetooth module 113, and a Bluetooth Low Energy (BLE) module 114. The audio acquisition module may include a microphone array 111 and an audio processing chip 112 (such as an audio encoder) for acquiring ambient sound or call audio, supporting high-fidelity and noise reduction processing. The classic Bluetooth module 113 can be used to connect to external devices such as smartphones (such as mobile terminal 132) for calls or music playback. The Bluetooth Low Energy module 114 can be used to establish a dedicated data connection channel with the second device 120 to transmit the acquired audio data stream in real time.

[0056] The second device 120 serves as the core data processing and transmission hub of the system. In one example, the second device 120 may include a main control chip 121, a large-capacity memory 122, a dual-mode Bluetooth module 123, and a wireless communication module 124.

[0057] Among them, the main control chip 121 is responsible for system coordination and control, and is used to handle tasks such as receiving, storing and synchronizing audio data streams.

[0058] The mass storage device 122 can be used to store all audio data received from the first device 110. Optionally, the mass storage device 122 can have 32GB or more of memory to ensure its storage capacity.

[0059] The dual-mode Bluetooth module 123 enables the second device 120 to establish a connection with the first device 110 as a Bluetooth host to receive audio data, and can also establish a connection with the mobile terminal 132 as a Bluetooth slave for device pairing, command issuance, and data synchronization.

[0060] The wireless communication module 124 may include a Wi-Fi module and / or a cellular mobile network module, which can be used to synchronize stored audio data at high speed to the network side 130 for storage.

[0061] The network side 130 is used to receive and store audio data synchronized from the second device 120, enabling audio data backup, multi-device synchronization, and remote access. In one example, the network side 130 may include a cloud server 131 and a mobile terminal 132 (which may be configured with a corresponding terminal APP). The cloud server 131 can provide high-capacity, highly reliable remote storage services, supporting data backup, multi-device synchronization, and remote access. The APP on the mobile terminal 132 can provide an interface for interacting with the system, offering functions such as audio data management, playback, and sharing.

[0062] In one embodiment, the second device can receive audio data sent by the first device based on a first connection with the first device. This audio data may be collected by the first device for ambient sound or call audio. The second device can then store the received audio data in its local storage space and send the stored audio data to the network side for storage.

[0063] Figure 2 A schematic flowchart of an audio data processing method according to one embodiment of the present disclosure is shown. Figure 2 As shown, the audio data processing method may include steps S210 to S240. This method may be performed by, for example... Figure 1 The second device 120 shown is executed.

[0064] In step S210, a first connection is established with the first device.

[0065] The first device can be an electronic device for audio acquisition, which may include, but is not limited to, any one of in-ear headphones, headphones, neckband headphones, lavalier microphones, or other wearable audio acquisition devices.

[0066] The second device can be an electronic device that serves as a data hub, which may include, but is not limited to, any one of the following: a smart charging case for headphones, a standalone portable communication hub, or a smartphone companion device.

[0067] The first connection can be a dedicated data connection channel established between the first device and the second device. In one example, the first connection can be a Bluetooth Low Energy (BLE) connection, which is dedicated to audio data transmission to avoid interference with other Bluetooth communications.

[0068] In this embodiment, the second device, acting as a Bluetooth host, can proactively initiate a connection request to the first device via its dual-mode Bluetooth module. This request may include the second device's device identifier, authentication information, or connection parameters, thereby ensuring the legitimacy and security of the connection. Upon receiving the connection request, the first device can authenticate the second device, such as verifying device pairing information and authentication keys. Only the authenticated second device can establish a connection to ensure the security of data transmission. After both parties complete pairing and authentication, a dedicated Bluetooth Low Energy data connection channel (i.e., the first connection) is established.

[0069] Thus, by establishing a dedicated low-power Bluetooth data connection channel, interference with other Bluetooth devices is avoided, ensuring the stability and real-time performance of audio data transmission and laying the foundation for subsequent efficient data transmission. Furthermore, this connection mechanism is applicable to various combinations of first and second devices, such as earphones and charging cases, earphones and independent portable data boxes, lavalier microphones and smart terminals, etc., demonstrating excellent system compatibility and scalability.

[0070] In step S220, according to the first connection, audio data sent by the first device is received, wherein the audio data is collected by the first device for ambient sound or call audio.

[0071] In this embodiment, in recording mode, the first device can collect ambient sound or call audio through its built-in microphone array to obtain corresponding audio data. Then, the first device can transmit the collected audio data to the second device in real time through the established first connection. The second device can then receive the audio data sent by the first device and perform subsequent processing.

[0072] In one example, during audio data acquisition, the first device converts the analog audio signal into a digital signal using an analog-to-digital converter and performs preprocessing such as noise reduction and gain adjustment. Then, it encapsulates the signal into data packets according to the BLE protocol standard. During encapsulation, the first device can add metadata such as timestamps, sequence numbers, and checksums to each data packet to ensure the traceability and integrity of data transmission.

[0073] In one example, during audio data transmission, BLE 5.0 or a higher version protocol can be used, supporting a transmission rate of 2 Mbps, a data packet size of 244 bytes, and a transmission frequency of 1000 Hz, thereby ensuring the real-time and continuous nature of the audio data. The first device can also dynamically adjust the transmission power and audio data packet size based on feedback from the second device, thereby optimizing transmission efficiency and reducing power consumption.

[0074] In this way, the first device does not need to handle data storage and high-speed transmission; it focuses on audio data acquisition, optimizing device design, reducing power consumption, and extending battery life. Meanwhile, the second device, acting as the data hub, can efficiently process large amounts of data, achieving large-capacity storage and allowing recording time to break through the physical limitations of traditional headphones.

[0075] In step S230, the audio data is stored in local storage space.

[0076] The local storage space can be the storage location used by the second device to store audio data, for example... Figure 1 The aforementioned large-capacity memory.

[0077] In this embodiment, the second device can write the received audio data into local storage space (i.e., mass storage) after preliminary processing and formatting (i.e., conversion into a standard audio file format).

[0078] In one example, the second device can monitor the usage of local storage space in real time. When the storage space usage exceeds a certain threshold (e.g., 90%), it can activate a storage space management mechanism. This mechanism may include, but is not limited to: prioritizing the deletion of the oldest stored audio data, retaining high-priority audio data (such as audio data marked as important), or notifying the user of insufficient storage space and providing cleanup suggestions.

[0079] In this way, by storing audio data in the large-capacity memory of the second device, the problem of insufficient storage space caused by the size limitation of the first device (such as headphones) is eliminated, and the recording time is greatly extended.

[0080] In step S240, the stored audio data is sent to the network side for storage.

[0081] The network side can be a remote storage node, which may include a cloud server and / or a mobile terminal, for receiving and storing audio data synchronized from the second device.

[0082] In this embodiment, the second device can determine the audio data to be synchronized and determine the synchronization target type according to preset rules. The synchronization target can be a cloud server, a mobile terminal, or other network storage services. After determining the synchronization target type, the second device can send the audio data to the corresponding synchronization target. After receiving the audio data, the network side can store it, thereby realizing audio data backup, multi-device synchronization, and remote access.

[0083] Thus, based on Figure 2 The implementation shown separates audio acquisition from data processing, with the first device focusing on audio acquisition and the second device responsible for data storage and synchronization. This not only significantly extends the recording time but also improves the transmission efficiency of audio data.

[0084] Regarding step S240, in some embodiments of this disclosure, step S240 may include, for example... Figure 3 Steps S241 and S242 are shown.

[0085] In step S241, the stored audio data is sent to the cloud server for storage based on the second connection with the cloud server.

[0086] The second connection can be a direct network connection between the second device and the cloud server, which can be a Wi-Fi connection or a cellular network connection, used to synchronize audio data to the cloud server at high speed and directly.

[0087] In this embodiment, the second device can monitor the network connection status between itself and the cloud server, such as Wi-Fi signal strength, cellular network availability, and network quality. When a stable network connection and sufficient bandwidth are detected, the second connection is determined to be available.

[0088] The second device can establish a secure, encrypted connection with the cloud server via its built-in Wi-Fi or cellular network module. During the connection process, the second device can verify the cloud server's authentication information to ensure the security of data transmission. Then, the second device can send the audio data to be synchronized to the cloud server for storage through the second connection.

[0089] In step S242, if the second connection is unavailable, the stored audio data is sent to the mobile terminal based on the third connection with the mobile terminal, and the mobile terminal sends the audio data to the cloud server for storage based on the fourth connection with the cloud server.

[0090] The third connection can be a network connection between the second device and the mobile terminal, which can be a Bluetooth connection. In one example, the third connection can be a BLE connection between the second device and the mobile terminal, which has a lower transmission rate but lower power consumption.

[0091] The fourth connection can be a network connection between the mobile terminal and the cloud server, which can be a Wi-Fi connection or a cellular mobile network connection, used to further synchronize the audio data received from the second device to the cloud server.

[0092] In this implementation, when the second device detects that its second connection with the cloud server is unavailable (e.g., weak Wi-Fi signal, unavailable cellular network, or network congestion), it can activate a backup synchronization scheme. Specifically, the second device can establish a Bluetooth connection (i.e., a third connection) with the mobile terminal via a dual-mode Bluetooth module. During the connection process, the second device can verify the legitimacy of the mobile terminal, ensuring that only authorized devices can receive audio data. The second device transmits the stored audio data to the mobile terminal via the Bluetooth connection. After receiving the audio data, the mobile terminal can check its network connection status with the cloud server. It should be understood that mobile terminals typically have more stable network connectivity, and even if the second device's network conditions are poor, the mobile terminal may still have a usable network connection.

[0093] When the mobile terminal detects that a network connection to the cloud server (i.e., the fourth connection) is available, it can upload the received audio data to the cloud server for storage through the fourth connection.

[0094] In one example, after receiving the audio data, the cloud server can perform an integrity check and return a confirmation message. Upon receiving this confirmation message, the mobile terminal or a second device can mark the audio data as "synchronized".

[0095] Thus, through the dual-path synchronization mechanism, even if the second device is unavailable to directly connect to the cloud server, data synchronization can still be completed through the mobile terminal, avoiding the risk of data loss due to network problems and significantly improving the reliability and continuity of data synchronization.

[0096] In some embodiments of this disclosure, the audio data processing method may further include, for example: Figure 4 Steps S410 to S420 are shown.

[0097] In step S410, the synchronization status flag is updated for the audio data after transmission is complete.

[0098] The synchronization status identifier can be information used to indicate whether audio data has been successfully synchronized to the network side. It can be a flag bit or a metadata field. In one example, the synchronization status identifier can be a binary flag bit, where 0 indicates no synchronization and 1 indicates synchronization. In another example, the synchronization status identifier can also be a metadata record containing a transmission timestamp and synchronization confirmation information.

[0099] In this embodiment, after receiving the audio data transmitted by the first device, the second device can initialize the synchronization status flag of each audio data to "unsynchronized". During the transmission to the network side, the second device can monitor the transmission status of each audio data. When it detects that the transmission of a certain audio data is complete (such as receiving a synchronization confirmation message sent by the network side), the second device can immediately update the synchronization status flag of that audio data to "synchronized".

[0100] In step S420, audio data whose synchronization status is marked as unsynchronized in the second device is transmitted to the network side.

[0101] In this implementation, after the current audio data transmission is completed, the second device can detect the synchronization status flags of each audio data in the local storage space. If the synchronization status flag of any audio data is out of sync, the audio data can be transmitted to the network side to avoid missed transmission.

[0102] In this way, through the synchronization status identification mechanism, the system can accurately track the transmission status of each audio data, ensuring that all audio data is successfully synchronized to the network side, avoiding data loss due to network interruption or transmission failure, and improving the reliability of data synchronization.

[0103] In some embodiments of this disclosure, the audio data processing method may further include, for example: Figure 5 Steps S510 to S520 are shown.

[0104] In step S510, if the third connection is disconnected during the transmission of audio data to the mobile terminal, a first reconnection request is sent to the mobile terminal. The first reconnection request is used to indicate that the third connection with the mobile terminal should be re-established.

[0105] The first reconnection request can be information used to request the mobile terminal to re-establish the connection. This first reconnection request may include information such as the device identifier and the expected reconnection parameters.

[0106] In this embodiment, the second device can continuously monitor the Bluetooth connection status while transmitting audio data to the mobile terminal via the third connection. For example, it can determine whether the third connection is stable by periodically sending heartbeat packets or detecting the Bluetooth signal strength. If no response is received from the mobile terminal multiple times in a row or the signal strength is lower than a certain threshold, it can be determined that the third connection has been disconnected.

[0107] Once the third connection is determined to be broken, the second device can generate and send a first reconnection request to the mobile terminal. Upon receiving this first reconnection request, the mobile terminal can re-establish the third connection with the second device.

[0108] In step S520, in response to the first interruption resume instruction sent by the mobile terminal, audio data continues to be transmitted to the mobile terminal based on the re-established third connection. The first interruption resume instruction is used to instruct the second device to continue transmission according to the interruption position of the latest audio data in the mobile terminal.

[0109] The first breakpoint resumption instruction can be a command sent by the mobile terminal to the second device to indicate the position for resuming transmission. This first breakpoint resumption instruction may contain transmission interruption position information (such as byte offset or data block sequence number) of the latest audio data received in the mobile terminal.

[0110] In this embodiment, the mobile terminal can detect its own stored audio data and confirm the last position of the latest received audio data. Then, it generates a first resume transmission command containing this position information and sends it to the second device via a classic Bluetooth connection or a newly established third connection. Upon receiving the first resume transmission command, the second device can parse the transmission interruption position information and then resume transmitting the remaining audio data from that position.

[0111] Thus, through the breakpoint resume mechanism, complete audio data transmission can be guaranteed even in environments with unstable Bluetooth connections or severe signal interference, avoiding transmission failures and data loss caused by connection drops, significantly improving data transmission reliability. Furthermore, it avoids the retransmission of successfully transmitted data, reducing unnecessary data transfer and saving Bluetooth bandwidth and device power consumption.

[0112] Regarding step S220, in some embodiments of this disclosure, step S220 may include, for example: Figure 6 Steps S221 to S222 are shown.

[0113] In step S221, the occurrence of a first operation event indicating the start of recording is detected, and a status query request is sent to the first device, which then reports its own working status based on the status query request.

[0114] The first operation event can be an action that triggers the recording function. For example, the first operation event can be a recording start condition triggered by clicking the "Start Recording" button on a mobile terminal APP, a voice command, a physical button operation (such as clicking a physical button on a second device twice in succession), or a recording start condition triggered automatically by the system.

[0115] A status query request can be an instruction sent by a second device to a first device to query its current working status.

[0116] In this embodiment, the second device can continuously monitor command input from a mobile terminal APP or local control. When it detects that the user has triggered a first operation event, the second device can initiate the recording startup process. Specifically, the second device can generate a status query request and send it to the first device (e.g., via classic Bluetooth or BLE connection). The first device can check its own working status based on the received status query command, such as the connection status with the second device, the current microphone working status, remaining battery power, and whether there are other processing tasks. The first device can send the status check results as feedback information to the second device.

[0117] In step S222, when the first device is in the target working state, the recording mode is turned on and audio data sent by the first device is received according to the first connection.

[0118] The target working state can be a state in which the first device can perform recording, including but not limited to one or more of the following: the first device is in a call state, has established a connection with the second device, has no other tasks, has sufficient power, or has a normal microphone function.

[0119] In this embodiment, after receiving status feedback from the first device, the second device can verify whether it meets the target working state conditions. If it does, the second device can send a recording start command to the first device, which may include information such as the recording type (e.g., ambient sound or call audio).

[0120] Upon receiving the recording start command, the first device initiates the recording function and transmits the collected audio data to the second device via the first connection. The second device can also enter recording mode to receive audio data sent by the first device for subsequent processing.

[0121] In this way, the status query mechanism ensures that the recording function starts when the first device is in a suitable state, avoiding recording failures caused by unsuitable device status.

[0122] In some embodiments of this disclosure, the audio data processing method may further include, for example: Figure 7 Steps S710 to S740 are shown.

[0123] In step S710, if the first connection is broken during the process of receiving audio data transmitted by the first device, a second reconnection request sent by the first device is received.

[0124] The second reconnection request can be a request message used to re-establish a connection with the second device.

[0125] In this implementation, the first device can continuously monitor the first connection status with the second device to determine whether the first connection is available. When it is determined that the first connection is unavailable, the first device can generate a second reconnection request and send it to the second device. In one example, the second reconnection request may include information such as the device identifier and reconnection parameters of the first device, so that the second device can recognize the identity of the first device after receiving the second reconnection request.

[0126] In step S720, the first connection is re-established with the first device according to the second reconnection request.

[0127] In this implementation, the second device can send an acknowledgment response to the first device based on the information contained in the second reconnection request. The dedicated data connection channel (i.e., the first connection) can then be re-established via the BLE protocol. During the connection establishment process, the second device can verify the identity information of the first device to ensure that only authorized devices can establish a connection.

[0128] In step S730, after determining that the first device is still in the target working state, a second interruption resume instruction is sent to the first device. The second interruption resume instruction is used to instruct the first device to continue transmission according to the transmission interruption position of the latest audio data in the second device.

[0129] The second interruption resume instruction can be an instruction message used to indicate the position to continue transmission to the first device. The second interruption resume instruction can include the transmission interruption position information of the latest audio data received in the second device.

[0130] In this embodiment, the second device can send a status query command to the first device to confirm whether the first device is still in the target working state. Based on the status feedback information from the first device, if it is confirmed that the first device is still in the target working state, the second device can generate a second breakpoint resumption command. This second breakpoint resumption command may include the transmission interruption position of the latest audio data received in the second device. The second device can then send this second breakpoint resumption command to the first device.

[0131] In step S740, based on the re-established first connection, audio data transmitted by the first device according to the second breakpoint resume instruction is received.

[0132] In this embodiment, after receiving the second interruption resume command, the first device can parse the transmission interruption location information and resume transmitting the remaining audio data from that location through the re-established first connection. The second device can then continue receiving the remaining audio data sent by the first device to ensure the integrity of the audio data.

[0133] Thus, through the breakpoint resume mechanism, even in environments with unstable Bluetooth connections or severe signal interference, the complete transmission of audio data between the first and second devices can be guaranteed, avoiding transmission failures and data loss caused by connection drops, significantly improving data transmission reliability. Furthermore, it avoids the retransmission of successfully transmitted data, reducing unnecessary data transmission and saving Bluetooth bandwidth and device power consumption.

[0134] In some embodiments of this disclosure, the audio data processing method may further include, for example: Figure 8 Steps S810 to S820 are shown.

[0135] In step S810, when the second operation event is detected, a recording control command is sent to the first device, which is used to instruct the first device to pause or resume recording.

[0136] The second operation event can be a specific operation triggered by the user or the system to control the recording status. For example, it could be a recording status change request triggered by clicking the "pause recording" or "resume recording" button on a mobile app, a voice command, a physical button operation, or other preset conditions.

[0137] Recording control commands can be commands used to control changes in recording status. These commands can include information such as operation type (e.g., pause or resume), timestamp, or device identifier.

[0138] In this embodiment, when the second device detects a second operation event (which can be obtained by monitoring command input from a mobile terminal APP, local control, or automatically triggered by the system), it can generate a corresponding recording control command based on the detected operation event type. This command may include information such as the operation type. Then, the second device can send the recording control command to the first device through a classic Bluetooth connection or a BLE connection (i.e., the first connection).

[0139] After receiving the control command, the first device can parse the command content and perform corresponding operations. For example, if the command is "pause recording", the first device will stop audio acquisition, mute the microphone, and save the current recording data as a temporary file. If the command is "resume recording", the first device will restart audio acquisition, continue recording from the last pause point, and can also add timestamps to the newly acquired data to ensure data continuity.

[0140] In step S820, the operating status fed back by the first device after executing the recording control command is received.

[0141] In this embodiment, after executing the recording control command, the first device can generate working status feedback information and send the status feedback information (such as "paused" or "resumed") to the second device so that the second device knows whether the first device has correctly executed the recording control command.

[0142] In one example, the second device can synchronize the status information fed back by the first device to the mobile terminal, so that the user can know the current working status of the first device through the mobile terminal APP.

[0143] Thus, through precise command control, the system can accurately control the start, pause, and resumption of recording, ensuring that the recording process meets user needs and avoiding recording errors caused by misoperation or system delays. Furthermore, the operational status feedback mechanism ensures the verifiability of command execution; even in situations of unstable Bluetooth connection, the system can accurately determine whether commands have been successfully executed, thereby improving system reliability and stability.

[0144] In some embodiments of this disclosure, the audio data processing method may further include, for example: Figure 9 Steps S910 to S920 are shown.

[0145] In step S910, when the occurrence of the third operation event is detected, a recording stop command is sent to the first device, and the first device stops recording according to the recording stop command.

[0146] The third operation event can be a specific operation triggered by the user or the system to stop recording. For example, a recording termination request triggered by clicking the "Stop Recording" button on a mobile terminal APP, a voice command, a physical button operation, or other preset conditions.

[0147] A recording stop command can be used to terminate the recording function. It may include information such as the operation type (stop) or device identifier, to instruct the first device to stop audio acquisition.

[0148] In this embodiment, when the second device detects the occurrence of a third operation event (which can be obtained by monitoring instruction inputs from a mobile terminal APP, local control, or system-triggered commands), it can generate a corresponding recording stop command and send the recording stop command to the first device (which can be sent via a classic Bluetooth connection or a BLE connection (i.e., the first connection) between the second device and the first device).

[0149] Upon receiving the recording stop command, the first device immediately ceases audio acquisition, mutes the microphone, and stops generating new audio data. However, the first device does not immediately disconnect from the second device; instead, it maintains the data transmission channel to ensure that the acquired audio data is transmitted completely.

[0150] In step S920, the audio data being transmitted by the first device continues to be received until the audio data transmission is completed.

[0151] In this embodiment, the second device can continue to receive the audio data being transmitted by the first device. The second device can continuously monitor the data transmission status until it is confirmed that all acquired but not yet fully transmitted audio data has been received.

[0152] In this way, the "stop command - continue transmission - complete reception" mechanism ensures that all audio data before the user stops recording is completely saved, avoiding the problem of lost recording data due to immediate disconnection.

[0153] In some embodiments of this disclosure, after step S920, the audio data processing method may further include, as follows: Figure 10 Steps S1010 to S1030 are shown.

[0154] In step S1010, a first audio data list of the first device is obtained, the first audio data list including relevant information of the audio data already stored in the first device.

[0155] The first audio data list can be a collection of metadata of stored audio data recorded in the first device, which may include, but is not limited to, key information such as unique audio data identifiers, storage timestamps, file sizes, and audio types (ambient sound / call recordings).

[0156] In this embodiment, the second device can send a data list query request to the first device, and the first device can respond to the request, obtain the first audio data list (which can be obtained by organizing the metadata of the audio data in real time according to the request or by maintaining it according to a predetermined period), and return the first audio data list to the second device.

[0157] In step S1020, the first audio data list is compared with the second audio data list of the second device to determine the target audio data that the first device has not yet transmitted. The second audio data list includes relevant information about the audio data that the second device has stored.

[0158] The second audio data list can be a collection of metadata for stored audio data recorded in the second device, and may include, but is not limited to, key information such as unique audio data identifiers, storage timestamps, file sizes, and audio types (ambient sound / call recordings).

[0159] In this embodiment, after receiving the first audio data list, the second device can compare and analyze it with the locally stored second audio data list to identify audio data (i.e., target audio data) that exists in the first audio data list but not in the second audio data list.

[0160] In step S1030, a transmission instruction for instructing the transmission of the target audio data is sent to the first device, and the target audio data transmitted by the first device according to the transmission instruction is received.

[0161] In this embodiment, after determining the target audio data, the second device can send a transmission instruction for the target audio data to the first device. This instruction includes a unique identifier for the target audio data and transmission parameters. Upon receiving the transmission instruction, the first device can retrieve the corresponding target audio data from its local storage and transmit it to the second device via a BLE connection (i.e., the first connection). After receiving the data, the second device can perform integrity verification and metadata updates on the received audio data, adding the newly received data to the second audio data list and updating the synchronization status flag.

[0162] In this way, by regularly comparing the audio data list, any audio data that may be missed can be identified and transmitted in a timely manner, avoiding data loss due to transmission interruptions or abnormalities, and ensuring the integrity and reliability of the recording data.

[0163] Based on the technical solutions described above. Figure 11 A schematic flowchart of an audio data processing method according to another embodiment of this disclosure is shown. Figure 11 As shown, the audio data processing method includes steps S1101 to S1109 (taking a call recording as an example).

[0164] In step S1101, the user can start recording by clicking a physical button on the second device (e.g., double-clicking a button on the second device).

[0165] In step S1102, after receiving the request to start recording, the second device first checks whether the first device is in a call state.

[0166] In step S1103, the first device sends the status query result back to the second device. If the result is "yes" (i.e., in a call state), the call recording mode is entered. If the result is "no", the ambient sound recording mode or other preset processes may be triggered (the flowchart is not shown).

[0167] In step S1104, the second device confirms the call status and enters the call recording mode. In one example, the vibration motor and / or LED indicator on the second device can also perform corresponding prompts (such as vibration or turning on the light effect) to remind the user that the call recording mode has been entered.

[0168] In step S1105, the first device transmits the real-time collected call audio data to the second device through the established dedicated BLE connection channel (i.e., the first connection).

[0169] In step S1106, the second device receives the audio data and stores it.

[0170] In step S1107, the first device stores the recorded audio data in the local storage unit while transmitting the audio data. This storage mechanism serves as a redundancy guarantee, providing a basis for data recovery in the event of transmission interruption.

[0171] In step S1108, the second device forwards the received complete recording data to the mobile terminal APP via the BLE connection (i.e., the third connection).

[0172] In step S1109, the mobile terminal APP stores the received audio recording data in a local database. The mobile terminal APP can also simultaneously start a background process to prepare for synchronizing the data to the cloud server, completing multi-layered backup protection of the audio recording data.

[0173] Figure 12 A schematic flowchart illustrating the reconnection process between a first device and a second device in an audio data processing method according to another embodiment of the present disclosure is shown.

[0174] In step S1201, after the first device detects an interruption in the BLE connection with the second device, it can play a disconnection alert tone through its built-in speaker or vibration motor. This alert tone can be a preset short audio clip (such as a "beep-beep" double tone) lasting about 1 second, used to remind the user that the current recording process may be affected by the connection interruption and needs to be dealt with as soon as possible.

[0175] In step S1202, the second device may receive a reconnection request sent by the first device and re-establish the BLE connection with the first device according to the reconnection request.

[0176] In step S1203, after detecting a BLE re-establishment, the first device can play a reconnection prompt tone to remind the user that the connection has been re-established. In one example, the prompt tone can be a single long tone (such as "beep—") lasting for 2 seconds, indicating that the connection has been successfully restored. At the same time, the LED indicator on the first device can also flash blue light synchronously to provide connection status feedback.

[0177] In step S1204, the second device sends a status query command to the first device. Upon response, the first device can return the current call status (e.g., 0 indicates no call, 1 indicates a call). The second device can then determine whether to maintain recording mode or switch to standby mode.

[0178] In step S1205, when it is determined that the first device is still in a call, the second device can query the locally stored recording files, accurately locate the latest untransmitted recording file, and determine its interruption point. After determining the interruption point, the second device can generate a resume transmission command containing the file ID and interruption point information and send it to the first device.

[0179] In step S1206, after parsing the interruption resume instruction, the first device can read the recording data from the interruption position of the specified file and resume the transmission to the second device through the re-established BLE connection.

[0180] In step S1207, the second device writes the received recording data into the local storage space.

[0181] Figure 13 A schematic diagram of the reconnection process between a second device and a mobile terminal in an audio data processing method according to another embodiment of the present disclosure is shown.

[0182] In step S1301, when it is determined that the BLE connection with the mobile terminal APP is broken, the second device can send a BLE reconnection request to the mobile terminal. The mobile terminal can verify the second device based on the BLE reconnection request, and re-establish the BLE connection with the second device after successful verification.

[0183] In step S1302, the mobile terminal APP can send a file list query command to the second device. The second device retrieves its locally stored audio data files and generates a second device file list containing information such as a unique identifier for each file, storage timestamp, file size, recording type, or transmission status. After receiving this list, the mobile terminal APP compares it item by item with the locally cached file list to accurately identify the latest recording files that have not yet been synchronized.

[0184] In step S1303, the mobile terminal APP determines the latest untransmitted recording file and its breakpoint position based on the comparison results. It then generates a breakpoint resumption instruction containing the target file ID and the starting transmission position, and sends it to the second device.

[0185] In step S1304, after the second device parses the interrupted resume instruction, it reads the recording data from the specified location and sends it to the mobile terminal APP through the re-established BLE connection.

[0186] In step S1305, the mobile terminal APP writes the received recording data into the local storage space.

[0187] Figure 14 A schematic flowchart illustrating recording state control in an audio data processing method according to another embodiment of the present disclosure is shown.

[0188] In step S1401, the user can trigger a pause recording command by clicking the pause button on the second device.

[0189] In step S1402, after receiving the pause command, the second device (such as the charging case) immediately sends a pause recording command to the first device (such as the earphones).

[0190] In step S1403, after receiving the pause command, the first device stops the current recording operation.

[0191] In step S1404, the second device synchronizes the pause status to the mobile terminal APP, so that the user can know that the recording has been paused through the display interface.

[0192] In step S1405, the user can trigger the instruction to restore the recording by clicking the restore button on the second device.

[0193] In step S1406, after receiving the recovery command, the second device immediately sends a recovery recording command to the first device.

[0194] In step S1407, after receiving the recovery command, the first device restarts the recording operation.

[0195] In step S1408, the second device synchronizes the recovery status to the mobile terminal APP, so that the user can know that the recording has been recovered through the display interface.

[0196] Figure 15 A schematic diagram of the process of stopping recording is shown in an audio data processing method according to another embodiment of the present disclosure.

[0197] In step S1501, the user can issue a command to exit recording to the second device by double-clicking a physical button on the second device.

[0198] In step S1502, after receiving the instruction, the second device sends a stop recording instruction to the first device.

[0199] In step S1503, after receiving the instruction from the second device, the first device stops the ongoing recording operation.

[0200] In step S1504, the second device continues to receive the remaining data of the current recording file from the first device until the entire recording file is received.

[0201] In step S1505, the second device confirms that it has successfully received and stored the complete recording file, thus completing the file transfer process.

[0202] In step S1506, after confirming that the recording file has been successfully transmitted to the second device, the first device deletes the recording file stored in its own memory to free up storage space.

[0203] In step S1507, the second device actively queries the file list on the first device and compares it with its own stored file list to determine whether there are any files that have not been transmitted.

[0204] In step S1508, the second device sends a list of files to be transmitted to the first device based on the comparison results, instructing the first device to transmit these audio files.

[0205] In step S1509, the first device transmits the audio files in the list to the second device via a BLE connection, as instructed by the second device.

[0206] In step S1510, the second device confirms that it has successfully received and stored all the recording files in the list, and completes the file transfer process again.

[0207] In step S1511, after the recording files in the confirmation list of the first device have been successfully transferred to the second device, the first device deletes these files stored in itself to free up storage space.

[0208] Figure 16A schematic diagram of the interaction flow between a mobile terminal and a second device after recording ends is shown in an audio data processing method according to one embodiment of the present disclosure.

[0209] In step S1601, the mobile terminal APP sends an instruction to the second device (such as the charging case) to query and compare the file list in the second device to determine which files need to be transferred to the mobile terminal.

[0210] In step S1602, the mobile terminal APP determines the ID of the file that needs to be transferred from the second device based on the query results. This step ensures that only files that are not synchronized or need to be updated are selected for transfer.

[0211] In step S1603, the mobile terminal APP further determines the start and end points of each file that needs to be resumed from where it left off, so that the resumed transmission can be performed. This step optimizes the transmission process, allowing transmission to continue from the last interrupted position without having to start over.

[0212] In step S1604, the mobile terminal APP sends a list of files to be transmitted to the second device, instructing the second device to prepare to transmit the aforementioned audio files.

[0213] In step S1605, the second device transmits the recording files in the list to the mobile terminal APP via BLE connection.

[0214] In step S1606, after receiving the recording file, the mobile terminal APP updates the local recording list to ensure that the recording file status displayed on the user interface is up-to-date and reflects all synchronized files.

[0215] Figure 17 A schematic diagram of the process of a mobile terminal interacting with a second device using a Wi-Fi hotspot after recording ends is shown in another embodiment of the audio data processing method according to this disclosure.

[0216] In step S1701, the mobile terminal APP sends a command to the second device to start a Wi-Fi hotspot in order to establish a high-speed data transmission connection.

[0217] In step S1702, after receiving the instruction, the second device activates its own Wi-Fi hotspot function to prepare for connection with the mobile terminal APP.

[0218] In step S1703, the mobile terminal APP detects and connects to the Wi-Fi hotspot of the second device, establishing a high-speed data transmission channel.

[0219] In step S1704, the mobile terminal APP queries the file list on the second device via Wi-Fi connection and compares it with the local file list to determine the file that needs to be transferred.

[0220] In step S1705, the mobile terminal APP determines the file ID that needs to be transmitted from the second device based on the comparison result.

[0221] In step S1706, the mobile terminal APP sends a list of files to be transmitted to the second device, instructing the second device to prepare to send these files.

[0222] In step S1707, the second device transmits the recording files in the list to the mobile terminal APP via Wi-Fi connection to achieve high-speed data synchronization.

[0223] In step S1708, after receiving the recording file, the mobile terminal APP updates the local recording list to ensure that the recording file status displayed on the user interface is up-to-date.

[0224] Figure 18 A schematic diagram of the process of interaction between a second device and the cloud after recording ends is shown in an audio data processing method according to one embodiment of the present disclosure.

[0225] In step S1801, the second device uploads the recording files that have not been marked as completed to the cloud server to ensure remote backup and storage of the data.

[0226] In step S1802, after receiving the file, the cloud server sends a notification to the second device that the file upload is complete, confirming that the file has been successfully stored.

[0227] In step S1803, after receiving the notification, the second device marks the synchronization status of these recording files locally as synchronized to avoid duplicate uploads.

[0228] In step S1804, the cloud server updates the local recording list to the mobile terminal APP, and synchronizes the status of files that have been successfully uploaded to the cloud to ensure that the recording file status is up-to-date for users to query.

[0229] This disclosure also provides an electronic device, Figure 19 A schematic diagram of the hardware implementation using the processing system is shown.

[0230] like Figure 19As shown, the hardware structure of electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. Bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400 such as peripherals, voltage regulators, power management circuits, external antennas, etc. Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one connection line is used in this figure, but this does not indicate that there is only one bus or one type of bus.

[0231] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means that can contain a program for storage, communication, propagation, or transmission for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0232] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0233] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0234] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0235] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, electronic devices, and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0236] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0237] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0238] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0239] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. An audio data processing method, characterized in that, Applied to a second device, the method includes: Establish the first connection with the first device; According to the first connection, audio data sent by the first device is received, wherein the audio data is collected by the first device for ambient sound or call audio; The audio data is stored in local storage space; and The stored audio data is sent to the network side for storage; Sending the stored audio data to the network side for storage includes: Based on the second connection with the cloud server, the stored audio data is sent to the cloud server for storage; If the second connection is unavailable, the stored audio data is sent to the mobile terminal based on the third connection with the mobile terminal, and the mobile terminal sends the audio data to the cloud server for storage based on the fourth connection with the cloud server. The audio data processing method further includes: If the third connection is disconnected during the transmission of audio data to the mobile terminal, a first reconnection request is sent to the mobile terminal. The first reconnection request is used to indicate that the third connection with the mobile terminal should be re-established. In response to a first interruption resume instruction sent by the mobile terminal, audio data is continued to be transmitted to the mobile terminal based on the re-established third connection. The first interruption resume instruction is used to instruct the second device to continue transmission according to the interruption position of the latest audio data in the mobile terminal. Specifically, the synchronization status flag of the transmitted audio data is updated, and the synchronization status flag includes unsynchronized or synchronized; the audio data in the second device with the synchronization status flag of unsynchronized is transmitted to the network side.

2. The method as described in claim 1, characterized in that, According to the first connection, receiving audio data sent by the first device includes: Upon detecting the occurrence of a first operation event indicating the start of recording, a status query request is sent to the first device, and the first device provides feedback on its own working status based on the status query request. When the first device is in target working state, the recording mode is turned on and audio data sent by the first device is received according to the first connection.

3. The method as described in claim 2, characterized in that, Also includes: If the first connection is broken during the process of receiving audio data transmitted by the first device, a second reconnection request sent by the first device is received. Based on the second reconnection request, re-establish the first connection with the first device; After determining that the first device is still in the target working state, a second interruption resume transmission instruction is sent to the first device. The second interruption resume transmission instruction is used to instruct the first device to continue transmission according to the transmission interruption position of the latest audio data in the second device. Based on the re-established first connection, audio data transmitted by the first device according to the second breakpoint resume instruction is received.

4. The method as described in claim 2, characterized in that, Also includes: When a third operation event is detected, a recording stop command is sent to the first device, and the first device stops recording according to the recording stop command; Continue receiving audio data being transmitted by the first device until the audio data transmission is complete.

5. The method as described in claim 4, characterized in that, The process continues to receive audio data being transmitted by the first device until the audio data transmission is complete, and further includes: Obtain a first audio data list from the first device, wherein the first audio data list includes relevant information about the audio data already stored in the first device; The first audio data list is compared with the second audio data list of the second device to determine the target audio data that the first device has not yet transmitted. The second audio data list includes relevant information about the audio data that the second device has stored. Send a transmission instruction to the first device to instruct the transmission of the target audio data, and receive the target audio data transmitted by the first device according to the transmission instruction.

6. An audio data processing system, characterized in that, include: The first device is used to collect ambient sound or call audio; The second device is used to perform the audio data processing method as described in any one of claims 1 to 5; as well as On the network side, it is used to receive and store audio data transmitted by the second device.

7. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the audio data processing method according to any one of claims 1 to 5.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the audio data processing method according to any one of claims 1 to 5.

Images