Audio processing method and device

Abstract

The embodiment of the invention provides an audio processing method and device, and relates to the technical field of terminals. The method comprises the following steps: in the process of voice communication between first equipment and second equipment, receiving first information from the second equipment, the first information being used for indicating to play a first recording prompt tone; in response to the first information, the first device plays a first recording prompt tone; and when the first recording prompt tone is not completely played, the first device interrupts playing of the first recording prompt tone, and the first device marks that processing of the audio stream of the first recording prompt tone is completed. Therefore, under the condition that playing of the recording prompt tone is interrupted, the electronic equipment can also mark that processing of the audio stream of the recording prompt tone is completed, and the phenomenon that the recording prompt tone played subsequently is abnormal can be reduced.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to an audio processing method and device. Background Art

[0002] Most electronic devices can record during a call. In order to meet user needs, when two electronic devices are talking and one of them is recording the call, both electronic devices can play a recording prompt tone. For example, during a call between a first device and a second device, in response to a user input operation 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 "start recording".

[0003] However, if the first device interrupts playing the recorded prompt tone before the recorded prompt tone is played completely, it may cause playback abnormality when the recorded prompt tone is played again later. Summary of the invention

[0004] The embodiment of the present application provides an audio processing method and device, which is applied to the field of terminal technology. After the first device interrupts playing the recording prompt sound, the first device can mark the audio stream processing of the recording prompt sound as completed, thereby reducing the phenomenon of subsequent abnormal playback of the recording prompt sound and improving the user experience.

[0005] In the first aspect, the embodiment of the present application proposes an audio processing method. The method includes: during a voice call between a first device and a second device, receiving a first message from the second device, the first message being used to instruct to play a first recording prompt tone; in response to the first message, the first device plays the first recording prompt tone; if the first recording prompt tone is not played completely, the first device interrupts the playing 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] 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 information 1 in data packet 1. The first recording prompt tone may be "stop recording" in method 800. The first device marks the completion of the audio stream processing of the first recording prompt tone, for example, by 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 in S706.

[0007] In the audio processing method of the present application, when the first recording prompt tone is not played completely and the first device interrupts playing the first recording prompt tone, the first device marks the audio stream of the first recording prompt tone as completed. In this way, when the first device plays the recording prompt tone again later, the subsequent recording prompt tone will not be abnormally played due to the fact that the audio stream marked as not completed is not processed this time.

[0008] In combination with the first aspect, in certain implementations of the first aspect, the first device marks that the audio stream processing of the first recording prompt sound 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 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 may be condition a, condition b and condition c as described below. The chip of the first device is of the first preset type may be condition a as described below, and the first preset type may be type 1 as described below. The playback path of the audio stream is the first path may be condition b as described below, and the first path may be the preset path as described below. The type of the audio stream is the second preset type may be condition c as described below, and the second preset type may be type 2 as described below.

[0010] In this way, after the first device interrupts playing the first recording prompt tone, it can mark the audio stream processing of the first recording prompt tone as completed when it is determined that the chip of the first device is prone to the problem of looping the recording prompt tone, and / or when it is determined that the recording prompt tone is currently being played during a call. This allows the first device to normally determine whether the audio processing is completed in other scenarios or when other chips are set. While reducing abnormal playback of the recording prompt tone, the impact on the first device processing other audio data is small.

[0011] In combination with the first aspect, in some implementations of the first aspect, the first device marks the audio stream processing as completed, including: when a first condition is met, setting the first mark bit to a first state; based on the first mark bit being in the first state, the first device marks the audio stream processing as completed.

[0012] The first flag bit may be flag bit 3 mentioned below. The first state may be flag 1 mentioned below.

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

[0014] In combination with the first aspect, in certain implementations of the first aspect, the first device interrupts playing the first recorded prompt tone, including: the first device receives second information from the second device, the second information is used to indicate playing the 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.

[0015] The second information may be information 2 in data packet 2 described below. The second recording prompt tone may be “start recording” in method 800 .

[0016] In this way, when the first device interrupts playing the first recorded prompt sound due to the user's input operation on the second device, the first device can also mark the audio stream processing of the first recorded prompt sound as completed, thereby reducing the phenomenon of abnormal subsequent playback of the recorded prompt sound by the first device.

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

[0018] In this way, when the first device interrupts playing 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 audio stream processing of the first recorded prompt tone as completed, thereby reducing the phenomenon of abnormal subsequent playback of the recorded prompt tone by the first device.

[0019] In combination with the first aspect, in certain implementations of the first aspect, the first device marks that the audio stream processing of the first recording prompt sound is completed, including: setting the second mark bit to a second state, and the second mark bit being in the second state indicates that the audio stream processing of the first recording prompt sound is completed.

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

[0021] In this way, the first device can determine that the audio stream processing of the first recording prompt sound is completed based on the second mark bit, so that the first device can release the control block corresponding to the audio stream of the first recording prompt sound. When the first device subsequently plays a new recording prompt sound and creates a control block corresponding to the new recording prompt sound, if the control block corresponding to the new recording prompt sound has the same shared memory address as the control block corresponding to the audio stream of the first recording prompt sound, the mark bit in the control block corresponding to the new recording prompt sound can be in the initial state, thereby reducing the phenomenon of abnormal playback of the recording prompt sound 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 a control block corresponding to the audio stream.

[0023] 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 implementations of the first aspect, the first device includes an audio mixer audioflinger; the first device marks that the audio stream processing of the first recording prompt sound is completed, including: the audio mixer marks that the audio stream processing of the first recording prompt sound is completed.

