Audio processing method and apparatus

Abstract

Embodiments of the present application provide an audio processing method and apparatus, which relate to the technical field of terminals. The method includes: during a voice call between a first device and a second device, receiving first information from the second device, where the first information is used to indicate playing a first recorded prompt tone; in response to the first information, the first device plays the first recorded prompt tone; in the case where the first recorded prompt tone is not played completely, the first device interrupts the playing of the first recorded prompt tone, and the first device marks that the audio stream processing of the first recorded prompt tone is completed. In this way, in the case where the recorded prompt tone is interrupted during playing, the electronic device can also mark that the audio stream processing of the recorded prompt tone is completed, which can reduce the phenomenon of abnormal playing of the recorded prompt tone in the future.

Description

Technical Field

[0001] This application relates to the technical field of terminals, and in particular, to an audio processing method and apparatus. Background Art

[0002] Most electronic devices can record during a call. To meet user requirements, when two electronic devices are in a call and one of the electronic devices records the call content, both electronic devices can play a recording prompt tone. Exemplarily, during a call between a first device and a second device, in response to an input operation of the user on the second device, the second device starts recording, and both the first device and the second device play a recording prompt tone, such as playing "recording started", etc.

[0003] However, if the first device interrupts the playback of the recording prompt tone before the playback of the recording prompt tone is completed, it may cause abnormal playback when the recording prompt tone is played again later. Summary of the Invention

[0004] Embodiments of this application provide an audio processing method and apparatus, which are applied to the technical field of terminals. After the first device interrupts the playback of the recording prompt tone, the first device can mark that the audio stream processing of the recording prompt tone is completed, thereby reducing the phenomenon of abnormal playback of the recording prompt tone later and improving the user experience.

[0005] In a first aspect, embodiments of this application propose an audio processing method. The method includes: during a voice call between a first device and a second device, receiving first information from the second device, the first information being used to indicate playing a first recording prompt tone; in response to the first information, the first device plays the first recording prompt tone; in the case where the first recording prompt tone is not played to completion, the first device interrupts the playback of the first recording prompt tone, and the first device marks that the audio stream processing of the first recording prompt tone is completed.

[0006] Wherein, the first device may be device 2 in the following text, and the second device may be device 1 in the following text. The first information may be the information 1 in data packet 1. The first recording prompt tone may be "stop recording" in method 800. The first device marking that the audio stream processing of the first recording prompt tone is completed may be, for example, setting the flag bit 1 corresponding to "stop recording" to true. The flag bit 1 corresponding to "stop recording" is set in the control block corresponding to "stop recording", that is, the control block in the shared memory created by S706.

[0007] In the audio processing method of the present application, when the first recording prompt tone has not finished playing and the first device interrupts the playback of the first recording prompt tone, the first device marks the audio stream processing of the first recording prompt tone as completed. In this way, when the first device plays the recording prompt tone again later, the abnormal playback of the subsequent recording prompt tone will not be caused by the fact that the audio stream is marked as not processed completed this time.

[0008] In combination with the first aspect, in some implementation manners of the first aspect, the first device marking the audio stream processing of the first recording prompt tone as completed includes: when the first condition is met, the first device marks the audio stream processing as completed, and the first condition includes one or more of the following: the chip of the first device is of a first preset type; the playback path of the audio stream is a first path; or, the type of the audio stream is a second preset type.

[0009] Among them, the first condition can be condition a, condition b, and condition c below. The chip of the first device being of a first preset type can be condition a below, and the first preset type can be type 1 below. The playback path of the audio stream being a first path can be condition b below, and the first path can be the preset path below. The type of the audio stream being a second preset type can be condition c below, and the second preset type can be type 2 below.

[0010] In this way, after the first device interrupts the playback of the first recording prompt tone, when it is determined that the chip of the first device is likely to cause the problem of circular playback of the recording prompt tone, and / or when it is determined that the current scenario is playing the recording prompt tone during a call, the first device marks the audio stream processing of the first recording prompt tone as completed. So that the first device can normally judge whether the audio processing is completed in other scenarios or when other chips are set. While reducing the abnormal playback of the recording prompt tone, the impact on the first device's processing of other audio data is relatively small.

[0011] In combination with the first aspect, in some implementation manners of the first aspect, the first device marking the audio stream processing as completed includes: when the first condition is met, setting the first flag bit to the first state; based on the first flag bit being in the first state, the first device marks the audio stream processing as completed.

[0012] Among them, the first flag bit can be flag bit 3 below. The first state can be flag 1 below.

[0013] In this way, the first device can determine that the chip of the first device is likely to cause the problem of circular playback of the recording prompt tone based on the first flag bit being in the first state, and / or determine that the current scenario is playing the recording prompt tone during a call, and then mark the audio stream processing of the first recording prompt tone as completed, thereby reducing the abnormal phenomenon of playing the recording prompt tone during a call.

[0014] In combination with the first aspect, in some implementations of the first aspect, the first device interrupts the playback of the first recorded prompt tone, including: the first device receives second information from the second device, and the second information is used to indicate the playback of the second recorded prompt tone; in response to the second information, the first device interrupts the playback of the first recorded prompt tone and plays the second recorded prompt tone.

[0015] Among them, the second information may be the information 2 in the data packet 2 below. The second recorded prompt tone may be "start recording" in method 800.

[0016] In this way, in the case where the first device interrupts the playback of the first recorded prompt tone due to the user's input operation on the second device, the first device can also mark the completion of the audio stream processing of the first recorded prompt tone, thereby reducing the phenomenon of abnormal playback of the recorded prompt tone by the first device in the future.

[0017] In combination with the first aspect, in some implementations of the first aspect, the first device interrupts the playback of the first recorded prompt tone, including: the voice call between the first device and the second device is interrupted, and the first device interrupts the playback of the first recorded prompt tone.

[0018] In this way, in the case where the first device interrupts the playback of the first recorded prompt tone due to the end of the call between the first device and the second device, the first device can also mark the completion of the audio stream processing of the first recorded prompt tone, thereby reducing the phenomenon of abnormal playback of the recorded prompt tone by the first device in the future.

[0019] In combination with the first aspect, in some implementations of the first aspect, the first device marks the completion of the audio stream processing of the first recorded prompt tone, including: setting the second flag bit to the second state, and the second flag bit being in the second state indicates the completion of the audio stream processing of the first recorded prompt tone.

[0020] Among them, the second flag bit may be the flag bit 1 below, and the second state may be true below, that is, the second flag bit being in the second state may be the flag bit 1 being true below.

[0021] In this way, the first device can determine the completion of the audio stream processing of the first recorded prompt tone based on the second flag bit, so that the first device can release the control block corresponding to the audio stream of the first recorded prompt tone. When the first device plays a new recorded prompt tone later and creates a control block corresponding to the new recorded prompt tone, if the shared memory address of the control block corresponding to the new recorded prompt tone is the same as that of the control block corresponding to the audio stream of the first recorded prompt tone, the flag bit in the control block corresponding to the new recorded prompt tone may be in the initial state, thereby reducing the phenomenon of abnormal playback of the recorded prompt tone by the first device.

[0022] In combination with the first aspect, in some implementations of the first aspect, the second flag bit is set in the control block corresponding to the audio stream.

[0023] Among them, the control block corresponding to the audio stream is, for example, the control block created in S706.

[0024] In combination with the first aspect, in some implementation manners of the first aspect, the first device includes an audio mixer, audioflinger; the first device marking the completion of the audio stream processing of the first recording prompt tone includes: the audio mixer marking the completion of the audio stream processing of the first recording prompt tone.

[0025] In this way, the audio mixer can mark the completion of the audio stream processing of the first recording prompt tone when the first device interrupts the playback of the first recording prompt tone. So that when the first device plays the recording prompt tone again later, the playback of the subsequent recording prompt tone will not be abnormal due to the abnormal state of the first recording prompt tone.

[0026] In combination with the first aspect, in some implementation manners of the first aspect, receiving the first information from the second device includes: receiving a data packet from the second device, where the data packet includes the audio stream of the first recording prompt tone and the first information.

[0027] Among them, the data packet can be the data packet 1 in the following text. The audio stream of the first recording prompt tone can be the audio data in the data packet 1, and the first information can be the information 1 in the data packet 1.

[0028] In this way, the first device can obtain the audio stream to be played.

[0029] In a second aspect, an embodiment of the present application provides a device, which can be an electronic device, or a chip or a chip system inside the electronic device. The dynamic effect execution device can include a transceiver unit, an audio playback unit, and a processing unit. When the device is an electronic device, the transceiver unit can be a transceiver, the audio playback unit can be a speaker or a headphone, etc., and the processing unit can be a processor. The device can also include a storage unit, and the storage unit can be a memory. The storage unit is used to store instructions, and the transceiver unit, the audio playback unit, and the processing unit execute the instructions stored in the storage unit, so that the electronic device implements an audio processing method described in the first aspect or any one of the possible implementation manners of the first aspect. When the device is a chip or a chip system inside the electronic device, the processing unit can be a processor. The processing unit executes the instructions stored in the storage unit, so that the electronic device implements an audio processing method described in the first aspect or any one of the possible implementation manners of the first aspect. The storage unit can be a storage unit inside the chip (for example, a register, a cache, etc.), or a storage unit outside the chip and inside the electronic device (for example, a read-only memory, a random access memory, etc.). The transceiver unit can be, for example, an Mdoem, etc.

[0030] Exemplarily, a transceiver unit for receiving first information from a second device; an audio playback unit for playing a first recorded prompt tone; and a processing unit for marking the completion of the audio stream processing of the first recorded prompt tone.

[0031] In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a memory. The memory is used to store code instructions, and the processor is used to run the code instructions to execute the method described in the first aspect or any possible implementation manner of the first aspect.

[0032] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction runs on a computer, the computer is caused to execute the method described in the first aspect or any possible implementation manner of the first aspect.

[0033] In a fifth aspect, an embodiment of the present application provides a computer program product including a computer program. When the computer program runs on a computer, the computer is caused to execute the method described in the first aspect or any possible implementation manner of the first aspect.

[0034] In a sixth aspect, the present application provides a chip or a chip system. The chip or the chip system includes at least one processor and a communication interface. The communication interface and the at least one processor are interconnected by a line. The at least one processor is used to run a computer program or instruction to execute the method described in the first aspect or any possible implementation manner of the first aspect. Among them, the communication interface in the chip can be an input / output interface, a pin, a circuit, etc.

[0035] In a possible implementation, the chip or the chip system described above in the present application further includes at least one memory, and instructions are stored in the at least one memory. The memory can be an internal storage unit of the chip, such as a register, a cache, etc., or a storage unit of the chip (such as a read-only memory, a random access memory, etc.).

[0036] It should be understood that the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects obtained by each aspect and the corresponding feasible implementation manners are similar and will not be elaborated. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is a schematic diagram of an application scenario applicable to an embodiment of the present application;

[0038] Figure 2 It is a schematic diagram of the process of playing a recorded prompt tone in a loop;

[0039] Figure 3Schematic diagram of a shared memory structure;

[0040] Figure 4 Schematic flow chart of a process for loop-playing a recorded prompt tone;

[0041] Figure 5 Schematic diagram of the software-hardware interaction process of an electronic device provided by an embodiment of the present application;

[0042] Figure 6 Schematic block diagram of a multimedia architecture provided by an embodiment of the present application;

[0043] Figure 7 Schematic flow chart of an audio processing method provided by an embodiment of the present application;

[0044] Figure 8 Schematic flow chart of another audio processing method provided by an embodiment of the present application;

[0045] Figure 9 Schematic flow chart of yet another audio processing method provided by an embodiment of the present application;

[0046] Figure 10 Schematic block diagram of the hardware architecture of an electronic device provided by an embodiment of the present application;

[0047] Figure 11 Schematic block diagram of an audio processing apparatus provided by an embodiment of the present application. Detailed implementation

[0048] To facilitate a clear description of the technical solutions of the embodiments of the present application, the following briefly introduces some terms and technologies involved in the embodiments of the present application:

[0049] 1. Thread: An execution unit within a process. A process can contain one or more threads, and these threads share the resources of the process (such as memory, file handles), but each thread has its own stack, registers, and program counter.

[0050] 2. Java Native Interface (JNI): A programming framework that allows Java code to interact with code written in other programming languages (such as C, C++).

[0051] android.media.*: A package of classes and interfaces in the Android operating system for handling multimedia functions. This package provides rich APIs for managing and operating multimedia content such as audio, video, and images. The following are some common sub-packages and classes:

[0052] 3. MixerThread: A thread dedicated to processing audio mixing. In the audio framework, multiple audio streams (such as audio outputs from different applications) need to be mixed together and then output to the audio hardware device. The MixerThread is the thread responsible for this task. The MixerThread reads audio data from multiple audio sources, mixes this data together, and sends the mixed audio data to the audio output device. This process needs to be carried out in real time to ensure the continuity and synchronization of audio playback.

[0053] 4. Other terms

[0054] In the embodiments of the present application, terms such as "first" and "second" are used to distinguish identical or similar items with basically the same functions and roles. For example, the first chip and the second chip are only used to distinguish different chips and do not limit their sequence. Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and terms such as "first" and "second" do not necessarily mean different.

[0055] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific manner.

[0056] In the embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of single item (s) or plural item (s). For example, at least one (item) of a, b, or c can represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, and c can be single or multiple.

[0057] 5. Electronic device

[0058] The electronic device according to the embodiment of the present application may include a handheld device with a face recognition function, a vehicle-mounted device, etc. For example, some electronic devices are: mobile phone, tablet computer, handheld computer, laptop computer, mobile internet device (MID), wearable device, virtual reality (VR) device, augmented reality (AR) device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication function, computing device or other processing device connected to a wireless modem, vehicle-mounted device, wearable device, terminal device in a 5G network or terminal device in a future evolved public land mobile network (PLMN), etc. The embodiment of the present application is not limited thereto.

[0059] By way of example and not limitation, in the embodiment of the present application, the electronic device may also be a wearable device. A wearable device may also be referred to as a wearable intelligent device, which is a general term for devices developed by applying wearable technologies to intelligentize daily wear, such as glasses, gloves, watches, clothing, shoes, etc. A wearable device is a portable device that is either directly worn on the body or integrated into the user's clothes or accessories. A wearable device is not just a hardware device, but also realizes powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable intelligent devices include those with complete functions and large sizes that can realize complete or partial functions without relying on a smart phone, such as smart watches or smart glasses, etc., and those that only focus on a certain type of application function and need to cooperate with other devices such as smart phones, such as various smart bracelets and smart jewelry for physical sign monitoring.

[0060] In addition, in the embodiments of the present application, the electronic device may also be a terminal device in an Internet of Things (IoT) system. The IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, so as to realize an intelligent network of human-machine interconnection and object-object interconnection.

[0061] The electronic device in the embodiments of the present application may also be referred to as: terminal device, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile terminal, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user device, etc.

[0062] In the embodiments of the present application, the electronic device or each network device includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and a memory (also referred to as main memory). The operating system may be any one or more computer operating systems that implement service processing through processes. For example, Linux operating system, Unix operating system, Android operating system, iOS operating system, or Windows operating system, etc. The application layer includes applications such as a browser, an address book, a word processing software, and an instant messaging software.

[0063] Currently, some electronic devices can record the call content during a call. And, in response to a user's input operation 1 on the peer electronic device, where input operation 1 indicates starting to record, both the local electronic device and the peer electronic device can play a voice prompt 1, and voice prompt 1 prompts the user to start recording. Voice prompt 1 may be, for example, "Start recording". After that, in response to a user's input operation 2 on the peer electronic device, where input operation 2 indicates ending the recording, both the local electronic device and the peer electronic device can play a voice prompt 2, and voice prompt 2 prompts the user to end the recording. Voice prompt 2 may be, for example, "Stop recording".

[0064] For ease of description, hereinafter the peer electronic device is referred to as device 1, and the local electronic device is referred to as device 2. Device 1 and device 2 establish a voice call, and the user inputs an operation indicating starting to record and an operation indicating ending the recording on device 1. For the sake of brevity, this will not be elaborated further hereinafter.

[0065] It should be understood that the recording prompt sounds shown in the embodiments of the present application, such as "start recording" and "stop recording", are only examples, and "start recording" and / or "stop recording" can also be replaced by other recording prompt sounds. For example, "start recording" can also be replaced by "recording has started", etc., and "stop recording" can also be replaced by "recording ended", etc. The present application does not make specific limitations on this.

[0066] Exemplarily, as Figure 1 shown, during the call between device 1 and device 2, device 1 can display Figure 1 the interface (a) in. In response to the user's click operation on the recording button 101, device 1 starts recording. And both device 1 and device 2 can play "start recording". And in response to the user's click operation on the recording button 101, device 1 can display Figure 1 the interface (b) in. In interface (b), the time below the recording button 102 is the recording duration. After that, in response to the user's click operation on the recording button 102, device 1 ends recording. And both device 1 and device 2 can play "stop recording".

[0067] It should be noted that the above call can be initiated by device 1 or by device 2. The present application does not make specific limitations on this.

[0068] However, in some application scenarios, in response to the user's input operation on device 1, such as input operation 1 or input operation 2, etc., device 2 may play some recording prompt sounds in a loop. Exemplarily, in response to the user's input operation 1 on device 1, device 2 plays some voice prompt sounds in a loop. For example, it plays "start" in a loop, so that the user of device 2 hears "start start start start...", resulting in a poor user experience.

[0069] Next, in combination with Figure 2 , a possible scenario where device 2 plays "start" in a loop is described.

[0070] Exemplarily, assume that at time t1, device 1 and device 2 establish call 1; at time t2 after time t1, call 1 is still ongoing. In response to the user's input operation 1 on device 1, device 1 starts recording, and both device 1 and device 2 start playing "start recording"; at time t3 after time t2, device 2 has not finished playing "start recording", for example, device 2 has just played "start", and call 1 between device 1 and device 2 ends. And due to the end of call 1 between device 1 and device 2, device 2 terminates playing "start recording".

[0071] At time t4 after time t3, device 1 establishes a call 2 with device 2; at time t5 after time t4, call 2 is still being recorded, in response to the user's input operation 1 on device 1, device 1 starts recording, and both device 1 and device 2 start playing "Start Recording"; at time t6 after time t5, both device 1 and device 2 have finished playing "Start Recording"; at time t7 after time t6, in response to the user's input operation 2 on device 1, device 1 ends the recording; and both device 1 and device 2 start playing "Stop Recording"; at time t8 after time t7, device 2 has not finished playing "Stop Recording", for example, device 2 has just finished playing "Stop", in response to the user's input operation 1 on device 1, device 1 starts recording again, at this time, device 2 plays "Start Recording", and device 2 starts to loop-play a part of the audio in "Start Recording", for example, loop-play "Start". As a result, the user of device 2 hears "Start Start Start...", resulting in a poor user experience.