[0025] In this way, the audio mixer can mark the audio stream processing of the first recording prompt sound as completed when the first device interrupts playing the first recording prompt sound, so that when the first device plays the recording prompt sound again later, the abnormal state of the first recording prompt sound will not cause the subsequent recording prompt sound to be played abnormally.

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

[0027] The data packet may be data packet 1 mentioned below. The audio stream of the first recorded prompt tone may be audio data in data packet 1, and the first information may be information 1 in data packet 1.

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

[0029] In the second aspect, an embodiment of the present application provides a device, which may be an electronic device, or a chip or chip system in an electronic device. The motion effect execution device may include a transceiver unit, an audio playback unit, and a processing unit. When the device is an electronic device, the transceiver unit may be a transceiver, the audio playback unit may be a speaker or a headset, etc., and the processing unit may be a processor. The device may also include a storage unit, which may 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 the first aspect or any possible implementation of the first aspect. A method for audio processing described in a method. When the device is a chip or a chip system in an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit so that the electronic device implements the first aspect or any possible implementation of the first aspect. A method for audio processing described in a method. The storage unit may be a storage unit in the chip (for example, a register, a cache, etc.), or a storage unit in the electronic device located outside the chip (for example, a read-only memory, a random access memory, etc.). The transceiver unit may be, for example, Mdoem, etc.

[0030] Exemplarily, the transceiver unit is used to receive the first information from the second device; the audio playback unit is used to play the first recording prompt tone; and the processing unit is used to mark that the audio stream processing of the first recording prompt tone is completed.

[0031] In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a memory, the memory being used to store code instructions, and the processor being used to run the code instructions to execute the method described in the first aspect or any possible implementation 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 instructions are stored. When the computer program or instructions are run on a computer, the computer executes the method described in the first aspect or any possible implementation 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 executes 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 chip system comprising at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and 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 of the first aspect. The communication interface in the chip can be an input / output interface, a pin or a circuit, etc.

[0035] In a possible implementation, the chip or chip system described above in the present application further includes at least one memory, in which instructions are stored. The memory may be a storage unit inside the chip, such as a register, a cache, etc., or a storage unit of the chip (e.g., 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 achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 2 A schematic diagram of a process of looping and playing a recorded reminder tone;

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

[0040] Figure 4 A schematic diagram of a process of looping a recorded reminder tone;

[0041] Figure 5 A schematic diagram of the software and hardware interaction process of an electronic device provided in an embodiment of the present application;

[0042] Figure 6 A schematic block diagram of a multimedia architecture provided in an embodiment of the present application;

[0043] Figure 7 A flowchart of an audio processing method provided in an embodiment of the present application;

[0044] Figure 8 A flowchart of another audio processing method provided in an embodiment of the present application;

[0045] Fig. 9 A flowchart of another audio processing method provided in an embodiment of the present application;

[0046] Fig.10 A schematic block diagram of a hardware architecture of an electronic device provided in an embodiment of the present application;

[0047] Fig.11 A schematic block diagram of an audio processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] In order to clearly describe the technical solutions of the embodiments of the present application, some terms and technologies involved in the embodiments of the present application are briefly introduced below:

[0049] 1. Thread: It is an execution unit in a process. A process can contain one or more threads, which 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.*: is a package of classes and interfaces used to handle multimedia functions in the Android operating system. This package provides a rich API for managing and operating multimedia content such as audio, video, and images. The following are some common sub-packages and classes:

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

[0053] 4. Other terms

[0054] In the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same functions and effects. For example, the first chip and the second chip are only used to distinguish different chips, and their order is not limited. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be 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 descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0056] In the embodiments of the present application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, c can be single or multiple.

[0057] 5. Electronic equipment

[0058] The electronic devices of the embodiments of the present application may include handheld devices, vehicle-mounted devices, etc. with face recognition functions. For example, some electronic devices are: mobile phones, tablet computers, PDAs, laptop computers, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to wireless modems, vehicle-mounted devices, wearable devices, terminal devices in 5G networks or future evolved public land mobile communication networks (PLANs), and wireless terminals in smart cities. The embodiments of the present application do not limit this.

[0059] As an example but not limitation, in the embodiments of the present application, the electronic device may also be a wearable device. Wearable devices may also be referred to as wearable smart devices, which are a general term for wearable devices that are intelligently designed and developed using wearable technology for daily wear, such as glasses, gloves, watches, clothing, and shoes. A wearable device is a portable device that is worn directly on the body or integrated into the user's clothes or accessories. Wearable devices are not only hardware devices, but also powerful functions achieved through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include full-featured, large-sized, and fully or partially independent of smartphones, such as smart watches or smart glasses, as well as devices that only focus on a certain type of application function and need to be used in conjunction with other devices such as smartphones, such as various types of smart bracelets and smart jewelry for vital sign monitoring.

[0060] In addition, in the embodiments of the present application, the electronic device can also be a terminal device in the Internet of Things (IoT) system. 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, thereby realizing an intelligent network that interconnects people and machines and things.

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

[0062] In an embodiment 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 called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux operating system, Unix operating system, Android operating system, iOS operating system, or Windows operating system. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0063] At present, some electronic devices can record the content of a call during a call. In addition, in response to an input operation 1 of a user on an electronic device at the other end, input operation 1 indicates the start of recording, and both the electronic device at the local end and the electronic device at the other end can play voice prompt 1, and voice prompt 1 prompts the user to start recording. Voice prompt 1 can be, for example, "Start recording." Afterwards, in response to an input operation 2 of a user on an electronic device at the other end, input operation 2 indicates the end of recording, and both the electronic device at the local end and the electronic device at the other end can play voice prompt 2, and voice prompt 2 prompts the user to end recording. Voice prompt 2 can be, for example, "Stop recording."