[0072] Through Figure 2 From the process shown, for device 2, there are 2 cases where the audio playback is abnormally terminated before looping-playing a part of the audio in "Start Recording". That is, at time t3, call 1 ends when "Start Recording" has not finished playing, causing the playback of "Start Recording" to be abnormally terminated; at time t8, when the user instructs to start recording again when "Stop Recording" has not finished playing, causing the playback of "Stop Recording" to be abnormally terminated.

[0073] It should be understood that Figure 2 The scenarios shown are only examples, and the devices establishing call 1 and call 2 with device 2 can also be different devices. For example, the device establishing call 1 with device 2 is device 1-1, and the device establishing call 2 with device 2 can be device 1-2, etc. This application does not make specific limitations on this.

[0074] Thus, it can be seen that the loop-playing of a part of the audio in "Start Recording" by device 2 may be related to the previous two abnormal terminations of audio playback, as follows.

[0075] It can be understood that in the above process, each time device 2 plays a recording prompt tone such as "Start Recording" or "Stop Recording", device 2 will create an AudioTrack class; device 2 will also create a control block (control block, Cblk) corresponding to the recording prompt tone and allocate a shared memory for this control block. The pointer of the shared memory can be mBufferSizeInFrames, that is, mBufferSizeInFrames points to this shared memory. This shared memory includes a control block and a buffer.

[0076] For ease of description, the control block created by device 2 is referred to as control block 1, the shared memory allocated for the control block is referred to as shared memory 1, and the buffer included in shared memory 1 is referred to as buffer 1. Then, as Figure 3 shown, shared memory 1 includes control block 1 and buffer 1.

[0077] Among them, the control block 1 includes a flag field, and the flag field can also be called mFlags. The flag field is used to record various flags. The flag field can, for example, include flag 1 or flag 2, etc. Flag 1 can, for example, be CBLK_STREAM_END_DONE; flag 2 can, for example, be CBLK_INVALID.

[0078] Flag 1 can be used to indicate that the audio data (or audio stream) has been processed or completed. For example, when flag 1 is set to true, it indicates that the audio data processing is completed, and device 2 can release control block 1. Flag 2 can be used to indicate that the control block is in an invalid state. For example, when flag 2 is set to true, it indicates that control block 1 is in an invalid state, and device 2 will not release control block 1.

[0079] It should be understood that the control block being in an invalid state can also be understood as one or more of the following: an error occurred during the initialization of the control block, resulting in its inability to be used normally; the resources (such as memory, file handles, etc.) on which the control block depends are unavailable or have been released; the control block has entered an error state and cannot continue to operate normally; the control block has been released or destroyed and is no longer valid.

[0080] Buffer 1 is used to cache audio data. Device 2 can read audio data from buffer 1 and / or write audio data to buffer 1 based on control block 1.

[0081] When device 2 determines that the playback of a recording prompt tone is interrupted (which can also be replaced by paused or terminated), device 2 can determine whether the audio data of the recording prompt tone has been processed; if so, device 2 can set flag 1 to true; if not, device 2 can set flag 2 to true.

[0082] It should be understood that the completion of the audio data processing of the recording prompt tone can be understood as the device 2 having processed the audio data written in the buffer 1. The completion of the audio data processing of the recording prompt tone does not limit the device 2 from completely playing the recording prompt tone, that is, the user does not necessarily hear the device 2 completely play the recording prompt tone. Exemplarily, the completion of the audio data processing of "start recording" does not limit the device 2 from having played "start recording" completely. When the device 2 terminates the playback of "start" and then terminates the playback of "start recording", the device 2 may still determine that the audio data processing of "start recording" is completed. This is because the storage space of the buffer 1 is limited. Therefore, the device 2 may not start reading the audio data of "start recording" after writing all the audio data of "start recording" into the buffer 1.

[0083] The device 2 can continuously write audio data into the buffer 1 on the one hand and read and play the audio data on the other hand. Therefore, after the playback of "start recording" is terminated, only part of the audio data of "start recording" may be written into the buffer 1. The device 2's determination that the audio data processing of "start recording" is completed can be the device 2's determination that this part of the audio data is processed (or completed).

[0084] When the flag bit 1 is true, it indicates that the audio data processing of the current playback of this recording prompt tone is completed, enabling the device 2 to release the control block 1 through a callback function or other means. When the device 2 allocates shared memory 1 for a newly created control block next time, the flag bits included in the newly created control block can all be in the initial state, that is, the flag bits included in the newly created control block are all set to the default value (usually 0 or other predefined values).

[0085] When the flag bit 2 is true, it indicates that the audio data of this recording prompt tone has not been processed completely. The device 2 will determine that the control block 1 is in an invalid state, so that the device 2 will not release the control block 1. In this way, when the device 2 plays a recording prompt tone next time and creates a new control block, when the device 2 allocates shared memory 1 for the new control block, the new control block 2 will reuse the state of the flag bit recorded in the control block 1, that is, the flag bit 2 in the control block 2 is set to true. Since the flag bit 2 in the control block 2 is set to true, the device 2 will loop-play part of the audio of the recording prompt tone during the next playback of the recording prompt tone. The specific process is as follows.

[0086] Exemplarily, in combination with Figure 2In the process shown, the "Start Recording" played by device 2 at time t3 was abnormally aborted. Assume that when playing the recording prompt tone this time, device 2 created AudioTrack and control block a, and the shared memory corresponding to control block a is shared memory a. Since the "Start Recording" played at time t3 was abnormally aborted, device 2 determined that the audio data of "Start Recording" was not processed completely, causing device 2 to set the flag bit 2 in control block a to true.

[0087] In addition, the "Stop Recording" played by device 2 at time t8 was abnormally aborted. Assume that when playing the recording prompt tone this time, device 2 created AudioTrack and control block b, and the shared memory corresponding to control block b is shared memory b. Since the "Stop Recording" played at time t8 was abnormally aborted, device 2 determined that the audio data of "Stop Recording" was not processed completely, causing device 2 to set the flag bit 2 in control block b to true.

[0088] Since the memory of device 2 is limited, during the process of device 2 playing the recording prompt tone, the shared memory allocated by device 2 for playing the recording prompt tone can reuse the shared memory used by the device to play the recording prompt tone at a historical moment. So at time t8, in response to input operation 1 of user on device 1, device 2 terminates playing "Stop Recording" and starts playing "Start Recording". During this process, device 2 creates the AudioTrack corresponding to the audio stream of "Start Recording" and control block c. The shared memory allocated by device 2 for control block c may be shared memory a or shared memory b. In this way, the flag bit in control block c will reuse the state of the flag bit in control block a or control block b, that is, the state of flag bit 2 in control block c is true. Based on the fact that flag bit 2 is true, device 2 will determine that control block c is invalid, and thus will create audio tracks in a loop and start playing the recording prompt tone in a loop. Specifically as follows.

[0089] Device 2 will execute in a loop Figure 4 The process shown.

[0090] S401. Device 2 calls the strat method in AudioTrack to start playing the audio data in the cache of shared memory c. That is, start playing "Start Recording".

[0091] S402. Device 2 calls the getPosition method in AudioTrack to read the state of the flag bit in the current control block.

[0092] Among them, the current control block is the control block latest created by device 2 each time S402 is executed. When executing Figure 4 The process shown for the first time, the current control block can be control block c. After that, when executing Figure 4 The process shown for the second time, the current control block can be the one when executing Figure 4The new control block created by the shown process (S405).

[0093] S403. Device 2 determines whether flag bit 2 is true.

[0094] S404. When device 2 determines that flag bit 2 in the current control block is true, a new track is created.

[0095] Herein, a track can be understood as a playback instance corresponding to audio data. Each time device 2 plays a recording prompt tone, it will create a track corresponding to the recording prompt tone. For example, device 2 also creates a track before creating AudioTrack and control block c. After device 2 creates a new track, it will terminate the playback of the currently playing recording prompt tone and start playing the recording prompt tone corresponding to the new track.

[0096] S405. Device 2 creates the AudioTrack corresponding to the new track and a new control block. The shared memory corresponding to the new control block may be shared memory a or shared memory b, such that the flag bit in the new control block reuses the state in control block a or control block b, that is, the state of flag bit 2 in the new control block is true.

[0097] Then, device 2 executes S401 to S405 again, and again reads that flag bit 2 in the current control block (the new control block) is true in S402, such that device 2 may continuously loop and execute Figure 4 the shown process. Thus, device 2 continuously starts playing "Start Recording".

[0098] Device 2 during the repeated execution of Figure 4 the shown process, since device 2 continuously creates new tracks (S404), device 2 will continuously terminate the currently playing "Start Recording" and restart playing "Start Recording" based on the new track. Since each time device restarts playing "Start Recording" based on a new track, the currently playing "Start Recording" may not be fully played. For example, the currently playing "Start Recording" is interrupted after playing "Start". In this way, device 2 restarts playing "Start Recording" each time after playing "Start". Such that the user continuously hears partial audio of "Start Recording", for example, hears "Start Start Start Start…".

[0099] It can be seen that the reason for the above problems is that at time t3, the device 2 determines that the audio data of "start recording" has not been processed completely, which causes the device 2 to set the flag bit 2 in control block a to true, and further causes the device 2 not to release control block a; and at time t8, it is determined that the audio data of "stop recording" has not been processed completely, which causes the device 2 to set the flag bit 2 in control block b to true, and further causes the device 2 not to release control block b. Further, when the device 2 subsequently plays the recording prompt tone and creates control block c, if the shared memory allocated to control block c is the same as shared memory a (or shared memory b), it causes control block c to reuse the status of the flag bit in control block a (or control block b), and further causes the device 2 to determine that control block c is abnormal (invalid).

[0100] It should also be noted that during the process of the device 2 playing the recording prompt tone, the device 2 writes the audio data of the recording prompt tone into the HAL layer through the application framework layer; the HAL layer writes the audio data of the recording prompt tone into the kernel layer; and then the kernel layer plays the recording prompt tone through hardware such as a speaker or headphones.

[0101] The device 2 usually determines whether the audio data of the recording prompt tone has been processed completely in the following way: the device 2 determines whether the number of frames of the audio data written from the application framework layer to the HAL layer is greater than or equal to the number of frames of the audio data of the recording prompt tone (condition 1); and the device 2 determines whether the number of frames of the audio data received by the kernel layer is less than the number of frames of the audio data written from the application framework layer to the HAL layer (condition 2). When the device 2 determines that conditions 1 and 2 are met, it determines that the audio data of the recording prompt tone has been processed completely; when the device 2 continuously determines multiple times that conditions 1 and / or 2 are not met, it determines that the audio data of the recording prompt tone has not been processed completely.

[0102] Exemplarily, the device 2 can call a function to determine whether conditions 1 and 2 are met; when the device 2 determines that conditions 1 and / or 2 are not met, the device 2 determines again whether conditions 1 and 2 are met. When the device 2 continuously determines multiple times (for example, 127 times) that conditions 1 and / or 2 are not met, the device 2 determines that the audio data of the recording prompt tone has not been processed completely and sets the flag bit 2 to true.

[0103] In view of this, the present application provides an audio processing method. During a call between device 1 and device 2, when device 2 plays a recording prompt tone in response to a user's input operation on device 1, after the playback of the recording prompt tone terminates, device 2 marks that the audio data processing of the recording prompt tone is completed. In this way, after device 2 terminates the playback of the recording prompt tone, device 2 will not set the flag bit 2 to true due to judging that the audio data of the recording prompt tone has not been processed completely. So that the flag bit included in the control block created during the subsequent playback of the recording prompt tone by device 2 can be in the initial state, thereby reducing the abnormal phenomenon of loop-playing the recording prompt tone caused by the flag bit 2 being true in the created control block, enabling device 2 to play the recording prompt tone normally and improving the user experience.

[0104] The following combines Figures 5 to 9 Specific embodiments are used to elaborate in detail on the technical solution of the present application and how the technical solution of the present application solves the above technical problems. These several specific embodiments can be implemented independently or in combination with each other. For the same or similar concepts or processes, they may not be elaborated in some embodiments.

[0105] The embodiments shown in the present application can be executed by device 2, or by a chip, chip system or processor that supports device 2 to implement the audio processing method, or can also be a logic module or software execution that can implement all or part of the functions of device 2. The present application does not make specific limitations on this.

[0106] The following takes device 2 as the execution subject to illustrate the embodiments of the present application. The specific forms and quantities of the devices shown therein are only examples and should not constitute any limitation on the implementation of the method provided by the present application.

[0107] For ease of understanding, the following combines Figure 5 , taking the Android system with a layered architecture as an example, to exemplarily illustrate the software architecture of device 2.

[0108] Among them, the software system of device 2 can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture.

[0109] The layered architecture divides the software into several layers, and each layer has clear roles and divisions of labor. The layers communicate through software interfaces. In some embodiments, the Android system is divided into six layers, from top to bottom are the application layer, the Java framework layer, the system service layer, the system runtime and system libraries, the hardware abstraction layer, and the kernel layer.

[0110] 1. Application layer

[0111] The application layer may include a series of application packages. Such as Figure 5As shown, the application package may include applications such as calls, browsers, and emails.

[0112] 2. The Java framework layer, which can also be referred to as the application framework (FWK) layer

[0113] The Java framework layer can provide application programming interfaces (APIs) and programming frameworks for the applications in the application layer. The Java framework layer includes some predefined functions. For example, Figure 5 As shown, the Java framework layer may include starting the system service, media player module, media recorder module, and Radio Interface Layer (RIL), etc.

[0114] The system service may include the activity manager service, window manager, power manager, input manager, and telephony manager, etc.

[0115] The media player module, which can also be referred to as MediaPlayer, etc., can be used to obtain the audio data of the recording prompt tone and perform processing such as decoding on the audio data to obtain the decoded pulse code modulation (PCM) stream; and can create an AudioTrack in the FWK layer and transmit the decoded PCM stream to the AudioTrack. The PCM stream can be understood as an audio data stream encoded using PCM.

[0116] When using MediaPlayer to play audio data, MediaPlayer will create an AudioTrack internally to handle the actual audio output. AudioTrack provides low-level control over the audio data, such as buffering and playing the audio data.

[0117] AudioTrack can transmit the decoded PCM stream to the audio flinger.

[0118] The phone manager is used to provide the call function of the terminal, such as the management of call status (including answering, hanging up, etc.). The application framework layer may also include RIL, and the modem can interact with the phone manager through RIL to implement the call function of Device 2.

[0119] 3. System Services Layer

[0120] The system services layer contains various system services, and these services interact with the application framework layer through the Binder IPC mechanism. The system services layer manages and coordinates system resources and provides core functions for application programs.

[0121] The system services layer includes the audio flinger. The audio flinger can obtain the decoded PCM stream from AudioTrack, mix and process the decoded PCM stream through sound effects, etc., to obtain Audio Data 1; and transmit Audio Data 1 to the hardware abstraction layer.

[0122] The audio flinger is also used to determine whether the audio data of the recording prompt tone is processed after the playback of the recording prompt tone is terminated.

[0123] 4. System Runtime and System Libraries

[0124] The system runtime includes core libraries and a virtual machine. The system runtime is responsible for the scheduling and management of the Android system.

[0125] Among them, the core libraries contain two parts: one part is the functional functions that need to be called by the Java language, and the other part is the core libraries of Android.

[0126] The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as the management of object life cycles, stack management, thread management, security and exception management, and garbage collection.

[0127] The system libraries may include multiple functional modules. For example: surface manager, service manager, Media Libraries, 3D graphics processing library (e.g., OpenGL ES), 2D graphics engine (e.g., SGL), etc.

[0128] Among them, the surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple application programs.

[0129] The media library supports the playback and recording of multiple common audio and video formats, as well as static image files, etc. The media library can support multiple audio and video coding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. The media library includes an audio manager (audio flinger) and a media player service, etc.

[0130] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing, etc.

[0131] The 2D graphics engine is a drawing engine for 2D drawing.

[0132] 5. Hardware Abstraction Layer

[0133] The hardware abstraction layer (HAL) provides hardware-related abstract interfaces, enabling upper-layer system services and libraries to interact with different hardware.

[0134] HAL includes multiple library modules such as a Bluetooth module, a camera module, an audio module, and a sensor module. Among them, each library module can provide an interface for the implementation of corresponding hardware components.

[0135] The audio module can obtain audio data 1 from the audio flinger. And the audio module can further process audio data 1 based on the hardware requirements for playing a recording prompt tone, such as performing format conversion, adjusting the sampling rate, and volume control on audio data 1 to obtain audio data 2. The audio module can transmit audio data 2 to the hardware (such as a speaker, a receiver, or headphones) in device 2 through the kernel layer, so that the hardware in device 2 plays the recording prompt tone.

[0136] 6. Kernel layer (Kernel), which can also be called Linux Kernel

[0137] The kernel layer is the layer between hardware and software. The kernel layer is used to drive the hardware to make it work. The kernel layer includes a display driver, a screen driver, a graphics processing unit (GPU) driver, a camera, and a sensor driver, etc. The embodiments of the present application do not limit this. For example, the screen driver can drive the screen to turn on or off.

[0138] In addition to the above hierarchical architecture, device 2 can also be provided with a modem (Modem).

[0139] Modem can include NAS (non-access stratum, non-access layer) layer, RRC (radio resource control, radio resource control) layer, packet data convergence protocol (packet data convergence protocol, PDCP) layer, radio link layer control protocol (radio link control, RLC) layer, medium access control layer (medium access control layer, MAC) layer and physical (physical, PHY) layer. The aforementioned layers can be software modules. Modem can interact with network devices such as base stations through antennas.

[0140] Optionally, the audio data of the recorded prompt sound played by device 2 may be obtained from device 1. That is, device 1 may send the audio data of the recorded prompt sound to a network device such as a base station based on the modem of device 1; the network device such as the base station sends the audio data of the recorded prompt sound to device 2; and device 2 may receive the audio data of the recorded prompt sound from the network device such as the base station through the modem of device 2.

[0141] Understandably, Figure 5 The illustrated software structure does not constitute a specific limitation on the device 2. In other embodiments of the present application, the device 2 may include more or fewer software modules than those shown in the figure, for example, the system server may also include a resource manager and the like.