[0064] For ease of description, the other electronic device is referred to as device 1, 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 to start recording and an operation to end recording on device 1. For brevity, this will not be described in detail below.

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

[0066] For example, Figure 1 As shown, during the call between device 1 and device 2, device 1 can display Figure 1 In response to the user clicking the recording button 101, device 1 starts recording. Both device 1 and device 2 can play "Start recording". In response to the user clicking the recording button 101, device 1 can display Figure 1 In the interface (b), the time below the recording button 102 is the recording duration. Afterwards, in response to the user clicking the recording button 102, the device 1 ends the recording. Both the device 1 and the device 2 can play "Stop Recording".

[0067] It should be noted that the above call can be initiated by device 1 or device 2. This application does not make any specific limitation 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, device 2 may play part of the recorded prompt sound in a loop. Exemplarily, in response to the user's input operation 1 on device 1, device 2 plays part of the voice prompt sound in a loop. For example, "start" is played in a loop, so that the user of device 2 hears "start start start start...", which makes the user experience poor.

[0069] Combine the following Figure 2 , a possible scenario of device 2 playing “start” in a loop is described.

[0070] For example, assume that at time t1, device 1 and device 2 establish call 1; at time t2 after time t1, call 1 is still going on, and in response to user 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 finished playing "start", and call 1 between device 1 and device 2 ends. And because call 1 between device 1 and device 2 ends, device 2 stops playing "start recording".

[0071] At time t4 after time t3, device 1 establishes call 2 with device 2; at time t5 after time t4, call 2 is still being recorded, and 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 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", and 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 play part of the audio in "start recording" in a loop, for example, playing "start" in a loop. As a result, the user of device 2 hears "start start start...", resulting in a poor user experience.

[0072] pass Figure 2 It can be seen from the process shown that for device 2, before looping the partial audio in "Start Recording", the audio playback of device 2 was abnormally terminated twice. That is, at time t3, call 1 ended before the playback of "Start Recording" was completed, so the playback of "Start Recording" was abnormally terminated; at time t8, the user instructed to start recording again before the playback of "Stop Recording" was completed, so the playback of "Stop Recording" was abnormally terminated.

[0073] It should be understood that Figure 2 The illustrated scenario is only an example, in which different devices may establish call 1 and call 2 with device 2. For example, the device that establishes call 1 with device 2 is device 1-1, and the device that establishes call 2 with device 2 may be device 1-2, etc. This application does not make specific limitations on this.

[0074] It can be seen that the loop playback of part of the audio in "Start Recording" by device 2 may be related to the abnormal termination of the previous two audio playbacks, as follows.

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

[0076] For the convenience of description, the control block created by device 2 is called control block 1, the shared memory allocated to the control block is called shared memory 1, and the cache included in shared memory 1 is called cache 1. Figure 3 As shown, the shared memory 1 includes a control block 1 and a cache 1.

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

[0078] Mark bit 1 can be used to indicate that the audio data (or audio stream) has been processed or has been processed. For example, when mark bit 1 is set to true (true), it indicates that the audio data processing is completed and device 2 can release control block 1. Mark bit 2 can be used to indicate that the control block is in an invalid state. For example, when mark bit 2 is set to true (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 process of the control block, resulting in its inability to be used normally; the resources on which the control block depends (such as memory, file handles, etc.) are unavailable or have been released; the control block has entered a certain error state and cannot continue normal operation; the control block has been released or destroyed and is no longer valid.

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

[0081] When device 2 determines that the playback of a recorded prompt tone is interrupted (which can also be replaced by pause or termination), device 2 can determine whether the audio data of the recorded prompt tone has been processed; if so, device 2 can set flag bit 1 to true; if not, device 2 can set flag bit 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 completion of the processing of the audio data written in the cache 1 by the device 2. The completion of the audio data processing of the recording prompt tone does not limit the device 2 to completely play 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 to have finished playing "start recording". When the device 2 stops playing "start recording" after playing "start", the device 2 may also determine that the audio data processing of "start recording" is completed. This is because the storage space of the cache 1 is limited, so the device 2 may not start reading "start recording" after writing all the audio data of "start recording" into the cache 1.

[0083] Device 2 may continuously write audio data to cache 1 on the one hand, and read and play audio data on the other hand. Therefore, after "start recording" is terminated, part of the audio data of "start recording" may be written into cache 1. Device 2 determines that the processing of the audio data of "start recording" is completed when device 2 determines that the processing of the part of the audio data is completed (or the processing is completed).

[0084] When the flag bit 1 is true, it indicates that the audio data processing of the recorded prompt tone being played this time is completed, so that the device 2 can release the control block 1 through a callback function or the like, so that the next time the device 2 allocates shared memory 1 for the newly created control block, 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 value).

[0085] When the flag bit 2 is true, it means that the audio data of the recording prompt tone has not been processed, and 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 the 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 and 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] For example, in combination Figure 2In the process shown, the "Start Recording" played by device 2 at time t3 is abnormally terminated. Assume that when playing the recording prompt tone, device 2 creates 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 is abnormally terminated, device 2 determines that the audio data of "Start Recording" has not been processed, so device 2 sets the flag bit 2 in control block a to true.