[0142] It should be understood that Figure 5 The names of the software modules or layer structures included in the illustrated software structure do not constitute specific limitations on the device 2. In other embodiments of the present application, Figure 5 The software modules in the illustrated software structure may also have other names. For example, the system library may be called the C++ framework layer, the Java framework layer may be called the application framework layer (FWK), and the system server may be called the system ability manager (SAMGR).

[0143] It should be noted that the software architecture of device 1 can also refer to Figure 5 , for the sake of brevity, it will not be repeated here.

[0144] It can be understood that the Android system also includes a multimedia architecture for processing multimedia tasks of the device 2, such as playing a recording prompt tone, etc. Figure 6 The multimedia architecture of device 2 is described in detail.

[0145] It should be understood that the multimedia architecture may also be referred to as an audio framework or an Android audio framework, etc., and this application does not make any specific limitations on this.

[0146] Figure 6 A schematic block diagram of the multimedia architecture provided by the embodiments of the present application. As Figure 6 shown, the multimedia architecture of device 2 includes an application framework layer, a native framework layer (Native Framework), HAL, and a kernel layer. The native framework layer can be understood as Figure 5 a part of the system libraries shown in

[0147] It should be understood that multiple source code files can be set in the multimedia architecture, and these source code files can be set in directories such as av / media and base / media.

[0148] Among them, the application framework layer can include a media playback module (also called a media playback APP) and a media recording module (also called a media recording APP). The application framework layer can also include android.media.*. android.media.* is a package of a set of classes and interfaces used to handle multimedia functions in the Android operating system. android.media.* provides rich APIs for managing and operating multimedia content such as audio, video, and images.

[0149] The multimedia architecture also includes a JNI module corresponding to the application framework layer. The APIs of the application framework layer can call the native framework layer through JNI. The native framework layer can call the media server through binder inter-process communication (IPC) proxies. The media playback service completes the playback of audio data through interactions with HAL and the kernel layer.

[0150] Among them, C++ source code files can be set in the JNI module, such as android.media_*.cpp, etc. Through these files, functions such as audio and video playback, recording, encoding, and decoding can be implemented.

[0151] C++ source code files can also be set in the native framework layer, such as AudioTrack.cpp and AudioRecord.cpp, etc.

[0152] AudioTrack.cpp is a key source file in the Android audio framework and can be used to implement the functions of the AudioTrack class. AudioTrack.cpp provides an interface for low-latency playback of audio data streams and is suitable for games, media players, and other real-time audio applications.

[0153] In addition, other non-binder resources, such as audio resources, can also be set in the local framework layer.

[0154] The local framework layer can transfer and share audio resources between different processes through the binder IPC proxy. The binder IPC proxy is a mechanism for transferring audio data and control commands between different processes.

[0155] The binder IPC proxy can obtain multiple C++ source code files, such as IAudioRecord.cpp, IAudioTrack.cpp, IAudioFlinger.cpp, and Ibinder.cpp, etc. These files usually contain the definitions and implementations of interfaces related to audio playback.

[0156] The media server can be understood as a process. The media server can transmit audio data across processes through the binder IPC proxy. The media server includes an audio policy service, an audio flinger service, and a media player service.

[0157] The audio policy service can determine the audio playback policy. For example, the audio policy service can decide the routing of the audio data stream (e.g., whether the recording prompt tone is played through the speaker, headphones, or a Bluetooth device), and can also control the volume. The audio policy service provides a set of APIs for the system and application programs to call to query and set the audio playback policy.

[0158] The audio flinger service can be understood as a Binder service, providing an interface for interacting with the audio flinger.

[0159] The media player service is a service component in the media server, responsible for processing requests from the media playback module. The media player service is used to manage audio playback tasks, such as the decoding of PCM streams, etc.

[0160] The HAL can include an Audio HAL Implementation. The Audio HAL Implementation defines a set of interfaces through which the audio driver communicates with the upper-layer software. The Audio HAL Implementation can also convert calls to HAL interfaces into instructions that the hardware can understand.

[0161] The kernel layer includes the advanced linux sound architecture (ALSA), the open sound system (OOS), or a custom driver, etc. Among them, ALSA is a collection of frameworks and drivers for audio processing in the Linux operating system. It provides low-level access to audio hardware and supports multiple audio devices. OSS provides a relatively simple programming interface and supports multiple audio hardware. A custom driver refers to an audio driver customized for specific hardware or specific requirements. Such drivers are usually written by hardware manufacturers or developers of specific applications to meet specific performance, function, or compatibility requirements.

[0162] It should be understood that Figure 6 The multimedia framework shown is only an example and does not constitute a limitation on the embodiments of this application.

[0163] Based on Figure 6 the multimedia framework shown, Device 2 can play a recording prompt tone through Method 700 as shown in Figure 7 Method 700 shown.

[0164] As Figure 7 shown, Method 700 includes the following steps:

[0165] S701. The media player module indicates the data source information corresponding to the audio data of the recording prompt tone to the media playback service through the Binder IPC proxy.

[0166] Among them, the recording prompt tone can be the recording prompt tone to be played. For example, in response to the input operation 1 of the user on Device 1, the input operation 1 indicates to start recording, and the recording prompt tone to be played on Device 2 can be "Start recording"; in response to the input operation 2 of the user on Device 1, the input operation 2 indicates to end recording, and the recording prompt tone to be played on Device 2 can be "Stop recording". The audio data of the recording prompt tone can be obtained from Device 1.

[0167] For example, Device 2 receives the audio data of the recording prompt tone from Device 1 through the Modem. The media player module can determine the data source information of the audio data of the recording prompt tone and indicate this data source information to the media playback service.

[0168] Optionally, in addition to the audio data of the recording prompt tone, Device 2 can also receive Information 1 from Device 1 through the Modem, and Information 1 is used to indicate playing the recording prompt tone. In this way, based on Information 1, the media player module can execute S701.

[0169] It should be understood that the data source information is the source information of the audio data, and the media playback service can determine the way to obtain the audio data based on the data source information. The data source information may include, for example, a local file path, a network uniform resource locator (URL), or a content provider URI, etc.

[0170] S702. The media playback service creates a media playback instance corresponding to the audio data, that is, a track, and obtains the audio data of the recording prompt tone, and prepares to decode and play the audio data.

[0171] For example, if the recording prompt tone for playback is "Stop recording", then the audio data of the recording prompt tone is the audio data of "Stop recording".

[0172] S703. The media playback module instructs the media playback service to start playing the audio data through the Binder IPC proxy. Alternatively, S703 can also be replaced by the media playback module instructing the media playback service to start playing the recording prompt tone, etc., through the Binder IPC proxy.

[0173] S704. Based on the instruction of the media playback module, the media playback service decodes the audio data of the recording prompt tone to obtain the decoded PCM stream.

[0174] S705. The media playback service creates an AudioTrack.

[0175] S706. The media playback service creates a control block and allocates shared memory for the control block. The shared memory includes the control block and a cache. The cache is used to cache the decoded PCM stream.

[0176] It should be understood that S705 and S706 can be executed in parallel, and S706 can also be executed before or after S705. This application does not make specific limitations on this.

[0177] S707. The media playback service writes the decoded PCM stream into the cache of the shared memory through AudioTrack.

[0178] S708. The audio flinger obtains the decoded PCM stream from the cache of the shared memory.

[0179] S709. The audio flinger mixes and processes the decoded PCM stream with sound effects, etc., to obtain audio data 1.

[0180] S710. The audio flinger instructs the audio module in the HAL with the audio data 1.

[0181] The audio module in S711 and HAL further processes the audio data 1, such as format conversion, sampling rate adjustment, and volume control, etc., to obtain the audio data 2.

[0182] S712. The audio module in HAL transmits the audio data 2 to the audio driver, enabling the audio driver to drive the audio hardware (such as a digital-to-analog converter, etc.) in the device 2 to play. The audio driver can drive the digital-to-analog converter to play the audio data 2 in the following manner: The digital-to-analog converter converts the audio data 2 from an electrical signal (or digital signal) to a sound signal (or analog signal), and plays the sound through an output device such as a speaker or headphones.

[0183] Method 700 shows the process of the device 2 playing a voice prompt tone. The following combines Figure 8 to elaborate in detail on the manner in which the device 2 determines whether the audio data is processed after stopping playing the recording prompt tone.

[0184] It should be noted that Figure 8 The method 800 shown takes the device 2 playing "Stop Recording" first; then the device 2 terminates playing "Stop Recording" and starts playing "Start Recording" as an example for description. Similar to Figure 2 the device 2 shown starts playing "Stop Recording" at time t7, terminates playing "Stop Recording" at time t8, and plays "Start Recording".

[0185] Figure 8 This is a schematic flowchart of an audio processing method 800 provided by an embodiment of the present application. As Figure 8 shown, the method 800 includes the following steps:

[0186] S801. In response to the user's input operation 2 on the device 1, the device 1 ends the recording (for example, Figure 2 the device 1 ends the recording at time t7 in ), and sends a data packet 1 through the Modem of the device 1 to a network device such as a base station. The data packet 1 includes the audio data of "Stop Recording" and information 1; the network device such as a base station sends the data packet 1 to the device 2; the device 2 receives the data packet 1 from the network device such as a base station through the Modem of the device 2.

[0187] It can be understood that the audio data of "Stop Recording" shown in S801 is only an example. For example, in the case where the device 1 ends the recording, the recording prompt tones played by the device 1 and the device 2 can also be "Recording has ended", etc. Or, S801 can also be that in response to the user's input operation 1 on the device 1, the device 1 starts recording, then the above-mentioned audio data of "Stop Recording" can be replaced with the audio data of "Start Recording".

[0188] It should be understood that the manner in which the device 2 obtains the audio data of the recording prompt tone shown above is only an example. The device 2 can also obtain the audio data of the recording prompt tone in other ways. For example, if the device 2 stores the audio data of the recording prompt tone, when the device 1 starts recording, information 3 can be sent to the device 2 through a network device, and the information 3 is used to indicate playing the recording prompt tone corresponding to starting recording, then the device 2 can obtain the audio data of "starting recording"; when the device 1 ends recording, information 4 can be sent to the device 2 through a network device, and the information 4 is used to indicate playing the recording prompt tone corresponding to stopping recording, then the device 2 can obtain the audio data of "stopping recording". The present application does not make specific limitations on this.

[0189] After that, the device 2 can play "stopping recording" through S701 to S712.

[0190] In one case, during the process of the device 2 playing "stopping recording", in response to the input operation 1 of the user on the device 1, the input operation 1 is used to indicate starting recording (for example, the device 1 starts recording at time t8), the device 2 terminates playing "stopping recording", and starts playing "starting recording" in the manner of S701 to S712.

[0191] In this case, the audio flinger can determine to terminate playing the recording prompt tone ("stopping recording") through S802 and S803.

[0192] S802: In response to the input operation 1 of the user on the device 1, the device 1 starts recording, and sends a data packet 2 to a network device such as a base station through the Modem of the device 1. The data packet 2 includes the audio data of "starting recording" and information 2, and the information 2 is used to indicate playing the recording prompt tone; the network device such as the base station sends the data packet 2 to the device 2; the device 2 receives the data packet 2 from the network device such as the base station through the Modem of the device 2.

[0193] It can be understood that the information 2 and the information 1 can be the same, for example, both are used to indicate playing the recording prompt tone; or the information 2 and the information 1 can also be different, for example, the information 1 is used to indicate playing the audio data of "stopping recording"; the information 2 is used to indicate playing the audio data of "starting recording", etc. The present application does not make specific limitations on this.

[0194] S803: The Modem of the device 2 instructs the audio flinger to terminate playing the recording prompt tone ("stopping recording").

[0195] It can be understood that after the Modem of device 2 obtains data packet 2, the media playback module can obtain data packet 2 from the Modem of device 2 and can instruct the audio flinger to terminate the playback of the recording prompt tone ("Stop recording") based on data packet 2. In addition, the media playback module can start playing the audio data in data packet 2 in the manner of S701 to S712, so that device 2 can terminate the playback of "Stop recording" and start playing "Start recording".

[0196] In another case, during the playback of the recording prompt tone ("Stop recording"), the media playback module determines that the call between device 1 and device 2 is disconnected, and then the media playback module instructs the audio flinger to terminate the playback of the recording prompt tone ("Stop recording").

[0197] Exemplarily, the media playback module can call a call manager or the like to monitor the call between device 2 and device 1, so that when the call between device 1 and device 2 is disconnected, the media playback module instructs the audio flinger to terminate the playback of the recording prompt tone ("Stop recording").

[0198] In yet another case, S802 can also be replaced with: the media playback module calls an interface to determine that the recording prompt tone ("Stop recording") has finished playing, and then the media playback module instructs the audio flinger to terminate the playback of the recording prompt tone ("Stop recording").

[0199] In this case, the playback of "Stop recording" is not interrupted, and device 2 finishes playing "Stop recording". After the media playback module determines that "Stop recording" has finished playing, it can instruct the audio flinger to terminate the playback of the recording prompt tone ("Stop recording").

[0200] When the audio flinger determines that the playback of the recording prompt tone ("Stop recording") has terminated, it can determine whether the audio data of "Stop recording" has been processed.

[0201] It should be noted that the completion of the playback of "Stop recording" means that device 2 has finished playing "Stop recording", that is, the user can hear device 2 finish playing "Stop recording". The completion of the processing of the audio data of "Stop recording" means that device 2 has completed the "production" and "consumption" of the audio data through the shared memory. For specific details, please refer to the above description and will not be elaborated here.

[0202] It can be understood that, as determined above, when device 2 determines whether the audio data of the recording prompt tone is processed based on condition 1 and condition 2, it may cause device 2 to determine that the audio data of the recording prompt tone is not processed, and then set the flag bit 2 to true. Therefore, in the embodiments of the present application, when audio flinger determines that conditions a, b, and c are met, audio flinger can determine that the audio data of the recording prompt tone is processed.

[0203] Among them, meeting conditions a, b, and c means that the chip of device 2 is prone to the abnormal phenomenon of loop-playing the recording prompt tone, and device 2 is currently playing the recording prompt tone during a call. In this way, when audio flinger determines that the chip of device 2 is prone to the abnormal phenomenon of loop-playing the recording prompt tone and device 2 plays the recording prompt tone based on the input operation of the user on device 1, audio flinger can directly determine that the audio data of the recording prompt tone is processed, so that audio flinger can set the flag bit 1 to true, and further enable device 2 to normally release the control block. This enables the status of the flag bit in the control block created by device 2 when playing the recording prompt tone subsequently to be the initial state, which can reduce the abnormal phenomenon of device 2 playing the recording prompt tone.

[0204] Whether audio flinger determines that conditions a, b, and c are met is shown in S804, S805, and S806 respectively.

[0205] S804. Audio flinger determines whether condition a is met. Condition a is that the chip of device 2 is of type 1.

[0206] Among them, type 1 is a preset type. The chip of device 2 can also be replaced with the chipset of device 2 or a system on chip (SoC). Type 1 can also be replaced with platform 1, indicating the model and / or manufacturer of the chip, etc. Exemplarily, audio flinger can obtain the platform (or type) corresponding to the chip of device 2 by calling functions such as GetPlatform() to determine whether the chip of device 2 is platform 1 (or type 1).

[0207] When the chip of device 2 is not of type 1, the media playback module executes S809.

[0208] When the chip of device 2 is of type 1, the media playback module executes S805.

[0209] S805. Audio flinger determines whether condition b is met. Condition b is that the playback path of the audio data is a preset path.

[0210] It should be understood that the playback path of the audio data is also the playback path of the audio data for this playback, that is, the playback path of the audio data of "stop recording".

[0211] Exemplarily, audio flinger can call a function to determine the playback thread (playback Thread) for playing the recording prompt tone ("stop recording"). The function called can be, for example, mThread promote() etc. Since the playback thread and the playback path are in one-to-one correspondence, audio flinger can determine the playback path of the recording prompt tone ("stop recording") based on the playback thread. The preset path can be, for example, incall_music_uplink etc. When the playback path of the audio data is incall_music_uplink, it means that the audio data is played during a call.

[0212] When audio flinger determines that the recording prompt tone ("stop recording") is not the preset path, the media playback module executes S809.

[0213] When audio flinger determines that the playback path of the recording prompt tone ("stop recording") is the preset path, the media playback module executes S806.

[0214] S806. Audio flinger determines whether condition c is met. Condition c is that the type of the audio stream is type 2.

[0215] Among them, the type of the audio stream is the type of the audio data for this playback, that is, the type of the audio data of the recording prompt tone ("stop recording"). The type of the audio stream can also be called the data stream type etc. Type 2 can be, for example, VOICE_CALL etc., indicating that the audio data of the recording prompt tone is played during a call.

[0216] When audio flinger determines that the type of the audio stream is not type 2, audio flinger executes S809.

[0217] When audio flinger determines that the type of the audio stream is type 2, audio flinger executes S807.

[0218] S807. Audio flinger sets the flag bit 3 to flag 1.

[0219] Among them, the flag bit 3 can be, for example, mtkRecordCall, etc., and mtkRecordCall can also be understood as a variable. The flag 1 can be, for example, predefined information such as true. When the flag 1 is set in the flag bit 3, audioflinger can determine that the audio data processing of the recording prompt tone ("Stop recording") is completed. When the flag 2 is set in the flag bit 3, audio flinger can determine whether the audio data of "Stop recording" is processed (i.e., execute S809) based on condition 1 and condition 2. The flag 2 can be, for example, false, and the initial state or default value of the flag bit 2 is the flag 2.

[0220] It should be noted that the flag bit 3 can be a variable or flag bit set in the device 2, and the device 2 can set the state of the flag bit 3, while devices such as device 1 that communicate with device 2 cannot set the state of the flag bit 3. In this way, devices such as device 1 that communicate with device 2 do not need to set the flag bit 3, so that devices such as device 1 that communicate with device 2 do not affect the process of device 2 determining whether the audio data is processed.

[0221] It can be understood that in the default state, the flag bit 3 is set to the flag 2. When audio flinger determines that conditions a, b, and c (S804 to S806) are met, the flag bit 3 is set to the flag 1.