[0087] In addition, when the "Stop Recording" played by device 2 at time t8 is abnormally terminated, it is assumed that when playing the recording prompt tone, device 2 creates 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 is abnormally terminated, device 2 determines that the audio data of "Stop Recording" has not been processed, so device 2 sets 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 the historical moment. So at time t8, in response to the user's input operation 1 on device 1, device 2 stops playing "Stop Recording" and starts playing "Start Recording". During this process, device 2 creates the audio stream corresponding to "Start Recording" AudioTrack 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 mark bit in control block c will reuse the state of the mark bit in control block a or control block b, that is, the state of mark bit 2 in control block c is true. Based on the fact that mark bit 2 is true, device 2 will determine that control block c is invalid, and will create the audio track in a loop, and start playing the recording prompt tone in a loop. The details are 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 buffer of shared memory c, that is, start playing "start recording".

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

[0092] The current control block is the control block created last by device 2 each time S402 is executed. Figure 4 In the process shown, the current control block may be control block c. Then, the second execution Figure 4 When the flow is shown, the current control block may be executed for the first time. Figure 4The new control block created by the process (S405) shown.

[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 audio track is created.

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

[0096] S405, device 2 creates an AudioTrack corresponding to the new audio track and a new control block. The shared memory corresponding to the new control block may be shared memory a or shared memory b, so 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 reads the flag bit 2 in the current control block (new control block) in S402 again as true, so that device 2 may continue to execute in a loop. Figure 4 Thus, device 2 starts playing "start recording" continuously.

[0098] Device 2 is repeatedly executing Figure 4 During the process shown, 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 the device restarts playing "Start Recording" based on the new track, the currently playing "Start Recording" may not be played completely, 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". The user continuously hears part of the audio of "Start Recording", for example, "Start Start Start Start..."

[0099] It can be seen that the cause of the above problem is that at time t3, device 2 determines that the audio data of "start recording" has not been processed, so that device 2 sets the mark bit 2 in control block a to true, and then device 2 does not release control block a; and at time t8, it determines that the audio data of "stop recording" has not been processed, so that device 2 sets the mark bit 2 in control block b to true, and then device 2 does not release control block b. Further, when device 2 subsequently plays the recording prompt tone and creates control block c, when the shared memory allocated to control block c is the same as shared memory a (or shared memory b), control block c reuses the state of the mark bit in control block a (or control block b), and then device 2 determines that control block c is abnormal (invalid).

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

[0101] Device 2 determines whether the audio data of the recording prompt tone has been processed or not, usually in the following manner: 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, 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). If Device 2 determines that Condition 1 and Condition 2 are satisfied, it determines that the audio data of the recording prompt tone has been processed; if Device 2 determines that Condition 1 and / or Condition 2 are not satisfied for multiple consecutive times, it determines that the audio data of the recording prompt tone has not been processed.

[0102] Exemplarily, device 2 may call a function to determine whether condition 1 and condition 2 are satisfied; if device 2 determines that condition 1 and / or condition 2 are not satisfied, device 2 again determines whether condition 1 and condition 2 are satisfied. If device 2 determines that condition 1 and / or condition 2 are not satisfied for multiple consecutive times (e.g., 127 times), device 2 determines that the audio data of the recording prompt tone has not been processed, and sets flag bit 2 to true.

[0103] In view of this, the present application provides an audio processing method, in which during a call between device 1 and device 2, when device 2 plays a recording prompt tone in response to a user input operation on device 1, after the recording prompt tone stops playing, device 2 marks that the audio data processing of the recording prompt tone is completed. In this way, after device 2 stops playing the recording prompt tone, device 2 will not set the mark bit 2 to true due to judging that the audio data of the recording prompt tone has not been processed. The mark bit included in the control block created in the subsequent playback of the recording prompt tone by device 2 can be in the initial state, thereby reducing the abnormal phenomenon of looping the recording prompt tone due to the mark bit 2 in the created control block being true, so that device 2 can play the recording prompt tone normally, which can improve the user experience.

[0104] Combine the following Figures 5 to 9 The technical solution of the present application and how the technical solution of the present application solves the above technical problems are described in detail with specific embodiments. The following specific embodiments can be implemented independently or in combination with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

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

[0106] The following describes the embodiment of the present application by taking device 2 as the execution subject as an example. The specific form and quantity of each device shown therein are only examples and should not constitute any limitation on the implementation of the method provided in the present application.

[0107] For ease of understanding, the following Figure 5 , taking the layered architecture Android system as an example, the software architecture of device 2 is illustrated.

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

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

[0110] 1. Application layer

[0111] The application layer can include a series of application packages. Figure 5As shown, the application package may include applications such as calling, browser, and email.

[0112] 2. Java framework layer, also known as application framework (framework, FWK) layer

[0113] The Java framework layer can provide application programming interface (API) and programming framework for the application program layer. The Java framework layer includes some predefined functions. Figure 5 As shown, the Java framework layer may include a system service startup module, a media player module, a media recorder module, and a radio interface layer (RIL).

[0114] The system server may include an activity manager service, a window manager, a power manager, an input manager, a telephony manager, and the like.

[0115] The media player module, also known as MediaPlayer, can be used to obtain the audio data of the recording prompt tone, and decode the audio data to obtain the decoded pulse code modulation (PCM) stream; and can create an AudioTrack at the FWK layer and transmit the decoded PCM stream to the AudioTrack. The PCM stream can be understood as an audio data stream encoded with PCM.

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

[0117] AudioTrack can transfer the decoded PCM stream to the audio mixer (audio flinger).

[0118] The phone manager is used to provide the terminal's call functions, such as management of call status (including connection, disconnection, etc.). The application framework layer may also include a RIL, and the modem processor (Modem) may exchange information with the phone manager through the RIL to implement the call function of the device 2.

[0119] 3. System services layer