[0222] It should be noted that when any one of conditions a, b, and c is not met, audioflinger executes S809, that is, determines whether the audio data of the recording prompt tone is processed based on condition 1 and condition 2. Among them, the order in which audio flinger determines whether conditions a, b, and c are met can also be other orders, that is, the execution order of S804, S805, and S806 can also be replaced with other orders; or, S804, S805, and S806 may not be executed according to the logic shown in method 800. For example, audio flinger can determine whether conditions a, b, and c are met respectively (that is, audio flinger does not determine whether another condition is met when determining that one of the three conditions is met, and S804, S805, and S806 will all be executed). The steps of determining whether conditions a, b, and c are met can be executed in any order or can also be executed in parallel. When audio flinger determines that all three conditions are met, S807 and S808 are executed. When one or more of the three conditions are not met, S809 is executed.

[0223] When AudioFlinger determines that conditions a, b, and c are met, the reason for setting flag bit 3 to flag 1 is as follows.

[0224] Regarding condition a, there is a problem with device 2 looping and playing part of the recording prompt tone, such as looping and playing "start", etc., which may be related to the chip type of device 2. Therefore, in the case of determining the chip type that is likely to cause the problem of looping and playing part of the recording prompt tone, the chip type (i.e., type 1) can be preset in device 2, so that device 2 can determine that the audio data processing is completed through the methods of S807 and S808 when the chip of device 2 is this chip type.

[0225] In this way, when the chip of device 2 is of other types, device 2 can determine whether the audio data is processed based on conditions 1 and 2, that is, when the chip of device 2 is of other types, device 2 can normally determine whether the audio data is processed. When the chip of device 2 is of type 1, AudioFlinger can determine that the audio data processing of the recording prompt tone is completed based on setting flag 1 by flag bit 3.

[0226] Regarding conditions b and c, since the problem of looping and playing part of the recording prompt tone occurs in device 2 during a call, therefore, in the application scenario of playing the recording prompt tone during a call, device 2 can determine that the audio data processing is completed based on setting flag 1 by flag bit 3. In other audio playback scenarios, device 2 can normally determine whether the audio data is processed based on conditions 1 and 2. This minimizes the impact on playing other audio while solving the problem of looping and playing part of the recording prompt tone.

[0227] When flag bit 3 is set to flag 1, AudioFlinger executes S807, that is, sets flag bit 3 to flag 1.

[0228] When flag bit 3 is flag 1, it means that the chip type of device 2 is likely to cause the problem of looping and playing the recording prompt tone, and device 2 is playing the recording prompt tone during a call. Therefore, AudioFlinger can determine that the audio data processing of the recording prompt tone is completed based on setting flag 1 by flag bit 3, and AudioFlinger can execute S808 to set flag 1 to true.

[0229] In this way, device 2 can release the control block. During the next playback of the recording prompt tone by device 2, if the address of the newly created shared memory is the same as that of the shared memory created by S706, and the status of the flag bit in the control block included in the newly created shared memory is the default value, then during the next playback of the recording prompt tone by device 2, device 2 can determine that the control block included in the newly created shared memory is in a normal state (i.e., not an invalid state), so that it can avoid loop-playing part of the recording prompt tone.

[0230] S809. The audio flinger determines whether the audio data of the recording prompt tone has been processed based on condition 1 and condition 2.

[0231] Exemplarily, the audio flinger can determine whether it has been processed through function callback. For example, the audio flinger calls the track->presentationComplete method to determine whether condition 1 and condition 2 are met.

[0232] In one case, if condition 1 and / or condition 2 are not met, the audio flinger determines again whether condition 1 and condition 2 are met until the audio flinger determines that condition 1 and condition 2 are met, then the audio flinger can determine that the audio data of the recording prompt tone has been processed.

[0233] In another case, if condition 1 and / or condition 2 are not met, the audio flinger determines again whether condition 1 and condition 2 are met until the number of determinations by the audio flinger is greater than or equal to 127 times, then the audio flinger determines that the audio data of the recording prompt tone has not been processed.

[0234] It should be understood that 127 times is only an example, and this number can also be replaced by other numbers, and the present application does not make specific limitations in this regard.

[0235] Condition 1 is that the number of frames of the audio data written by the application framework layer to the HAL layer is greater than or equal to the number of frames of the audio data of the recording prompt tone. Among them, the number of frames of the audio data written by the application framework layer to the HAL layer can also be understood as: the number of frames of the decoded PCM stream obtained by the audio flinger from the shared memory, or the number of frames of the audio data 1 transmitted by the audio flinger to the HAL layer. The number of frames of the audio data of the recording prompt tone can also be understood as the number of frames of the audio data written by the media playback service to the shared memory.

[0236] The audio flinger can calculate the number of frames of the audio data written by the media playback service to the shared memory based on parameters such as the sampling rate and bit depth of the audio data.

[0237] Condition 2 is that the number of frames of the audio data received by the kernel layer is less than the number of frames of the audio data written by the application framework layer to the HAL layer. Among them, the number of frames of the audio data received by the kernel layer can also be understood as the number of frames of audio data 2 obtained by the audio driver, and audio flinger can obtain the number of frames of the audio data received by the kernel layer by calling interfaces, etc.; the number of frames of the audio data written by the application framework layer to the HAL layer can also be understood as: the number of frames of the decoded PCM stream obtained by audio flinger from the shared memory, or the number of frames of audio data 1 transmitted by audio flinger to the HAL layer.

[0238] When audio flinger determines that the audio data processing of the recording prompt tone is completed, S808 is executed.

[0239] When audio flinger determines that the audio data of the recording prompt tone is not processed completely, S810 is executed, and flag bit 2 is set to true.

[0240] Exemplarily, audio flinger can call the Track::invalidate method to set flag bit 2 to true. In this way, during the next playback of the recording prompt tone on device 2, if the shared memory allocated to the newly created control block has the same address as the shared memory created in S706, the flag bit 2 in the newly created control block is set to true, so that device 2 may loop through the Figure 4 shown process.

[0241] Figure 9 This is a schematic flowchart of the audio processing method 900 provided by the embodiments of this application. Some steps in method 900 can also be understood as the implementation manners of some steps in method 800. Method 900 includes the following steps:

[0242] S901. The media playback module calls AudioTrack::start(), that is, the media playback module calls the start() method in AudioTrack.

[0243] Furthermore, AudioTrack can instruct audio flinger to start playing audio.

[0244] S902. Audio flinger wakes up (or creates) the MixerThread.

[0245] S903. The audio flinger executes the thread loop (threadLoop) through the mixing thread. The thread loop includes the following three processes: Process 1: Call prepareTracks_l to perform preparations before mixing; Process 2: Call threadLoop_mix to mix the audio data to obtain Audio Data 1; Process 3: Call threadLoop_write to output Audio Data 1, that is, transfer Audio Data 1 to the audio module in the HAL layer.

[0246] It can be understood that in combination with S707, since AudioTrack continuously writes audio data into the shared memory, the audio flinger also needs to continuously obtain and process the audio data from the shared memory. Therefore, the audio flinger can execute the thread loop periodically, for example, execute the thread loop once every 20 ms. In this way, the audio flinger can continuously transfer the newly mixed audio data (Audio Data 1) to the HAL layer, so that Device 2 can play the recording prompt sound normally.

[0247] Among them, Process 1 in the thread loop can be understood as S708 in Method 700; Process 2 in the thread loop can be understood as S709 in Method 700; Process 3 in the thread loop can be understood as S710 in Method 700.

[0248] When the audio flinger determines that the playback of the recording prompt sound terminates (such as in S802 and S803), the audio flinger can execute S904, that is, determine whether the audio data of the recording prompt sound has been played completely.

[0249] It should be understood that the implementation manner of S904 is similar to the implementation manners of S804 to S809 in Method 800. That is, the audio flinger first determines whether Conditions a, b, and c are met; if so, set the flag bit 3 to flag 1 and determine that the audio data of the recording prompt sound has been played completely. If one or more of Conditions a, b, and c are not met, execute S809. For specific details, please refer to the above description and will not be elaborated here.

[0250] When the audio flinger determines that the audio data of the recording prompt sound has been played completely, execute S905 and S906;

[0251] When the audio flinger determines that the audio data of the recording prompt sound has not been played completely, execute S907 to S910.

[0252] S905. The audio flinger sets the flag bit 1 to true.

[0253] S906. The audio flinger releases the control block.

[0254] S907. The audio flinger adds the audio track to Queue 1. Queue 1 is used to record the audio tracks to be deleted.

[0255] Exemplarily, the audio flinger can add the audio track to Queue 1 by calling tracksToRemove->add(track). This audio track can be, for example, the audio track created by the media playback service in S702.

[0256] S908. The audio flinger deletes the audio track.

[0257] Exemplarily, the audio flinger can delete the audio track by calling removeTracks_I(*tracksToRemove).

[0258] S909. The audio flinger terminates the playback of the audio data of the recording prompt tone.

[0259] Exemplarily, the audio flinger can stop the current audio playback by calling stopOutput.

[0260] S910. The audio flinger calls Track::invalidate to set the flag bit 2 to true.

[0261] It should be understood that S907 to S910 can also be understood as an implementation manner of S810.

[0262] It should be noted that in the embodiments of the present application, the marks or information set by each flag bit (such as true in the above text) are all examples, and the marks or information set by each flag bit in various cases can also be replaced by others. The present application does not make specific limitations on this.

[0263] It should also be noted that in addition to the mflags field, the control block can further include various parameters. These various parameters can include, but are not limited to, one or several of the following: mBufferSizeInFrames, which is used to indicate the size of the buffer so that the amount of audio data written by Device 2 to the buffer does not exceed this size; mFront, which is used to indicate the position of reading the audio data in the buffer; or mRear, which is used to indicate the position of writing the audio data to the buffer, etc. The embodiments of the present application do not make specific limitations on other information included in the control block.

[0264] It should be understood that the magnitudes of the serial numbers in the above embodiments do not imply the order of execution. The order of execution of each process should be determined according to its function and internal logic.

[0265] The method for executing animation effects in the embodiments of the present application has been described above. Next, the device for executing the above method provided in the embodiments of the present application will be described. Those skilled in the art can understand that the method and the device can be combined and cited with each other. The related device provided in the embodiments of the present application can execute the steps in the above method for sorting the list.

[0266] To facilitate understanding of this solution, first, in combination with Figure 10 the hardware structure of the electronic device 1000 will be described. The electronic device 1000 can be, for example, the device 1 or the device 2 in the above text.

[0267] Figure 10 is a schematic structural diagram of the electronic device 1000 provided in the embodiments of the present application. As Figure 10 shown, the electronic device 1000 may include a processor 1010, an external memory interface 1020, an internal memory 1021, a universal serial bus (USB) interface 1030, a charging management module 1040, a power management module 1041, a battery 1042, an antenna 1, an antenna 2, a mobile communication module 1050, a wireless communication module 1060, an audio module 1070, a sensor module 1080, a button 1090, an indicator 1092, a camera 1093, and a display screen 1094, etc.

[0268] Among them, the audio module 1070 may include, but is not limited to: a speaker, a receiver, a microphone, and a headphone interface, etc. The speaker can be used to play a recorded prompt tone.

[0269] The sensor module 1080 may include, but is not limited to, one or more of the following sensors: a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, and a bone conduction sensor, etc.

[0270] It can be understood that the structure schematically shown in the embodiments of the present application does not constitute a specific limitation on the electronic device 1000. In other embodiments of the present application, the electronic device 1000 may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or have different component arrangements. The components shown in the figure can be implemented in hardware, software, or a combination of software and hardware.

[0271] The processor 1010 may include one or more processing units. For example, the processor 1010 may include an application processor (AP), a modem processor (Modem), a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Optionally, a memory may also be provided in the processor 1010 for storing instructions and data. Among them, different processing units may be independent devices or integrated in one or more processors.

[0272] The wireless communication function of the electronic device 1000 may be implemented by the antenna 1, antenna 2, the mobile communication module 1050, the wireless communication module 1060, the modem processor (Modem), and the baseband processor, etc.

[0273] Exemplarily, Device 1 or Device 2 may communicate with a network device through the Modem. Device 1 may send data packets to the network device through the Modem; the network device may send the data packets from Device 1 to Device 2, and Device 2 may receive the data packets through the Modem.

[0274] The electronic device 1000 implements the display function through the GPU, the display screen 1094, and the application processor, etc. The GPU is a microprocessor for image processing, connected to the display screen 1094 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 1010 may include one or more GPUs, which execute program instructions to generate or change display information.

[0275] The display screen 1094 is used to display images, videos, etc. In some embodiments, the electronic device 1000 may include 1 or N display screens 1094, where N is a positive integer greater than 1.

[0276] The external memory interface 1020 may be used to connect to an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 1000. The internal memory 1021 may be used to store computer-executable program code, and the executable program code includes instructions.

[0277] Figure 11Schematic block diagram of an animation effect execution device 1100 provided by an embodiment of the present application. The device 1100 includes a processor 1101, a communication interface 1102, and a memory 1103. Among them, the processor 1101, the communication interface 1102, and the memory 1103 communicate with each other through an internal connection path. The memory 1103 is used to store instructions, and the processor 1101 is used to execute the instructions stored in the memory 1103. The communication interface 1102 can be used to send signals to other devices (such as the processor 1101 or the touch screen of an electronic device), and can also be used to receive signals from other devices (such as the memory 1103). Exemplarily, the communication interface 1102 reads the instructions stored in the memory 1103 and sends the instructions to the processor 1101.

[0278] It should be understood that the device 1100 may specifically be the device 1 or the device 2 in the above embodiment, and may be used to execute each step and / or process corresponding to the device 1 or the device 2 in the above method embodiment. Optionally, the memory 1103 may include a read-only memory and a random access memory, and provide instructions and data to the processor. A part of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type. The processor 1101 may be used to execute the instructions stored in the memory, and when the processor 1101 executes the instructions stored in the memory, the processor 1101 is used to execute each step and / or process of the above method embodiment.

[0279] It should be understood that in the embodiment of the present application, the processor may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0280] In the implementation process, each step of the above method may be completed by the integrated logic circuit in the hardware of the processor or the instructions in the form of software. The steps of the method disclosed in combination with the embodiments of the present application may be directly embodied as being executed and completed by the hardware processor, or executed and completed by a combination of the hardware and software modules in the processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor executes the instructions in the memory and combines its hardware to complete the steps of the above method. To avoid repetition, it will not be described in detail here.

[0281] The dynamic effect execution method provided by the embodiments of the present application can be applied to an electronic device with communication functions. The electronic device includes a terminal device, and the specific device form of the terminal device and the like can refer to the above relevant description, which will not be elaborated here.

[0282] The embodiments of the present application provide an electronic device, which includes: a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, so that the electronic device executes the above method.

[0283] The embodiments of the present application provide a chip. The chip includes a processor, and the processor is used to call a computer program in the memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those of the above relevant embodiments, which will not be elaborated here.

[0284] The embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the above method is implemented. The methods described in the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. If implemented in software, the functions can be stored as one or more instructions or codes on a computer-readable medium or transmitted on a computer-readable medium. The computer-readable medium can include a computer storage medium and a communication medium, and can also include any medium that can transmit a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0285] In a possible implementation, the computer-readable medium can include RAM, ROM, a compact disc read-only memory (CD-ROM), or other optical disc memories, magnetic disk memories, or other magnetic storage devices, or any other medium targeted to carry or store the required program code in the form of instructions or data structures and accessible by a computer. Moreover, any connection is properly referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. As used herein, disk and disc include optical disc, laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically, while discs reproduce data optically using a laser. The above combinations should also be included within the scope of the computer-readable medium.

[0286] An embodiment of the present application provides a computer program product. The computer program product includes a computer program, and when the computer program is run, it causes a computer to execute the above method.

[0287] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, and the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable devices to generate a machine, so that the instructions executed by the processing unit of the computer or other programmable data processing devices generate a device for realizing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 a block or multiple blocks.

[0288] The above specific implementation manners further elaborate on the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are only specific implementation manners of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solution of the present invention shall be included in the protection scope of the present invention.

Claims

1. An audio processing method, characterized in that: Applied to a first device, the method includes: During a voice call between the first device and the second device, receiving first information from the second device, where the first information is used to instruct to play a first recorded prompt tone; In response to the first information, the first device plays the first recorded prompt tone; When the first recording prompt tone is not played completely, the first device interrupts playing the first recording prompt tone, and the first device marks that the audio stream processing of the first recording prompt tone is completed.

2. The method according to claim 1, characterized in that The first device marks that the audio stream processing of the first recording prompt tone is completed, including: When a first condition is met, the first device marks that the audio stream processing is completed, and the first condition includes one or more of the following: The chip of the first device is of a first preset type; The playback path of the audio stream is the first path; or, The type of the audio stream is a second preset type.

3. The method according to claim 2, characterized in that The first device marking that the audio stream processing is completed includes: When the first condition is met, setting the first flag bit to a first state; Based on the first flag bit being in the first state, the first device marks the audio stream processing completed.

4. The method according to any one of claims 1 to 3, characterized in that The first device interrupting the playing of the first recorded prompt tone includes: The first device receives second information from the second device, where the second information is used to instruct to play a second recorded prompt tone; In response to the second information, the first device interrupts playing the first recorded prompt tone and plays the second recorded prompt tone.

5. The method according to any one of claims 1 to 3, characterized in that The first device interrupting the playing of the first recorded prompt tone includes: Based on the interruption of the voice call between the first device and the second device, the first device interrupts playing the first recorded prompt tone.

6. The method according to claim 1 or 2, characterized in that: The first device marks that the audio stream processing of the first recording prompt tone is completed, including: The second flag bit is set to a second state, and the second flag bit being in the second state indicates that the audio stream processing is completed.

7. The method according to claim 6, characterized in that The second flag bit is set in a control block corresponding to the audio stream.

8. The method according to any one of claims 1 to 3, characterized in that The first device comprises an audio mixer; The first device marks that the audio stream processing of the first recording prompt tone is completed, including: The audio mixer marks that the audio stream processing of the first recording prompt tone is completed.

9. The method according to any one of claims 1 to 3, characterized in that The receiving first information from the second device includes: A data packet is received from the second device, where the data packet includes an audio stream of the first recording prompt tone and the first information.

10. An electronic device, characterized in that: The electronic device comprises: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors call the computer instructions so that the electronic device executes the method as described in any one of claims 1 to 9.

11. A chip system, characterized in that: The chip system is applied to an electronic device, and the chip system includes one or more processors, and the one or more processors are used to call computer instructions so that the electronic device executes the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises computer instructions, and when the computer instructions are executed on an electronic device, the electronic device is caused to perform the method as claimed in any one of claims 1 to 9.

13. A computer program product, characterized in that The computer program product comprises a computer program code, and when the computer program code is run on an electronic device, the electronic device is caused to perform the method according to any one of claims 1 to 9.

Images