[0120] The system service layer includes various system services, which interact with the application framework layer through the Binder IPC mechanism. The system service layer manages and coordinates system resources and provides core functions for applications.

[0121] The system service layer includes an audio mixer (audio flinger). The audio flinger can obtain the decoded PCM stream from AudioTrack, and perform mixing, sound effects and other processing on the decoded PCM stream to obtain audio data 1; and transmit the audio data 1 to the hardware abstraction layer.

[0122] The audio flinger is also used to determine whether the audio data of the recorded prompt sound has been processed after determining that the playback of the recorded prompt sound has terminated.

[0123] 4. System runtime and system libraries

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

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

[0126] The application layer and the application framework layer run in a 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 object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0127] The system library may include multiple functional modules, such as surface manager, service manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

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

[0129] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding 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 (media player service), etc.

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

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

[0132] 5. Hardware Abstraction Layer

[0133] The hardware abstraction layer (HAL) provides hardware-related abstract interfaces so that upper-level system services and libraries can interact with different hardware.

[0134] HAL includes multiple library modules such as Bluetooth module, camera module, audio module and sensor module, among which each library module can provide an interface for the corresponding hardware component implementation.

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

[0136] 6. Kernel layer (Kernel), also known as Linux Kernel

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

[0138] In addition to the above layered architecture, the device 2 may also be provided with a modem processor (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 This is a schematic block diagram of a multimedia architecture provided in an embodiment of the present application. Figure 6 As shown, the multimedia architecture of device 2 includes application framework layer, native framework layer (Native Framework), HAL and kernel layer. The native framework layer can be understood as Figure 5 Part of the system library 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 may include a media playback module (also known as a media playback APP) and a media recording module (also known as a media recording APP). The application framework layer may also include android.media.*. android.media.* is a package of a group of classes and interfaces used to handle multimedia functions in the Android operating system. android.media.* provides a rich API for managing and operating multimedia content such as audio, video, and images.

[0149] The multimedia architecture also includes the JNI module corresponding to the application framework layer. The API of the application framework layer can call the local framework layer through JNI. The local framework layer can call the media server through the binder inter-process communication (IPC) proxies. The media playback service completes the playback of audio data by interacting with the HAL and 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] The local framework layer may also be provided with C++ source code files, such as AudioTrack.cpp and AudioRecord.cpp.

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

[0153] In addition, the local framework layer may also be provided with other non-binder resources, such as audio resources.

[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 agent can obtain a variety of C++ source code files, such as IAudioRecord.cpp, IAudioTrack.cpp, IAudioFlinger.cpp, and Ibinder.cpp, etc. These files usually contain the definition and implementation 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 the audio policy service, the audio mixer service, and the media player service.

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

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

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

[0160] 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 the HAL interface into instructions that the hardware can understand.

[0161] The kernel layer includes advanced Linux sound architecture (ALSA), open sound system (OOS) or custom driver, etc. Among them, ALSA is a framework and driver collection for audio processing in the Linux operating system. It provides low-level access to audio hardware and supports a variety of audio devices. OSS provides a relatively simple programming interface and supports a variety of audio hardware. Custom driver refers to an audio driver customized for specific hardware or specific needs. Such drivers are usually written by hardware manufacturers or developers of specific applications to meet specific performance, functionality 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 of the embodiments of the present application.

[0163] based on Figure 6 The multimedia framework shown, device 2 can be Figure 7 The illustrated method 700 plays a recorded reminder tone.

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

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

[0166] The recording prompt tone may be a recording prompt tone to be played. For example, in response to the user's input operation 1 on device 1, input operation 1 indicates to start recording, and the recording prompt tone to be played on device 2 may be "start recording"; in response to the user's input operation 2 on device 1, input operation 2 indicates to end recording, and the recording prompt tone to be played on device 2 may be "stop recording". The audio data of the recording prompt tone may be obtained from device 1.

[0167] For example, device 2 receives audio data of a recording prompt tone from device 1 through a modem. The media playback module may determine data source information of the audio data of the recording prompt tone, and indicate the data source information to the media playback service.

[0168] Optionally, in addition to the audio data of the recorded prompt sound, the device 2 can also receive information 1 from the device 1 through the modem, and the information 1 is used to instruct to play the recorded prompt sound. In this way, based on the information 1, the media playback module can execute S701.

[0169] It should be understood that data source information is the source information of audio data, and the media playback service can determine the method of obtaining 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.

[0170] S702: The media playback service creates a media playback instance corresponding to the audio data, namely, an audio track, obtains the audio data of the recorded prompt sound, and prepares to decode and play the audio data.

[0171] For example, if the recording prompt tone with playback is "stop recording", 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 may also be replaced by the media playback module instructing the media playback service to start playing the recording prompt tone 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 recorded prompt tone to obtain a decoded PCM stream.

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

[0175] S706: The media playback service creates a control block and allocates a 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 may be executed in parallel, and S706 may be executed before or after S705, and this application does not make any specific limitation 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 mixer (audio flinger) obtains the decoded PCM stream from the cache of the shared memory.

[0179] S709 , the audio flinger performs mixing and sound effect processing on the decoded PCM stream to obtain audio data 1 .

[0180] S710 , the audio flinger indicates the audio data 1 to the audio module in the HAL.

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

[0182] S712, the audio module in the HAL transmits the audio data 2 to the audio driver, so that the audio driver can drive the audio hardware (such as a digital-to-analog converter, etc.) in the device 2 to play. The audio driver drives 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 a digital signal) into a sound signal (or an analog signal), and plays the sound through an output device such as a speaker or a headset.

[0183] Method 700 shows the process of device 2 playing a voice prompt. Figure 8 The manner in which the device 2 determines whether the audio data has been processed after the device 2 stops playing the recording prompt tone is described in detail.

[0184] It should be noted that Figure 8 The method 800 shown is described by taking the example that the device 2 first plays "Stop Recording" and then the device 2 stops playing "Stop Recording" and starts playing "Start Recording". Figure 2 The device 2 shown starts playing "Stop Recording" at time t7, stops playing "Stop Recording" at time t8 and plays "Start Recording" similarly.

[0185] Figure 8 FIG. 8 is a flow chart of an audio processing method 800 provided in an embodiment of the present application. Figure 8 As shown, method 800 includes the following steps:

[0186] S801: In response to the user's input operation 2 on device 1, device 1 ends recording (e.g. Figure 2 At time t7, device 1 finishes recording, and sends data packet 1 to network devices such as base stations through the modem of device 1. Data packet 1 includes audio data of "stop recording" and information 1; network devices such as base stations send data packet 1 to device 2; device 2 receives data packet 1 from network devices such as base stations through the modem of device 2.

[0187] It is understood that the audio data of "stop recording" shown in S801 is only an example. For example, when device 1 ends recording, the recording prompt sound played by device 1 and device 2 may also be "recording has ended" or the like. Alternatively, S801 may also be that in response to the user's input operation 1 on device 1, device 1 starts recording, and the above-mentioned audio data of "stop recording" may be replaced by the audio data of "start recording".

[0188] It should be understood that the method for device 2 to obtain the audio data of the recording prompt tone shown above is only an example. Device 2 can also obtain the audio data of the recording prompt tone in other ways. For example, device 2 can store the audio data of the recording prompt tone. Then, when device 1 starts recording, information 3 can be sent to device 2 through the network device. Information 3 is used to indicate the playback of the recording prompt tone corresponding to the start of recording. Then device 2 can obtain the audio data of "start recording"; when device 1 stops recording, information 4 can be sent to device 2 through the network device. Information 4 is used to indicate the playback of the recording prompt tone corresponding to the stop of recording. Then device 2 can obtain the audio data of "stop recording". This application does not make specific limitations on this.

[0189] Afterwards, device 2 may play “stop recording” through S701 to S712 .

[0190] In one case, while device 2 is playing “Stop Recording”, in response to the user's input operation 1 on device 1, input operation 1 is used to indicate the start of recording (for example, device 1 starts recording at time t8), device 2 stops playing “Stop Recording” and starts playing “Start Recording” through S701 to S712.

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

[0192] S802. In response to the user's input operation 1 on device 1, device 1 starts recording and sends data packet 2 to a base station or other network device through the modem of device 1. Data packet 2 includes audio data of "start recording" and information 2. Information 2 is used to instruct the base station or other network device to play the recording prompt tone; the base station or other network device sends data packet 2 to device 2; device 2 receives data packet 2 from the base station or other network device through the modem of device 2.

[0193] It is understandable that information 2 and information 1 may be the same, for example, both are used to indicate the playing of the recording prompt tone; or information 2 and information 1 may be different, for example, information 1 is used to indicate the playing of the audio data of "stop recording"; information 2 is used to indicate the playing of the audio data of "start recording", etc. This application does not make specific limitations on this.

[0194] S803, the modem of device 2 instructs the audio flinger recording prompt tone ("stop recording") to stop playing.

[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 stop playing 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 stop playing "stop recording" and start playing "start recording".

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

[0197] Exemplarily, the media playback module may 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 stop playing the recording prompt tone ("stop recording").

[0198] In another case, S802 may also be replaced by: the media playback module calls an interface to determine that the recording prompt tone ("stop recording") has been played, and then the media playback module instructs the audio flinger recording prompt tone ("stop recording") to stop playing.

[0199] In this case, the playing of "Stop Recording" is not interrupted, and device 2 finishes playing "Stop Recording". After the media playing module determines that the playing of "Stop Recording" is finished, the audio flinger can be instructed to stop playing the recording prompt tone ("Stop Recording").

[0200] When the audio flinger determines that the recording prompt tone ("stop recording") stops playing, it can be determined whether the audio data of "stop recording" is processed.

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

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

[0203] Among them, satisfying conditions a, b, and c indicates that the chip of device 2 is prone to abnormal phenomenon of looping recording prompt tone, and device 2 is currently playing recording prompt tone during a call. In this way, when audio flinger determines that the chip of device 2 is prone to abnormal phenomenon of looping recording prompt tone, and device 2 plays recording prompt tone based on the user's input operation on device 1, audio flinger can directly determine that the audio data processing of the recording prompt tone is completed, so that audio flinger can set mark bit 1 to true, and then device 2 can release the control block normally. The state of the mark bit in the control block created by device 2 when playing the recording prompt tone later can be the initial state, which can reduce the abnormal phenomenon of device 2 playing the recording prompt tone.

[0204] The audio flinger determines whether condition a, condition b, and condition c are satisfied as shown in S804, S805, and S806, respectively.

[0205] S804 , the audio flinger determines whether condition a is satisfied, where condition a is that the chip of device 2 is type 1.

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

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

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

[0209] S805 , the audio flinger determines whether condition b is satisfied, where 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 played this time, that is, the playback path of the audio data of "stop recording".

[0211] Exemplarily, the audio flinger may call a function to determine the playback thread (playback Thread) for playing the recording prompt tone ("stop recording"), and the called function may be, for example, mThread promote(). Since the playback thread and the playback path are one-to-one corresponding, the audio flinger may determine the playback path of the recording prompt tone ("stop recording") based on the playback thread. The preset path may be, for example, incall_music_uplink. 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 the audio flinger determines that the recording prompt tone ("stop recording") is not a preset path, the media playback module executes S809.

[0213] When the 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. The audio flinger determines whether condition c is satisfied. Condition c is that the type of the audio stream is type 2.

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

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

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

[0218] S807. The audio flinger sets the marker bit 3 to marker 1.

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

[0220] It should be noted that the flag bit 3 may be a variable or a flag bit set in the device 2, and the state of the flag bit 3 may be set by the device 2, while the device 1 or other devices communicating with the device 2 cannot set the state of the flag bit 3. In this way, the device 1 or other devices communicating with the device 2 may not set the flag bit 3, so that the device 1 or other devices communicating with the device 2 may not affect the process of the device 2 determining whether the audio data is processed.

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

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

[0223] The reason why the flag bit 3 is set to flag 1 when the audio flinger determines that conditions a, b, and c are satisfied is as follows.

[0224] For condition a, the problem of looping the playback of part of the recording prompt tone in device 2, such as looping the playback of "start", may be related to the chip type of device 2. Therefore, when the chip type that is likely to cause the problem of looping the playback of part of the recording prompt tone is determined, 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 S807 and S808 when the chip of device 2 is of 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 processing is completed 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 processing is completed. When the chip of device 2 is type 1, audio flinger can set flag 1 based on flag bit 3 to determine that the audio data processing of the recording prompt tone is completed.

[0226] For conditions b and c, since the problem of looping some recorded prompt tones occurs in device 2 during a call, in the application scenario of playing recorded prompt tones during a call, device 2 can set flag 1 based on flag bit 3 to determine that the audio data processing is complete. In other audio playback scenarios, device 2 can normally determine whether the audio data processing is complete based on conditions 1 and 2. This solves the problem of looping some recorded prompt tones, while having little impact on the playback of other audio.

[0227] When the mark bit 3 is set to mark 1, the audio flinger executes S807, that is, setting the mark bit 3 to mark 1.

[0228] When the flag bit 3 is flag 1, it indicates that the chip type of device 2 easily causes the problem of looping the recording prompt tone, and device 2 plays the recording prompt tone during a call. Therefore, the audio flinger can set flag 1 based on flag bit 3 to determine that the audio data processing of the recording prompt tone is completed, and the audio flinger can execute S808 to set flag bit 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 the address of the shared memory created in S706, the state of the mark bit in the control block included in the newly created shared memory is the default value, so that 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 in an invalid state), so that part of the recording prompt tone can be played without looping.

[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 the processing is completed through a function callback. For example, the audio flinger calls the track->presentationComplete method to determine whether conditions 1 and 2 are met.

[0232] In one case, if condition 1 and / or condition 2 is 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, the audio flinger can determine that the audio data processing of the recording prompt tone is completed.

[0233] In another case, if condition 1 and / or condition 2 is 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 this application does not make any specific limitation on this.

[0235] Condition 1 is that the number of frames of audio data written from the application framework layer to the HAL layer is greater than or equal to the number of frames of audio data of the recording prompt tone. The number of frames of audio data written from 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 audioflinger from the shared memory, or the number of frames of audio data 1 transmitted from the audio flinger to the HAL layer. The number of frames of audio data of the recording prompt tone can also be understood as the number of frames of audio data written to the shared memory by the media playback service.

[0236] The audio flinger can calculate the number of frames of audio data that the media playback service writes 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 audio data received by the kernel layer is less than the number of frames of audio data written to the HAL layer by the application framework layer. The number of frames of 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 the audio flinger can obtain the number of frames of audio data received by the kernel layer by calling interfaces, etc.; the number of frames of audio data written to the HAL layer by the application framework 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 audio data 1 transmitted by the audio flinger to the HAL layer.

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

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

[0240] For example, the audio flinger can call the Track::invalidate method to set the flag bit 2 to true. In this way, when the device 2 plays the recording prompt sound next time, if the shared memory allocated to the newly created control block is the same as the shared memory address created in S706, the flag bit 2 in the newly created control block is set to true, so that the device 2 may execute the loop. Figure 4 The process shown.

[0241] Fig. 9 The flowchart of the audio processing method 900 provided in the embodiment of the present application is shown in FIG. Some steps in the method 900 can also be understood as the implementation of some steps in the method 800. The 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] This allows AudioTrack to instruct the audio flinger to start playing audio.

[0244] S902. The audio flinger wakes up (or creates) a mixing thread (MixerThread).

[0245] S903, audio flinger executes thread loop (threadLoop) through mixing thread. The thread loop includes the following three processes: process 1, calling prepareTracks_1 to prepare for mixing; process 2, calling threadLoop_mix to mix the audio data to obtain audio data 1; process 3, calling threadLoop_write to output audio data 1, that is, transmitting audio data 1 to the audio module of HAL layer.

[0246] It can be understood that, in combination with S707, since AudioTrack will continue to write audio data to the shared memory, the audio flinger also needs to continuously obtain and process audio data from the shared memory. Therefore, the audio flinger can periodically execute a thread loop, for example, executing a thread loop every 20ms. In this way, the audio flinger can continuously transmit the new mixed audio data (audio data 1) to the HAL layer, so that the device 2 can play the recording prompt tone normally.

[0247] Among them, process 1 in the thread cycle can be understood as S708 in method 700, for example; process 2 in the thread cycle can be understood as S709 in method 700; process 3 in the thread cycle can be understood as S710 in method 700.

[0248] When the audio flinger determines that the recording prompt sound has terminated playing (for example, S802 and S803), the audio flinger may execute S904, ie, determine whether the audio data of the recording prompt sound has been played.

[0249] It should be understood that the implementation of S904 is similar to the implementation of S804 to S809 in method 800. That is, audioflinger first determines whether conditions a, b, and c are met; if so, it sets flag bit 3 to flag 1, and determines that the audio data of the recording prompt tone is played. If one or more of conditions a, b, and c are not met, S809 is executed. For details, please refer to the above description, which will not be repeated here.

[0250] When the audio flinger determines that the audio data of the recording prompt tone is played, S905 and S906 are executed;

[0251] When the audio flinger determines that the audio data of the recorded prompt tone has not been played completely, S907 to S910 are executed.

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

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

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

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

[0256] S908, audio flinger deletes audio tracks.

[0257] For example, an audio flinger can remove tracks by calling removeTracks_I(*tracksToRemove).

[0258] S909. The audio flinger stops playing the audio data of the recorded prompt tone.

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

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

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

[0262] It should be noted that in the embodiments of the present application, the marks or information set for each mark bit (such as true in the above text, etc.) are all examples, and the marks or information set for each mark bit in various situations can also be replaced by other ones, and 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 may also include a variety of parameters, which may include but are not limited to one or more of the following: mBufferSizeInFrames, used to indicate the size of the buffer, so that the amount of audio data written to the buffer by the device 2 does not exceed the size; mFront, used to indicate the location of the audio data in the buffer; or, mRear, used to indicate the location of writing audio data to the buffer, etc. The embodiment of the present application does not specifically limit other information included in the control block.

[0264] It should be understood that the size of the sequence numbers in the above embodiments does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic.

[0265] The above has described the method for executing the dynamic effect of the embodiment of the present application, and the following is a description of the device for executing the above method provided by the embodiment of the present application. Those skilled in the art can understand that the method and the device can be combined and referenced with each other, and the relevant device provided by the embodiment of the present application can execute the steps in the above list sorting method.

[0266] In order to facilitate the understanding of this scheme, first combine Fig.10 The hardware structure of the electronic device 1000 is described. The electronic device 1000 may be, for example, the device 1 or the device 2 mentioned above.

[0267] Fig.10 Schematic diagram of the structure of the electronic device 1000 provided in the embodiment of the present application. Fig.10 As 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] The audio module 1070 may include, but is not limited to: a speaker, a receiver, a microphone, and an earphone interface, etc. The speaker may be used to play a recording 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, an air 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 is understood that the structure illustrated in the embodiment 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 some components, or split some components, or arrange the components differently. The components shown in the figure may 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 processor (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). Optionally, a memory may be provided in the processor 1010 for storing instructions and data. Different processing units may be independent devices or integrated in one or more processors.

[0272] The wireless communication function of the electronic device 1000 can be implemented through the antenna 1, the antenna 2, the mobile communication module 1050, the wireless communication module 1060, the modem processor and the baseband processor.

[0273] For example, device 1 or device 2 can communicate with the network device through a modem. Device 1 can send a data packet to the network device through the modem; the network device can send a data packet from device 1 to device 2, and device 2 can receive the data packet through the modem.

[0274] The electronic device 1000 implements the display function through a GPU, a display screen 1094, and an application processor. The GPU is a microprocessor for image processing, which connects 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 that 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 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 codes, which include instructions.

[0277] Fig.11A schematic block diagram of a motion effect execution device 1100 provided in an embodiment of the present application. The device 1100 includes a processor 1101, a communication interface 1102, and a memory 1103. 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 can be specifically the device 1 or the device 2 in the above-mentioned embodiment, and can be used to execute the various steps and / or processes corresponding to the device 1 or the device 2 in the above-mentioned 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 portion 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 instructions stored in the memory, and when the processor 1101 executes instructions stored in the memory, the processor 1101 is used to execute the various steps and / or processes of the above-mentioned method embodiment.

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

[0280] In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software. The steps of the method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in a processor for execution. The software module can be located in a storage medium mature 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 a memory, and the processor executes the instructions in the memory, and completes the steps of the above method in conjunction with its hardware. To avoid repetition, it is not described in detail here.

[0281] The method for executing the dynamic effect provided in the embodiment of the present application can be applied to electronic devices with communication functions. The electronic devices include terminal devices, and the specific device form of the terminal devices can refer to the above related descriptions, which will not be repeated here.

[0282] An embodiment of the present application provides an electronic device, which includes: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the electronic device executes the above method.

[0283] The embodiment of the present application provides a chip. The chip includes a processor, and the processor is used to call a computer program in a memory to execute the technical solution in the above embodiment. Its implementation principle and technical effect are similar to those of the above related embodiments, and will not be repeated here.

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

[0285] In one possible implementation, a computer-readable medium may include RAM, ROM, compact disc read-only memory (CD-ROM) or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that is intended to carry or store the required program code in the form of instructions or data structures and can be accessed by a computer. Moreover, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology (such as infrared, radio and microwave) is used to transmit software from a website, server or other remote source, the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology such as infrared, radio and microwave are included in the definition of medium. Disks and optical disks as used herein include optical disks, laser disks, optical disks, digital versatile disks (DVD), floppy disks and Blu-ray disks, where disks usually reproduce data magnetically, while optical disks reproduce data optically using lasers. Combinations of the above should also be included in the scope of computer-readable media.

[0286] An embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is executed, the computer executes the above method.

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

[0288] The above specific implementation methods further illustrate the purpose, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the present invention should be included in the scope of protection 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 any one of claims 1 to 5, 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 7, 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 8, 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