WO2024021096A1 - 一种数据共享的方法及设备 - Google Patents

一种数据共享的方法及设备 Download PDF

Info

Publication number
WO2024021096A1
WO2024021096A1 PCT/CN2022/109186 CN2022109186W WO2024021096A1 WO 2024021096 A1 WO2024021096 A1 WO 2024021096A1 CN 2022109186 W CN2022109186 W CN 2022109186W WO 2024021096 A1 WO2024021096 A1 WO 2024021096A1
Authority
WO
WIPO (PCT)
Prior art keywords
audio data
target audio
different applications
memory
application
Prior art date
Application number
PCT/CN2022/109186
Other languages
English (en)
French (fr)
Inventor
曹东波
Original Assignee
京东方科技集团股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京东方科技集团股份有限公司 filed Critical 京东方科技集团股份有限公司
Priority to CN202280002470.4A priority Critical patent/CN117795485A/zh
Priority to PCT/CN2022/109186 priority patent/WO2024021096A1/zh
Publication of WO2024021096A1 publication Critical patent/WO2024021096A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication

Definitions

  • the present disclosure relates to the field of data processing technology, and in particular to a data sharing method and device.
  • the audio processing logic of traditional Android core is mainly implemented through the audio core framework (Framework), which uses the audio core framework to provide rich interfaces to upper-layer APPs.
  • Upper-layer APPs can implement functions such as recording, editing, and playback by calling the interfaces provided by the audio core framework.
  • the present disclosure provides a data sharing method and device to improve the usage efficiency of audio data and avoid audio frame loss and lagging.
  • an embodiment of the present disclosure provides a data sharing method.
  • the method includes:
  • the file descriptor is shared among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • obtaining target audio data to be shared between different applications and storing the target audio data in memory includes:
  • obtaining the target audio data from the hardware register and storing the target audio data in memory includes:
  • the target audio data in the hardware register is stored in physical memory.
  • storing the target audio data in the hardware register into physical memory includes:
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio;
  • the method of obtaining target audio data to be shared between different applications and storing the target audio data in memory includes:
  • the recorded audio is used as target audio data to be shared between the first application and the second application, and the recorded audio stored in the hardware register is stored in a physical memory.
  • the different application programs include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the audio in the audio containing the watermark. watermark;
  • the method of obtaining target audio data to be shared between different applications and storing the target audio data in memory includes:
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared;
  • the method also includes:
  • the audio containing the watermark is transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the target audio data is stored in physical memory
  • Determining the file descriptor corresponding to the target audio data based on the memory address where the target audio data is stored includes:
  • determining the file descriptor corresponding to the target audio data according to the memory address where the target audio data is stored includes:
  • mapping relationship between virtual memory addresses of different applications and the same file descriptor, and determining the file descriptor corresponding to the target audio data according to the mapping relationship includes:
  • sharing the file descriptor among the different applications includes:
  • the target audio data to be shared includes target audio data processed simultaneously by the different applications.
  • the different application programs include different application programs running on the Android system.
  • sharing the file descriptor among the different applications includes:
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • the method further includes:
  • the different applications obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data;
  • the processing of the target audio data includes:
  • embodiments of the present disclosure also provide a data sharing system, which includes: an audio driver module and an audio framework module, wherein:
  • the audio driver module is configured to obtain target audio data to be shared between different applications, store the target audio data in memory; and determine the corresponding target audio data according to the memory address where the target audio data is stored. file descriptor;
  • the audio framework module is configured to share the file descriptor among the different applications, so that the different applications obtain the target audio data according to the memory address corresponding to the file descriptor.
  • the audio driver module is specifically configured to execute:
  • the audio driver module is specifically configured to execute:
  • the target audio data in the hardware register is stored in physical memory.
  • the audio driver module is specifically configured to execute:
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio;
  • the audio driver module is specifically configured to execute:
  • the recorded audio is used as target audio data to be shared between the first application and the second application, and the recorded audio stored in the hardware register is stored in a physical memory.
  • the different application programs include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the audio in the audio containing the watermark. watermark;
  • the audio driver module is specifically configured to execute:
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared;
  • the audio driver module is specifically configured to execute:
  • the audio containing the watermark is transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the target audio data is stored in physical memory
  • the audio driver module is specifically configured to execute:
  • the audio driver module is specifically configured to execute:
  • the audio driver module is specifically configured to execute:
  • the audio framework module is specifically configured to execute:
  • the target audio data to be shared includes target audio data processed simultaneously by the different applications.
  • the different application programs include different application programs running on the Android system.
  • the audio framework module is specifically configured to execute:
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • the method further includes a delay processing module specifically configured to execute:
  • the different applications obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data;
  • the processing of the target audio data includes:
  • an embodiment of the present disclosure provides a data sharing device, including a processor and a memory.
  • the memory is used to store programs executable by the processor.
  • the processor is used to read the program in the memory. program and perform the following steps:
  • the file descriptor is shared among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • the processor is specifically configured to execute:
  • the processor is specifically configured to execute:
  • the target audio data in the hardware register is stored in physical memory.
  • the processor is specifically configured to execute:
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio;
  • the processor is specifically configured to perform:
  • the recorded audio is used as target audio data to be shared between the first application and the second application, and the recorded audio stored in the hardware register is stored in a physical memory.
  • the different application programs include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the audio in the audio containing the watermark. watermark;
  • the processor is specifically configured to perform:
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared;
  • the processor is specifically configured to execute:
  • the audio containing the watermark is transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the target audio data is stored in physical memory
  • the processor is specifically configured to perform:
  • the processor is specifically configured to execute:
  • the processor is specifically configured to execute:
  • the processor is specifically configured to execute:
  • the target audio data to be shared includes target audio data processed simultaneously by the different applications.
  • the different application programs include different application programs running on the Android system.
  • the processor is specifically configured to execute:
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • the processor is specifically configured to execute:
  • the different applications obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data;
  • the processor is specifically configured to perform:
  • an embodiment of the present disclosure provides a data sharing device, including:
  • An address mapping unit configured to determine the file descriptor corresponding to the target audio data according to the memory address where the target audio data is stored;
  • An audio sharing unit is configured to share the file descriptor among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • the audio acquisition unit is specifically used for:
  • the audio acquisition unit is specifically used for:
  • the target audio data in the hardware register is stored in physical memory.
  • the audio acquisition unit is specifically used for:
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio;
  • the audio acquisition unit is specifically used for:
  • the recorded audio is used as target audio data to be shared between the first application and the second application, and the recorded audio stored in the hardware register is stored in a physical memory.
  • the different application programs include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the audio in the audio containing the watermark. watermark;
  • the audio acquisition unit is specifically used for:
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared;
  • the audio containing the watermark is transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the target audio data is stored in physical memory; the address mapping unit is specifically used to:
  • the address mapping unit is specifically used to:
  • the address mapping unit is specifically used to:
  • the audio sharing unit is specifically used for:
  • the target audio data to be shared includes target audio data processed simultaneously by the different applications.
  • the different application programs include different application programs running on the Android system.
  • the audio sharing unit is specifically used for:
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • a delay processing unit is also included for:
  • the different applications obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data;
  • the delay processing unit is specifically used for:
  • embodiments of the present disclosure also provide a computer storage medium on which a computer program is stored, and when the program is executed by a processor, it is used to implement the steps of the method described in the first aspect.
  • Figure 1 is a traditional Android system audio processing framework diagram provided by an embodiment of the present disclosure
  • Figure 2 is an implementation flow chart of a data sharing method provided by an embodiment of the present disclosure
  • Figure 3 is an audio processing framework diagram provided by an embodiment of the present disclosure.
  • Figure 4 is an architectural diagram for sharing audio data between different processes according to an embodiment of the present disclosure
  • Figure 5 is an implementation flow chart of an audio data sharing method provided by an embodiment of the present disclosure.
  • Figure 6 is an implementation flow chart of a watermarked audio data sharing method provided by an embodiment of the present disclosure
  • Figure 7 is an implementation flow chart of an audio data sharing method for playing verification watermarks provided by an embodiment of the present disclosure
  • Figure 8 is a schematic diagram of a data sharing system provided by an embodiment of the present disclosure.
  • Figure 9 is a schematic diagram of a data sharing device provided by an embodiment of the present disclosure.
  • Figure 10 is a schematic diagram of a data sharing device provided by an embodiment of the present disclosure.
  • the term "and/or” describes the association relationship of associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A exists alone, A and B exist simultaneously, and B exists alone. these three situations.
  • the character "/” generally indicates that the related objects are in an "or” relationship.
  • Embodiment 1 The traditional Android system audio processing framework is shown in Figure 1.
  • the bottom layer (first layer) is the audio hardware layer (audio Codec Hardware), which is responsible for audio digital-to-analog conversion, channel management, etc.
  • the second layer is the audio driver layer.
  • the third layer is the audio HAL (Hardware Abstraction Layer), which shields different hardware from the upper layer (such as the fourth layer).
  • the fourth layer is the audio core framework (Framework) layer.
  • the core audio processing logic of Android is implemented in this layer, which can provide rich interfaces to the upper-layer application APP.
  • the upper-layer APP can realize recording, editing, and playback by calling the interface provided by the Framework. and other functions.
  • App1 and App2 need to share audio data, since the processes of different APPs cannot access each other, if the process of one APP wants to access the audio data of another APP process, the audio data needs to be copied once before it can be processed or played.
  • the current method of copying audio data greatly reduces the efficiency of audio data use. In special scenarios, it may also cause audio frame loss, lag, etc.
  • App1 needs to record audio data C
  • APP2 needs to add a watermark to the audio data C
  • each APP needs to copy the audio data once when using the audio data C, and copy the audio data twice in total to achieve this.
  • the processing of audio data leads to a reduction in the efficiency of the use of audio data.
  • this embodiment provides a data sharing method that can achieve access and processing of audio data without copying the audio data. This effectively improves the usage efficiency of audio data.
  • the core idea of this embodiment is to store audio data into memory, determine the file descriptor according to the memory address, and then share the file descriptor among different applications.
  • the file descriptor of the audio data can be shared among multiple applications, that is, the file descriptor of the audio data can be transmitted among multiple applications.
  • the application determines the memory address based on the file descriptor, it can retrieve the memory address from the memory address. Read audio data to process the audio data.
  • This embodiment realizes the sharing of audio data between different applications by mapping the memory address of the audio data into a file descriptor and sharing the file descriptor in different applications.
  • the data sharing method in this embodiment can also be applied to other types of data other than audio data.
  • the data sharing method implemented based on the principles of this embodiment all fall within the scope of the present disclosure.
  • this embodiment provides a data sharing method that can be applied to Android systems.
  • the specific implementation process of this method is as follows:
  • Step 200 Obtain target audio data to be shared between different applications, and store the target audio data in memory;
  • the target audio data to be shared between different applications may be target audio data processed simultaneously between different applications.
  • simultaneous processing includes but is not limited to processing that is completely aligned in time, or processing that is not completely aligned in time. That is, with respect to two different applications, there may be a certain amount of corresponding processing time. degree of delay.
  • the different applications in this embodiment obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data; wherein, There is a time delay in processing the target audio data by the different applications.
  • the different applications in this embodiment include different applications running on the Android system.
  • the target audio data to be shared between different applications is obtained through the following steps, and the target audio data is stored in memory:
  • the audio data are stored in the corresponding hardware registers.
  • the target audio data is read from the hardware register corresponding to the target audio data, and the target audio data is Data is stored into memory.
  • the hardware register in this embodiment may be a hardware register in a hardware interface controller, which is used for storing and caching target audio data.
  • any VXI bus device regardless of its function, must have a set of configuration registers. The system identifies the type, model, manufacturer, address space and required memory space of the device by accessing the configuration register of the PI port on the VME bus. The only VXI bus devices with this lowest communication capability are register-based devices. Through this set of common configuration registers, central resource managers and basic software modules, system and memory configuration can be automatically performed during system initialization.
  • this embodiment obtains the target audio data from the hardware register and stores the target audio data into memory in the following manner:
  • the target audio data in the hardware register is stored in physical memory.
  • the direct memory access mechanism is used to read the target audio data in the hardware register corresponding to the target audio data into the physical memory.
  • the direct memory access mechanism includes but is not limited to the DMA (Direct Memory Access) mechanism, which can directly access data from physical memory without going through the CPU.
  • DMA Direct Memory Access
  • the CPU only needs to issue instructions to the DMA controller, and let the DMA controller handle the data transmission. After the data transmission is completed, the information is fed back to the CPU, thus reducing the CPU resource occupancy to a great extent and effectively saving money. system resource.
  • the target audio data in the hardware register is stored into physical memory through the following steps:
  • continuous physical memory is allocated to the target audio data; and the target audio data is stored in the allocated continuous physical memory.
  • continuous memory allocation technology includes but is not limited to CMA (Contiguous Memory Allocator, continuous memory allocator).
  • the working principle is to reserve part of the physical memory for the driver to use, but when the driver is not using it, the memory allocator (memory allocator) or
  • the buddy system can be allocated to user processes for use as anonymous memory or page cache. When the driver needs to use it, the physical memory occupied by the process is reserved for the driver to use by recycling or migrating.
  • the recorded audio is stored in the physical memory as target audio data to be shared;
  • the audio containing the watermark may also be transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio; and the recorded audio is obtained through the first application and store the recorded audio in a hardware register; use the recorded audio as target audio data to be shared between the first application and the second application, and store all the audio in the hardware register.
  • the recorded audio is stored into physical memory.
  • the second application reads the recorded audio from the physical memory and adds a watermark to the recorded audio.
  • the audio hardware layer (audio Codec Hardware) is used to perform analog-to-digital conversion, codec processing, etc. on the audio signal, output the target audio data, and pass the target audio data through the hardware interface controller.
  • the hardware register is cached, and the SoC is used to read the target audio data from the hardware register and stored in the physical memory; the kernel of the operating system is used to map the physical memory address storing the target audio data to the first The virtual memory addresses of the application and the second application.
  • the target audio data can be stored in the ring buffer corresponding to the virtual memory address, and a mapping relationship between the virtual memory addresses of the first application and the second application and the same file descriptor can be established.
  • the file descriptor corresponding to the target audio data is determined according to the mapping relationship.
  • the first application uses the audio framework to obtain the target.
  • the file descriptor corresponding to the audio data and according to the mapping relationship between the file descriptor and the virtual memory address of the first application, continue to record the target audio data in the ring buffer corresponding to the virtual memory address.
  • the second application also The audio framework is used to obtain the file descriptor corresponding to the target audio data, and according to the mapping relationship between the file descriptor and the virtual memory address of the second application, the watermark is continued to be added to the target audio data in the ring buffer corresponding to the virtual memory address.
  • the different applications include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the watermark in the audio containing the watermark;
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared; the said The audio containing the watermark is transferred from the physical memory to the hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the third application when the audio containing the watermark is played through a third application, the third application reads the audio containing the watermark from the ring buffer corresponding to the virtual memory address and plays it. According to the virtual memory of the audio containing the watermark in the third application Address, determine the mapped physical memory, store the audio containing the watermark into the physical memory, then cache it through the hardware register in the hardware interface controller, output it to the audio hardware layer for analog-to-digital conversion, and after encoding and decoding, output it to the speaker. Play, and at the same time, when it is determined to use the fourth application to verify the watermark when the third application plays the audio containing the watermark, the kernel of the operating system is used to map the physical memory address where the target audio data is stored, respectively.
  • the third application uses the audio framework to obtain the corresponding file descriptor of the target audio data.
  • file descriptor and based on the mapping relationship between the file descriptor and the virtual memory address of the third application, continue to play the target audio data in the ring buffer corresponding to the virtual memory address.
  • the fourth application also uses the audio framework Obtain the file descriptor corresponding to the target audio data, and perform watermark verification on the target audio data in the ring buffer corresponding to the virtual memory address according to the mapping relationship between the file descriptor and the virtual memory address of the fourth application to verify the watermark. legality.
  • the first application and the third application in this embodiment may be the same application program, or they may be different application programs.
  • the second application and the fourth application in this embodiment may be the same application program, or they may be different application programs. application, this embodiment does not impose too many limitations on this.
  • Step 201 Determine the file descriptor corresponding to the target audio data according to the memory address where the target audio data is stored;
  • the kernel of the operating system is used to map the physical memory address where the target audio data is stored to the virtual memory address of different applications, and establish the relationship between the virtual memory addresses of different applications and the same file descriptor. Mapping relationship, determine the file descriptor corresponding to the target audio data according to the mapping relationship.
  • the size of the virtual memory allocated to the APP is fixed, that is, the size of the available virtual memory of the APP is fixed.
  • the virtual memory is determined based on the actual situation of the process. The actual size of the memory.
  • the system's physical memory is divided into many equal-sized parts, also called memory pages.
  • the size of the memory page depends on the CPU architecture and operating system configuration.
  • the use of physical memory is mainly divided into one or more of the following situations:
  • the compressed kernel file located in the /boot directory is loaded into physical memory and decompressed. This part of the content will reside at the beginning of the memory as long as the system allows it.
  • the operation of the operating system also requires more space to be allocated to management processes, file descriptors, sockets, loaded kernel modules, etc. So the kernel will dynamically allocate physical memory through the slab allocator.
  • the page cache Except for the part used by the kernel and processes, the remaining part of physical memory is called the page cache. Because the speed of disk IO is much lower than the access speed of memory, in order to speed up access to disk data, the page cache stores the data read from the disk as much as possible. There is also a part of the page cache called buffer, which is used to cache data to be written to the disk.
  • Virtual memory doesn't actually exist, it just exists in this clever memory management mechanism.
  • the kernel creates a virtual address space for the new process.
  • This virtual address space represents all the memory that may be used by the process, and of course it can change dynamically.
  • the schematic diagram of the virtual address structure is as follows. The address increases from bottom to top and mainly includes the following parts:
  • Code segment This section is read-only and is used to store loaded code.
  • Stack used to store local variables and process context.
  • this embodiment can first store the target audio data into physical memory, map the physical memory to the virtual memory of different applications, and map the virtual memory addresses of different applications to the same A file descriptor, the specific implementation steps are as follows:
  • the virtual memory address is determined as follows:
  • the physical memory address storing the target audio data is mapped to the virtual memory address of different applications.
  • virtual memory addresses are isolated from each other between different applications, virtual memory addresses cannot be directly transferred between different applications. Instead, they need to be converted into file descriptors through the following steps and then transferred between different applications.
  • the file descriptor in this embodiment is a non-negative integer in form. In fact, it is an index value pointing to the record table of files opened by the process maintained by the kernel for each process.
  • the kernel returns a file descriptor to the process.
  • the kernel uses file descriptors to access files. File descriptors are nonnegative integers. When opening an existing file or creating a new file, the kernel returns a file descriptor. Reading and writing files also requires the use of file descriptors to specify the files to be read and written.
  • the file descriptor in this embodiment includes but is not limited to a handle.
  • the handle is an identifier used to identify an object or project, which can be used to describe a form, file, etc.
  • the handle is set based on the memory management mechanism problem, that is, the virtual address problem. If the address of the data needs to be changed, the change needs to be recorded and managed after the change, so the change of the data address is recorded through a handle.
  • a handle is a special smart pointer. When an application wants to reference a memory block or object managed by other systems (such as databases and operating systems), it can use handles.
  • a mapping relationship between virtual memory addresses of different applications and the same handle is established, and the handle corresponding to the target audio data is determined based on the mapping relationship.
  • the virtual memory addresses of different applications can be mapped to the same handle according to the mapping relationship between the virtual memory address and the handle in the IDR table.
  • the file descriptors are shared among the different applications as follows:
  • Step 202 Share the file descriptor among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • the handle corresponding to the audio data can be passed among different applications.
  • Each application obtains the handle and converts it into the virtual memory address of the application, thereby accessing the audio data according to the physical memory address mapped by the virtual memory address.
  • the purpose of accessing related audio data without copying the audio data is to effectively improve the transfer efficiency of audio data between apps, effectively solve the problem of audio frame loss and lag, and improve the audio processing in different ways. Stages, different processing levels, and different apps can locate problems very well.
  • this embodiment provides an audio processing framework, including an audio hardware layer, an audio driver layer, an audio hardware abstraction layer, and an audio core framework layer.
  • the audio driver layer includes a DMA address management layer, a CMA cache layer, a virtual Address mapping layer; the audio driver layer in this embodiment can use the DMA mechanism of the DMA address management layer to store the target audio data from the hardware register to the physical memory, and use the CMA technology of the CMA cache layer to allocate continuous data to the target audio data.
  • Physical memory maps physical memory to the virtual memory of different applications.
  • It uses the virtual address mapping layer to map the virtual memory addresses of different applications into a handle, that is, determines the handle corresponding to the target audio data, and transfers the handle between different applications or Different in-process transfers allow each application or process to obtain the target audio data by converting the handle to a virtual memory address within that application or process.
  • the audio processing framework also includes a ring buffer, which is used to cache audio data (target audio data).
  • the memory structure in the ring buffer is circular, with a head pointer and a tail pointer, and is composed of N blocks of virtual memory.
  • each memory block (corresponding to a virtual memory address) is mapped with a handle and provided to the application layer, so that the handle can be transferred between different processes and different Apps. After each process obtains the handle, Convert it into a virtual memory pointer (virtual memory address) to obtain all audio data in the ring buffer.
  • this embodiment provides an architectural diagram for different processes to share audio data, including a CMA cache layer, a virtual address mapping layer, a ring buffer, process A, and process B.
  • the CMA technology of the CMA cache layer is used , allocate continuous physical memory such as P1 ⁇ P4 for the target audio data, and map the physical memory P1 ⁇ P4 to the virtual memory V1 ⁇ V4.
  • Use the virtual address mapping layer to map the virtual memory addresses (V1 ⁇ V4) to handles respectively.
  • the handles (G1 ⁇ G4) are mapped to different applications or different In-process transmission allows different applications or different processes to convert the handles (G1 ⁇ G4) into virtual memory addresses (V1 ⁇ V4), thereby obtaining the target audio data, that is, the target audio data in P1 ⁇ P4.
  • the ring buffer stores the target audio data.
  • Each memory block in the ring buffer has a virtual memory address.
  • V1 ⁇ V4 in the ring buffer are mapped to handles (G1 ⁇ G4). After each process obtains the handle, This is converted into a virtual memory address, thereby obtaining all the data in the ring buffer.
  • this embodiment also provides an implementation process of an audio data sharing method, which is specifically as follows:
  • Step 500 When different applications need to share the target audio data, determine the hardware register of the target audio data;
  • Step 501 Use the direct memory access mechanism and continuous memory allocation technology to allocate continuous physical memory for the target audio data, and store the target audio data in the allocated continuous physical memory;
  • Step 502 According to the pre-established mapping relationship between physical memory and virtual memory, map the physical memory address where the target audio data is stored to the virtual memory address of different applications;
  • Step 503 Map the virtual memory addresses of different applications to the same handle
  • Step 504 Share the handle in different application programs, so that the different application programs perform corresponding processing on the target audio data corresponding to the virtual memory address mapped by the handle.
  • this embodiment provides a watermarked audio data sharing method.
  • the implementation process of this method is as follows:
  • Step 600 When the first application records audio, determine to add a watermark to the recorded audio;
  • Step 601 Use DMA and CMA technology to store the recorded audio as target audio data to be shared into continuous physical memory
  • Step 602 Map the physical memory address storing the target audio data to the first virtual memory address of the first application and the second virtual memory address of the second application respectively;
  • Step 603 Map both the first virtual memory address and the second virtual memory address to the same handle
  • Step 604 Transfer the handle between the first application and the second application
  • Step 605 The first application obtains the target audio data according to the first virtual memory address mapped by the handle and records the target audio data.
  • the second application obtains the target audio data according to the second virtual memory address mapped by the handle and adds a watermark to the target audio data. .
  • this embodiment provides an audio data sharing method for playing verification watermarks.
  • the implementation process of this method is as follows:
  • Step 700 Determine to extract and verify the watermark when the first application plays the audio containing the watermark
  • Step 701 Use DMA and CMA technology to store the audio containing the watermark as target audio data to be shared into continuous physical memory;
  • Step 702 Map the physical memory address storing the target audio data to the first virtual memory address of the first application and the second virtual memory address of the second application respectively;
  • Step 703 Map both the first virtual memory address and the second virtual memory address to the same handle
  • Step 704 Transfer the handle between the first application and the second application
  • Step 705 The first application obtains the target audio data according to the first virtual memory address mapped by the handle, and plays the target audio data.
  • the second application obtains the target audio data according to the second virtual memory address mapped by the handle, and performs watermarking on the target audio data. extraction and verification.
  • the audio data sharing method provided by this embodiment enables multiple applications and processes to access and play each other without copying audio data, effectively solving problems such as audio playback delays and freezes, and also effectively reducing the copying process.
  • the risk of audio data errors is reduced. Since there is no need to copy audio data, the efficiency of locating problems can be improved.
  • Embodiment 2 Based on the same inventive concept, the embodiment of the present disclosure also provides a data sharing system, because this system is the system in the method in the embodiment of the present disclosure, and the principle of solving the problem of the system is the same as that of the method. are similar, so the implementation of the system can be found in the implementation of the method, and the repetitive parts will not be repeated.
  • the embodiment of the present disclosure also provides a data sharing system.
  • the system includes: an audio driver module 800 and an audio framework module 801, wherein:
  • the audio driver module 800 is configured to obtain target audio data to be shared between different applications, store the target audio data in memory, and determine the target audio data according to the memory address where the target audio data is stored.
  • the audio framework module 801 is configured to share the file descriptor among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • the audio driver module 800 is specifically configured to perform:
  • the audio driver module 800 is specifically configured to execute:
  • the target audio data in the hardware register is stored in physical memory.
  • the audio driver module 800 is specifically configured to execute:
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio;
  • the audio driver module 800 is specifically configured to execute:
  • the recorded audio is used as target audio data to be shared between the first application and the second application, and the recorded audio stored in the hardware register is stored in a physical memory.
  • the different application programs include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the audio in the audio containing the watermark. watermark;
  • the audio driver module 800 is specifically configured to execute:
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared;
  • the audio driver module 800 is specifically configured to execute:
  • the audio containing the watermark is transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the target audio data is stored in physical memory
  • the audio driver module 800 is specifically configured to execute:
  • the audio driver module 800 is specifically configured to perform:
  • the audio driver module 800 is specifically configured to perform:
  • the audio framework module 801 is specifically configured to execute:
  • the target audio data to be shared includes target audio data processed simultaneously by the different applications.
  • the different application programs include different application programs running on the Android system.
  • the audio framework module 801 is specifically configured to execute:
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • the method further includes a delay processing module specifically configured to execute:
  • the different applications obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data;
  • the processing of the target audio data includes:
  • Embodiment 3 Based on the same inventive concept, the embodiment of the present disclosure also provides a data sharing device, because this device is the device in the method in the embodiment of the present disclosure, and the principle of solving the problem of the device is the same as that of the method. are similar, so the implementation of the device can be referred to the implementation of the method, and repeated details will not be repeated.
  • the device includes:
  • the audio acquisition unit 900 is used to acquire target audio data to be shared between different applications, and store the target audio data in memory;
  • Address mapping unit 901 configured to determine the file descriptor corresponding to the target audio data according to the memory address where the target audio data is stored;
  • the audio sharing unit 902 shares the file descriptor among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • the audio acquisition unit 900 is specifically used to:
  • the audio acquisition unit 900 is specifically used to:
  • the target audio data in the hardware register is stored in physical memory.
  • the audio acquisition unit 900 is specifically used to:
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio;
  • the audio acquisition unit 900 is specifically used for:
  • the recorded audio is used as target audio data to be shared between the first application and the second application, and the recorded audio stored in the hardware register is stored in a physical memory.
  • the different application programs include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the audio in the audio containing the watermark. watermark;
  • the audio acquisition unit 900 is specifically used for:
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared;
  • the audio containing the watermark is transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the target audio data is stored in physical memory; the address mapping unit 901 is specifically used to:
  • the address mapping unit 901 is specifically used to:
  • the address mapping unit 901 is specifically used to:
  • the audio sharing unit 902 is specifically used to:
  • the target audio data to be shared includes target audio data processed simultaneously by the different applications.
  • the different application programs include different application programs running on the Android system.
  • the audio sharing unit 902 is specifically used to:
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • a delay processing unit is also included for:
  • the different applications obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data;
  • the delay processing unit is specifically used for:
  • Embodiment 4 Based on the same inventive concept, the embodiment of the present disclosure also provides a data sharing device, because the device is the device in the method in the embodiment of the present disclosure, and the principle of solving the problem of the device is the same as that of the method. are similar, so the implementation of the device can be referred to the implementation of the method, and repeated details will not be repeated.
  • the device includes a processor 1000 and a memory 1001.
  • the memory 1001 is used to store programs executable by the processor 1000.
  • the processor 1000 is used to read the programs in the memory 1001 and Perform the following steps:
  • the file descriptor is shared among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • the processor 1000 is specifically configured to execute:
  • the processor 1000 is specifically configured to execute:
  • the target audio data in the hardware register is stored in physical memory.
  • the processor 1000 is specifically configured to execute:
  • the different applications include a first application and a second application; the first application is used to record audio, and the second application is used to add watermarks to audio;
  • the processor 1000 is specifically configured to execute:
  • the recorded audio is used as target audio data to be shared between the first application and the second application, and the recorded audio stored in the hardware register is stored in a physical memory.
  • the different application programs include a third application and a fourth application; the third application is used to play the audio containing the watermark, and the fourth application is used to verify the audio in the audio containing the watermark. watermark;
  • the processor 1000 is specifically configured to execute:
  • the played audio containing the watermark is stored in the physical memory as the target audio data to be shared;
  • the processor 1000 is specifically configured to execute:
  • the audio containing the watermark is transferred from the physical memory to a hardware register, so that the audio hardware reads the audio containing the watermark from the hardware register and plays it.
  • the target audio data is stored in physical memory
  • the processor 1000 is specifically configured to execute:
  • the processor 1000 is specifically configured to execute:
  • the processor 1000 is specifically configured to execute:
  • the processor 1000 is specifically configured to execute:
  • the target audio data to be shared includes target audio data processed simultaneously by the different applications.
  • the different application programs include different application programs running on the Android system.
  • the processor 1000 is specifically configured to execute:
  • the file descriptor is transferred to different applications using an audio framework so that the file descriptor is shared among the different applications.
  • the processor 1000 is specifically configured to execute:
  • the different applications obtain the target audio data according to the memory address corresponding to the file descriptor, and process the target audio data;
  • the processor is specifically configured to perform:
  • embodiments of the present disclosure also provide a computer storage medium on which a computer program is stored.
  • the program is executed by a processor, the following steps are implemented:
  • the file descriptor is shared among the different application programs, so that the different application programs obtain the target audio data according to the memory address corresponding to the file descriptor.
  • embodiments of the present disclosure may be provided as methods, systems, or computer program products. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, optical storage, and the like) embodying computer-usable program code therein.
  • a computer-usable storage media including, but not limited to, magnetic disk storage, optical storage, and the like
  • These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instructed device, the instructions
  • the equipment implements the functions specified in a process or processes in the flow diagram and/or in a block or blocks in the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
  • Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

本公开提出了一种数据共享的方法及设备，用于提高音频数据的使用效率，避免造成音频丢帧、卡顿的情况。该方法包括：获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。

Description

一种数据共享的方法及设备 技术领域
本公开涉及数据处理技术领域，特别涉及一种数据共享的方法及设备。
背景技术
传统Android核心的音频处理逻辑主要通过音频核心框架(Framework)实现，利用音频核心框架对上层APP提供丰富的接口，上层APP可以通过调用音频核心框架提供的接口实现录音、编辑、播放等功能。
当App1和App2需要共享音频数据时，由于不同APP的进程之间不能互相访问，导致如果一个APP的进程要访问另外一个APP的进程的音频数据，就需要拷贝一次音频数据，然后才能处理或者播放该音频数据，但是目前拷贝音频数据的方式极大降低了音频数据的使用效率，在特殊场景下还可能造成音频丢帧、卡顿等情况。
发明内容
本公开提供一种数据共享的方法及设备，用于提高音频数据的使用效率，避免造成音频丢帧、卡顿的情况。
第一方面，本公开实施例提供的一种数据共享的方法，该方法包括：
获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
作为一种可选的实施方式，所述获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存，包括：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
作为一种可选的实施方式，所述从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存，包括：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
作为一种可选的实施方式，所述将所述硬件寄存器中的所述目标音频数据存储到物理内存中，包括：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
将所述目标音频数据存储到分配的连续的物理内存中。
作为一种可选的实施方式，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
所述获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存，包括：
通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；
将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
作为一种可选的实施方式，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
所述获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存，包括：
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物 理内存；
所述方法还包括：
将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
作为一种可选的实施方式，所述目标音频数据存储在物理内存；
所述根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符，包括：
将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符，包括：
利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符，包括：
建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
作为一种可选的实施方式，所述将所述文件描述符在所述不同应用程序中共享，包括：
将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
作为一种可选的实施方式，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
作为一种可选的实施方式，所述不同应用程序包括在安卓系统运行的不同应用程序。
作为一种可选的实施方式，所述将所述文件描述符在所述不同应用程序中共享，包括：
利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
作为一种可选的实施方式，所述方法还包括：
所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
所述对所述目标音频数据进行处理，包括：
所述不同应用程序对所述目标音频数据的处理具有时间延迟。
第二方面，本公开实施例还提供一种数据共享的系统，该系统包括：音频驱动模块和音频框架模块，其中：
所述音频驱动模块，被配置为获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
所述音频框架模块，被配置为将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
作为一种可选的实施方式，所述音频驱动模块具体被配置为执行：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
作为一种可选的实施方式，所述音频驱动模块具体被配置为执行：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
作为一种可选的实施方式，所述音频驱动模块具体被配置为执行：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
将所述目标音频数据存储到分配的连续的物理内存中。
作为一种可选的实施方式，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
所述音频驱动模块具体被配置为执行：
通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；
将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
作为一种可选的实施方式，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
所述音频驱动模块具体被配置为执行：
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物理内存；
所述音频驱动模块具体还被配置为执行：
将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
作为一种可选的实施方式，所述目标音频数据存储在物理内存；
所述音频驱动模块具体被配置为执行：
将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据 所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述音频驱动模块具体被配置为执行：
利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述音频驱动模块具体被配置为执行：
建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
作为一种可选的实施方式，所述音频框架模块具体被配置为执行：
将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
作为一种可选的实施方式，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
作为一种可选的实施方式，所述不同应用程序包括在安卓系统运行的不同应用程序。
作为一种可选的实施方式，所述音频框架模块具体被配置为执行：
利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
作为一种可选的实施方式，所述方法还包括延迟处理模块具体被配置为执行：
所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
所述对所述目标音频数据进行处理，包括：
所述不同应用程序对所述目标音频数据的处理具有时间延迟。
第三方面，本公开实施例提供的一种数据共享的设备，包括处理器和存 储器，所述存储器用于存储所述处理器可执行的程序，所述处理器用于读取所述存储器中的程序并执行如下步骤：
获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
作为一种可选的实施方式，所述处理器具体被配置为执行：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
作为一种可选的实施方式，所述处理器具体被配置为执行：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
作为一种可选的实施方式，所述处理器具体被配置为执行：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
将所述目标音频数据存储到分配的连续的物理内存中。
作为一种可选的实施方式，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
所述处理器具体被配置为执行：
通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；
将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
作为一种可选的实施方式，所述不同应用程序包括第三应用和第四应用； 所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
所述处理器具体被配置为执行：
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物理内存；
所述处理器具体还被配置为执行：
将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
作为一种可选的实施方式，所述目标音频数据存储在物理内存；
所述处理器具体被配置为执行：
将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述处理器具体被配置为执行：
利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述处理器具体被配置为执行：
建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
作为一种可选的实施方式，所述处理器具体被配置为执行：
将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
作为一种可选的实施方式，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
作为一种可选的实施方式，所述不同应用程序包括在安卓系统运行的不同应用程序。
作为一种可选的实施方式，所述处理器具体被配置为执行：
利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
作为一种可选的实施方式，所述处理器具体还被配置为执行：
所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
所述处理器具体被配置为执行：
所述不同应用程序对所述目标音频数据的处理具有时间延迟。
第四方面，本公开实施例提供的一种数据共享的装置，包括：
获取音频单元，用于获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
地址映射单元，用于根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
音频共享单元，用于将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
作为一种可选的实施方式，所述获取音频单元具体用于：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
作为一种可选的实施方式，所述获取音频单元具体用于：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储 到物理内存中。
作为一种可选的实施方式，所述获取音频单元具体用于：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
将所述目标音频数据存储到分配的连续的物理内存中。
作为一种可选的实施方式，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
所述获取音频单元具体用于：
通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；
将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
作为一种可选的实施方式，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
所述获取音频单元具体用于：
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物理内存；
还包括转存单元具体用于：
将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
作为一种可选的实施方式，所述目标音频数据存储在物理内存；所述地址映射单元具体用于：
将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述地址映射单元具体用于：
利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述地址映射单元具体用于：
建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
作为一种可选的实施方式，所述音频共享单元具体用于：
将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
作为一种可选的实施方式，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
作为一种可选的实施方式，所述不同应用程序包括在安卓系统运行的不同应用程序。
作为一种可选的实施方式，所述音频共享单元具体用于：
利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
作为一种可选的实施方式，还包括延迟处理单元具体用于：
所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
所述延迟处理单元具体用于：
所述不同应用程序对所述目标音频数据的处理具有时间延迟。
第五方面，本公开实施例还提供计算机存储介质，其上存储有计算机程序，该程序被处理器执行时用于实现上述第一方面所述方法的步骤。
本公开的这些方面或其他方面在以下的实施例的描述中会更加简明易懂。
附图说明
为了更清楚地说明本公开实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本公开实施例提供的一种传统Android系统音频处理框架图；
图2为本公开实施例提供的一种数据共享的方法的实施流程图；
图3为本公开实施例提供的一种音频处理框架图；
图4为本公开实施例提供的一种不同进程共享音频数据的架构图；
图5为本公开实施例提供的一种音频数据共享的方法的实施流程图；
图6为本公开实施例提供的一种录音加水印的音频数据共享方法实施流程图；
图7为本公开实施例提供的一种播放验证水印的音频数据共享方法实施流程图；
图8为本公开实施例提供的一种数据共享的系统示意图；
图9为本公开实施例提供的一种数据共享的装置示意图；
图10为本公开实施例提供的一种数据共享的设备示意图。
具体实施方式
为了使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开作进一步地详细描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本公开保护的范围。
本公开实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
本公开实施例描述的应用场景是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域普通技术人员可知，随着新应用场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。其中，在本公开的描述中，除非另有说明，“多个”的含义是两个或两个以上。
实施例1、传统Android系统音频处理框架如图1所示，最底层(第一层)是音频硬件层(音频Codec Hardware)，负责音频数模转换、通路管理等，第二层是音频驱动层，包括Linux ALSA音频驱动框架，负责驱动音频Codec，管理数字音频接口(DAI)，对应用层提供字符设备接口。第三层是音频HAL(Hardware Abstraction Laye，硬件抽象层)，对上层(如第四层)屏蔽不同的硬件。第四层是音频核心框架(Framework)层，Android核心的音频处理逻辑都在此层实现，可以对上层应用程序APP提供丰富的接口，上层APP可以通过调用Framework提供的接口实现录音、编辑、播放等功能。当App1和App2需要共享音频数据时，由于不同APP的进程之间不能互相访问，导致如果一个APP的进程要访问另外一个APP的进程的音频数据，就需要拷贝一次音频数据，然后才能处理或者播放该音频数据，但是目前拷贝音频数据的方式极大降低了音频数据的使用效率，在特殊场景下还可能造成音频丢帧、卡顿等情况。例如当App1需要对音频数据C进行录音，同时APP2需要对该音频数据C添加水印，则目前每个APP在使用该音频数据C时都需要拷贝1次音频数据，共拷贝2次音频数据才能实现对音频数据的处理，导致音频数据的使用效率降低。
为了提高音频数据的使用效率，避免造成音频丢帧、卡顿的情况，本实施例提供一种数据共享的方法，能够在对音频数据零拷贝的情况下，实现对音频数据的访问、处理，从而有效提高音频数据的使用效率。本实施例的核心思想是将音频数据存储到内存，并根据内存地址确定文件描述符后，将文件描述符在不同应用程序中共享，当多个应用程序需要共享(使用)某个音频数据时，可以将该音频数据的文件描述符在多个应用程序中共享，即将该 音频数据的文件描述符在多个应用程序中传输，应用程序可以根据文件描述符确定内存地址后，从该内存地址读取音频数据，从而对音频数据进行处理。本实施例通过将音频数据的内存地址映射成文件描述符，并将文件描述符在不同应用程序中共享的方式，实现音频数据在不同应用程序间的共享。
需要说明的是，本实施例中的数据共享的方法，还可以应用于非音频数据的其他类型的数据，基于本实施例的原理实现的数据共享的方法，都属于本公开的保护范围。
如图2所示，本实施例提供的一种数据共享的方法，可以应用于安卓系统，该方法的具体实施流程如下所示：
步骤200、获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
在一些实施例中，不同应用程序之间待共享的目标音频数据可以是不同应用程序之间同时处理的目标音频数据。需要说明的是，此处的同时处理包括但不限于在时间上完全对齐的处理，或在时间上不完全对齐的处理，即相对于两个不同应用程序而言，对应的处理时间可以存在一定程度上的延时。
作为一种可选的实施方式，本实施例中的所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；其中，所述不同应用程序对所述目标音频数据的处理具有时间延迟。
在一些实施例中，本实施例中的不同应用程序包括在安卓系统运行的不同应用程序。
在一些实施例中，通过如下步骤获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
实施中，音频数据都存储在对应的硬件寄存器中，当确定不同应用程序 之间需共享目标音频数据时，从该目标音频数据对应的硬件寄存器中读取该目标音频数据，并将该目标音频数据存储到内存。
其中，本实施例中的硬件寄存器可以是硬件接口控制器中的硬件寄存器，用于进行目标音频数据存储、缓存。其中，任何VXI总线器件，不管其功能如何，都必须有一组配置寄存器，系统通过访问VME总线上PI口的配置寄存器来识别器件的类型、型号、生产厂家、地址空间与所要求的存储器空间。仅有这种最低通信能力的VXI总线器件就是寄存器基器件。通过这组公共的配置寄存器、中央资源管理器和基本的软件模块，可以在系统初始化时自动进行系统与存储器配置。
在一些实施例中，本实施例通过如下方式从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
实施中，当确定不同应用程序之间需共享目标音频数据时，利用直接内存访问机制，将该目标音频数据对应的硬件寄存器中的该目标音频数据读取到物理内存中。
需要说明的是，直接内存访问机制包括但不限于DMA(Direct Memory Access，直接内存访问)机制，可以不经过CPU而直接从物理内存中存取数据。在DMA模式下，CPU只须向DMA控制器下达指令，让DMA控制器来处理数据的传送，数据传送完毕再把信息反馈给CPU，从而很大程度上减轻了CPU资源占有率，可以有效节省系统资源。
在一些实施例中，通过如下步骤将所述硬件寄存器中的所述目标音频数据存储到物理内存中：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；将所述目标音频数据存储到分配的连续的物理内存中。
实施中，连续内存分配技术包括但不限于CMA(Contiguous Memory Allocator，连续内存分配器)，工作原理是预留部分物理内存给驱动使用，但 当驱动不使用时，内存分配器(memory allocator)或伙伴制(buddy system)可以分配给用户进程用作匿名内存或者页缓存，而当驱动需要使用时，则通过回收或者迁移的方式将进程占用的物理内存预留出来，以供驱动使用。
由于使用连续内存分配技术能够分配连续的物理内存，从而保证了音频数据的存储是连续的，在共享目标音频数据的文件描述符时，能够根据文件描述符读取到完整的目标音频数据。
若在所述第一应用录制音频时确定使用所述第二应用为录制的音频添加水印，则将录制的音频作为待共享的目标音频数据存储到物理内存；
还可以将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
在一些实施例中，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。并且，通过第二应用从物理内存中读取录制的音频并为录制的音频添加水印。
实施中，通过麦克接收录制的音频信号后，利用音频硬件层(音频Codec Hardware)对音频信号进行模数转换，编解码处理等，输出目标音频数据，将目标音频数据通过硬件接口控制器中的硬件寄存器进行缓存，利用SoC从所述硬件寄存器中读取所述目标音频数据，并存储到物理内存中；利用操作系统的内核将存储所述目标音频数据的物理内存地址，分别映射到第一应用和第二应用的虚拟内存地址，此时，可以将目标音频数据存储虚拟内存地址对应的环形缓冲中，以及建立第一应用和第二应用的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符，当在所述第一应用录制音频时确定使用所述第二应用为录制的音频添加水印时，第一应用利用音频框架获取目标音频数据对应的文件描述符，并根据文件描述符和第一应用的虚拟内存地址的映射关系，对所述虚拟内存 地址对应的环形缓冲中的目标音频数据继续进行录音，同时，第二应用也利用音频框架获取目标音频数据对应的文件描述符，并根据文件描述符和第二应用的虚拟内存地址的映射关系，对所述虚拟内存地址对应的环形缓冲中的目标音频数据继续添加水印。
在一些实施例中，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物理内存；还可以将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
实施中，通过第三应用播放包含水印的音频时，第三应用从虚拟内存地址对应的环形缓冲中读取包含水印的音频并进行播放，根据包含水印的音频的在第三应用中的虚拟内存地址，确定映射的物理内存，将包含水印的音频存储到物理内存，然后通过硬件接口控制器中的硬件寄存器进行缓存，输出到音频硬件层进行模数转换，编解码处理后，输出到喇叭端进行播放，同时，当在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证时，利用操作系统的内核将存储所述目标音频数据的物理内存地址，分别映射到第三应用和第四应用的虚拟内存地址，以及建立第三应用和第四应用的虚拟内存地址和同一文件描述符的映射关系，将播放的包含水印的音频作为目标音频数据，根据所述映射关系确定所述目标音频数据对应的文件描述符，当在所述第三应用录制音频时确定使用所述第四应用为录制的音频添加水印时，第三应用利用音频框架获取目标音频数据对应的文件描述符，并根据文件描述符和第三应用的虚拟内存地址的映射关系，对所述虚拟内存地址对应的环形缓冲中的目标音频数据继续进行播放，同时，第四应用也利用音频框架获取目标音频数据对应的文件描述符，并根据文件描述符和第四应用的虚拟内存地址的映射关系，对所述虚拟内存地址对应的环形缓冲中的目 标音频数据进行水印验证，以验证水印的合法性。
本实施例中的第一应用和第三应用可以是相同的应用程序，也可以是不同的应用程序，本实施例中的第二应用和第四应用可以是相同的应用程序，也可以是不同的应用程序，本实施例对此不作过多限定。
步骤201、根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
在一些实施例中，利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
需要说明的是，在APP启动时，为APP分配的虚拟内存的大小是固定的，即APP的可用虚拟内存的大小是固定的，在APP运行的过程中，根据进程运行的实际情况再确定虚拟内存的实际大小。
其中，系统的物理内存被划分为许多相同大小的部分，也称作内存页。内存页的大小取决于CPU的架构和操作系统的配置，物理内存的使用主要分为以下一种或几种情况：
(1)内核使用的情况
操作系统启动时，位于/boot目录下的压缩内核文件会被加载到物理内存中并解压。这部分内容在系统允许期间都会常驻在内存的起始位置。
(2)slab分配器使用的情况
操作系统的运行还需要更多的空间来分配给管理进程、文件描述符、socket和加载的内核模块等内容。所以内核会通过slab分配器动态分配物理内存。
(3)进程使用的情况
除去内核使用的部分，所有的进程都需要分配物理内存页给它们的代码、数据和堆栈。进程消耗的这些物理内存被称为“驻留内存”，RSS。
(4)页缓存page cache使用的情况
除去在内核和进程使用的部分，物理内存剩下的部分被称为页缓存(page cache)。因为磁盘IO的速度远远低于内存的访问速度，所以为了加快访问磁盘数据的速度，页缓存尽可能的保存着从磁盘读入的数据。page cache中还有一部分称为buffer(缓存)，它的作用是缓存要写入到磁盘的数据。
虚拟内存实际上并不存在，它只是存在于这套巧妙的内存管理机制中。当一个进程启动时，内核会给新的进程建立一个虚拟地址空间。这个虚拟地址空间代表了该进程可能使用到的所有内存，当然它是可以动态变化的。虚拟地址结构示意图如下，从下往上地址增大，主要包括以下几个部分：
(1)代码段：该部分只读，用于存放加载的代码。
(2)数据段：用于存放全局变量和静态变量。
(3)堆：动态内存，当malloc/free申请释放内存小于某个阈值时，通过brk/sbrk系统调用，控制堆顶指针向高地址偏移(malloc)或者低地址偏移(free)。
(4)文件映射区：动态内存，当malloc/free申请释放内存大于128K时，通过mmap系统调用分配一块虚拟地址空间。
(5)栈：用于存放局部变量和进程上下文。
由于成本的限制，物理内存往往无法做的很大，但是进程运行阶段所需申请的内存可能远远超过物理内存，并且系统不可能只跑一个进程，会有多个进程一起申请使用内存，如果都直接向物理内存进行申请使用肯定无法满足。通过引入虚拟内存，每个进程都有自己独立的虚拟地址空间，这个空间理论上可以无限大，一个进程同一时刻不可能所有变量数据都会访问到，只需要在访问某部分数据时，把这一块虚拟内存映射到物理内存，其他没有实际访问过的虚拟地址空间并不会占用到物理内存，这样对物理内存的消耗就极大减少了。系统内核为每个进程都维护了一份从虚拟内存到物理内存的映射表，也称为页表。页表根据虚拟地址，查找出映射的物理页位置和数据在物理页中的偏移量，便得到了实际需要访问的物理地址。
在一些实施例中，本实施例确定目标音频数据后，可以先将目标音频数据存储到物理内存，将物理内存映射到不同应用程序的虚拟内存，并将不同 应用程序的虚拟内存地址映射为同一个文件描述符，具体实施步骤如下所示：
(1)将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
在一些实施例中，通过如下方式确定虚拟内存地址：
根据预先建立的物理内存地址和虚拟内存地址的映射关系，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址。
实施中，由于虚拟内存地址在不同应用程序之间是相互隔离的，因此不能在不同应用程序间直接传递虚拟内存地址，则需要通过如下步骤转换为文件描述符后在不同应用程序间传递。
(2)建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
本实施例中的文件描述符，在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。内核(kernel)利用文件描述符(file descriptor)来访问文件。文件描述符是非负整数。打开现存文件或新建文件时，内核会返回一个文件描述符。读写文件也需要使用文件描述符来指定待读写的文件。
可选的，本实施例中的文件描述符包括但不限于句柄。其中，句柄是一个是用来标识对象或者项目的标识符，可以用来描述窗体、文件等。句柄是根据内存管理机制的问题，即虚拟地址的问题设定的。如果数据的地址需要变动，变动以后则需要记录并管理变动，因此通过句柄来记载数据地址的变更。在程序设计中，句柄是一种特殊的智能指针，当一个应用程序要引用其他系统(如数据库、操作系统)所管理的内存块或对象时，则可以使用句柄。
在一些实施例中，建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
实施中，可以根据IDR表中的虚拟内存地址和句柄的映射关系，将不同应用程序的虚拟内存地址映射为同一个句柄。
在一些实施例中，通过如下方式将所述文件描述符在所述不同应用程序中共享：
将不同应用程序的虚拟内存地址映射为相同的文件描述符，在不同应用程序中共享所述文件描述符，以使不同应用程序对所述文件描述符映射的虚拟内存地址对应的目标音频数据进行相应处理。
步骤202、将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
在一些实施例中，利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
实施中，可以将音频数据对应的句柄在不同应用程序中传递，每个应用程序获取句柄后转换为该应用程序的虚拟内存地址，从而根据该虚拟内存地址映射的物理内存地址访问音频数据，实现不用拷贝音频数据，就能访问相关音频数据的目的，通过这种方式能够有效的提高音频数据在App之间的传递效率，有效的解决了音频丢帧、卡顿问题，并且在音频不同的处理阶段，不同的处理层次，不同的App中，都能很好的定位问题。
如图3所示，本实施例提供一种音频处理框架，包括音频硬件层、音频驱动层、音频硬件抽象层、音频核心框架层，其中音频驱动层包括DMA地址管理层，CMA缓存层，虚拟地址映射层；本实施例中的音频驱动层可以利用DMA地址管理层的DMA机制，将目标音频数据从硬件寄存器存储到物理内存中，利用CMA缓存层的CMA技术，为目标音频数据分配连续的物理内存，将物理内存映射到不同应用程序的虚拟内存，利用虚拟地址映射层，将不同应用程序的虚拟内存地址映射成一个句柄，即确定目标音频数据对应的句柄，将句柄在不同应用程序或不同的进程中传输，使得每个应用程序或进程将句柄转换为该应用程序或进程中的虚拟内存地址，从而获取目标音频数据。
其中，音频处理框架还包括环形缓冲区，用于缓存音频数据(目标音频数据)，环形缓冲区中的内存结构是环形的，有一个头指针和一个尾指针，由N块虚拟内存组成，本实施例中，将每个内存块(对应一个虚拟内存地址) 都被映射一个句柄提供给应用层的应用程序，使得句柄可以在不同的进程和不同的App之间传递，每个进程获取句柄后将其转换成虚拟内存指针(虚拟内存地址)，从而获取到环形缓冲区中的所有音频数据。
如图4所示，本实施例提供一种不同进程共享音频数据的架构图，包括CMA缓存层、虚拟地址映射层、环形缓冲区、进程A、进程B，其中，利用CMA缓存层的CMA技术，为目标音频数据分配连续的物理内存如P1～P4，并将物理内存P1～P4映射到虚拟内存V1～V4，利用虚拟地址映射层，将虚拟内存地址(V1～V4)分别映射到句柄，即确定目标音频数据对应的句柄(G1～G4)，其中，V1映射为G1，V2映射为G2，V3映射为G3，V4映射为G4，将句柄(G1～G4)在不同应用程序或不同的进程中传输，使得不同应用程序或不同的进程将句柄(G1～G4)转换为虚拟内存地址(V1～V4)，从而获取目标音频数据即P1～P4中的目标音频数据。其中，环形缓冲区存储目标音频数据，环形缓冲区中的每个内存块有一个虚拟内存地址，将环形缓冲区中的V1～V4映射为句柄(G1～G4)，每个进程获取句柄后将其转换成虚拟内存地址，从而获取到环形缓冲区中的所有数据。
如图5所示，本实施例还提供一种音频数据共享的方法的实施流程，具体如下所示：
步骤500、当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
步骤501、利用直接内存访问机制和连续内存分配技术，为目标音频数据分配连续的物理内存，将目标音频数据存储到分配的连续的物理内存中；
步骤502、根据预先建立的物理内存和虚拟内存的映射关系，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；
步骤503、将不同应用程序的虚拟内存地址映射为同一句柄；
步骤504、在不同应用程序中共享句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
如图6所示，本实施例提供一种录音加水印的音频数据共享方法，该方 法的实施流程如下所示：
步骤600、在第一应用录制音频时确定为录制的音频添加水印；
步骤601、利用DMA和CMA技术，将录制的音频作为待共享的目标音频数据存储到连续的物理内存；
步骤602、将存储所述目标音频数据的物理内存地址，分别映射到第一应用的第一虚拟内存地址和第二应用的第二虚拟内存地址；
步骤603、将第一虚拟内存地址和第二虚拟内存地址都映射为同一句柄；
步骤604、将句柄在第一应用和第二应用中传输；
步骤605、第一应用根据句柄映射的第一虚拟内存地址获取目标音频数据，进行目标音频数据的录制，第二应用根据句柄映射的第二虚拟内存地址获取目标音频数据，为目标音频数据添加水印。
如图7所示，本实施例提供一种播放验证水印的音频数据共享方法，该方法的实施流程如下所示：
步骤700、在第一应用播放包含水印的音频时确定进行水印的提取和验证；
步骤701、利用DMA和CMA技术，将包含水印的音频作为待共享的目标音频数据存储到连续的物理内存；
步骤702、将存储所述目标音频数据的物理内存地址，分别映射到第一应用的第一虚拟内存地址和第二应用的第二虚拟内存地址；
步骤703、将第一虚拟内存地址和第二虚拟内存地址都映射为同一句柄；
步骤704、将句柄在第一应用和第二应用中传输；
步骤705、第一应用根据句柄映射的第一虚拟内存地址获取目标音频数据，进行目标音频数据的播放，第二应用根据句柄映射的第二虚拟内存地址获取目标音频数据，进行目标音频数据中水印的提取和验证。
本实施例提供的音频数据共享的方法，实现了多应用多进程之间不需要拷贝音频数据，就能互相访问和播放，有效解决了音频播放延迟、卡顿等问题，还可以有效降低拷贝过程中音频数据出错的风险，由于不需要拷贝音频数据，因此能够提高定位问题的效率。
实施例2、基于相同的发明构思，本公开实施例还提供了一种数据共享的系统，由于该系统即是本公开实施例中的方法中的系统，并且该系统解决问题的原理与该方法相似，因此该系统的实施可以参见方法的实施，重复之处不再赘述。
如图8所示，本公开实施例还提供一种数据共享的系统，该系统包括：音频驱动模块800和音频框架模块801，其中：
所述音频驱动模块800，被配置为获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
所述音频框架模块801，被配置为将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
作为一种可选的实施方式，所述音频驱动模块800具体被配置为执行：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
作为一种可选的实施方式，所述音频驱动模块800具体被配置为执行：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
作为一种可选的实施方式，所述音频驱动模块800具体被配置为执行：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
将所述目标音频数据存储到分配的连续的物理内存中。
作为一种可选的实施方式，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
所述音频驱动模块800具体被配置为执行：
通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器 中；
将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
作为一种可选的实施方式，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
所述音频驱动模块800具体被配置为执行：
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物理内存；
所述音频驱动模块800具体还被配置为执行：
将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
作为一种可选的实施方式，所述目标音频数据存储在物理内存；
所述音频驱动模块800具体被配置为执行：
将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述音频驱动模块800具体被配置为执行：
利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述音频驱动模块800具体被配置为执行：
建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
作为一种可选的实施方式，所述音频框架模块801具体被配置为执行：
将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
作为一种可选的实施方式，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
作为一种可选的实施方式，所述不同应用程序包括在安卓系统运行的不同应用程序。
作为一种可选的实施方式，所述音频框架模块801具体被配置为执行：
利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
作为一种可选的实施方式，所述方法还包括延迟处理模块具体被配置为执行：
所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
所述对所述目标音频数据进行处理，包括：
所述不同应用程序对所述目标音频数据的处理具有时间延迟。
实施例3、基于相同的发明构思，本公开实施例还提供了一种数据共享的装置，由于该装置即是本公开实施例中的方法中的装置，并且该装置解决问题的原理与该方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。
如图9所示，该装置包括：
获取音频单元900，用于获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
地址映射单元901，用于根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
音频共享单元902，将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
作为一种可选的实施方式，所述获取音频单元900具体用于：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
作为一种可选的实施方式，所述获取音频单元900具体用于：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
作为一种可选的实施方式，所述获取音频单元900具体用于：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
将所述目标音频数据存储到分配的连续的物理内存中。
作为一种可选的实施方式，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
所述获取音频单元900具体用于：
通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；
将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
作为一种可选的实施方式，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
所述获取音频单元900具体用于：
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物 理内存；
还包括转存单元具体用于：
将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
作为一种可选的实施方式，所述目标音频数据存储在物理内存；所述地址映射单元901具体用于：
将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述地址映射单元901具体用于：
利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述地址映射单元901具体用于：
建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
作为一种可选的实施方式，所述音频共享单元902具体用于：
将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
作为一种可选的实施方式，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
作为一种可选的实施方式，所述不同应用程序包括在安卓系统运行的不同应用程序。
作为一种可选的实施方式，所述音频共享单元902具体用于：
利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
作为一种可选的实施方式，还包括延迟处理单元具体用于：
所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
所述延迟处理单元具体用于：
所述不同应用程序对所述目标音频数据的处理具有时间延迟。
实施例4、基于相同的发明构思，本公开实施例还提供了一种数据共享的设备，由于该设备即是本公开实施例中的方法中的设备，并且该设备解决问题的原理与该方法相似，因此该设备的实施可以参见方法的实施，重复之处不再赘述。
如图10所示，该设备包括处理器1000和存储器1001，所述存储器1001用于存储所述处理器1000可执行的程序，所述处理器1000用于读取所述存储器1001中的程序并执行如下步骤：
获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
作为一种可选的实施方式，所述处理器1000具体被配置为执行：
当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
作为一种可选的实施方式，所述处理器1000具体被配置为执行：
利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
作为一种可选的实施方式，所述处理器1000具体被配置为执行：
利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
将所述目标音频数据存储到分配的连续的物理内存中。
作为一种可选的实施方式，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
所述处理器1000具体被配置为执行：
通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；
将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
作为一种可选的实施方式，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证包含水印的音频中的水印；
所述处理器1000具体被配置为执行：
若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物理内存；
所述处理器1000具体还被配置为执行：
将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
作为一种可选的实施方式，所述目标音频数据存储在物理内存；
所述处理器1000具体被配置为执行：
将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据 所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述处理器1000具体被配置为执行：
利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
作为一种可选的实施方式，所述处理器1000具体被配置为执行：
建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
作为一种可选的实施方式，所述处理器1000具体被配置为执行：
将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
作为一种可选的实施方式，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
作为一种可选的实施方式，所述不同应用程序包括在安卓系统运行的不同应用程序。
作为一种可选的实施方式，所述处理器1000具体被配置为执行：
利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
作为一种可选的实施方式，所述处理器1000具体还被配置为执行：
所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
所述处理器具体被配置为执行：
所述不同应用程序对所述目标音频数据的处理具有时间延迟。
基于相同的发明构思，本公开实施例还提供了一种计算机存储介质，其 上存储有计算机程序，该程序被处理器执行时实现如下步骤：
获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
本领域内的技术人员应明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本公开是参照根据本公开实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品，该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图 一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本公开进行各种改动和变型而不脱离本公开的精神和范围。这样，倘若本公开的这些修改和变型属于本公开权利要求及其等同技术的范围之内，则本公开也意图包含这些改动和变型在内。

Claims (17)

  1. 一种数据共享的方法，其中，该方法包括：
    获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；
    根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
    将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
  2. 根据权利要求1所述的方法，其中，所述获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存，包括：
    当不同应用程序之间需共享所述目标音频数据时，确定所述目标音频数据的硬件寄存器；
    从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存。
  3. 根据权利要求2所述的方法，其中，所述从所述硬件寄存器中获取所述目标音频数据，将所述目标音频数据存储到内存，包括：
    利用直接内存访问机制，将所述硬件寄存器中的所述目标音频数据存储到物理内存中。
  4. 根据权利要求2所述的方法，其中，所述将所述硬件寄存器中的所述目标音频数据存储到物理内存中，包括：
    利用连续内存分配技术，为所述目标音频数据分配连续的物理内存；
    将所述目标音频数据存储到分配的连续的物理内存中。
  5. 根据权利要求1所述的方法，其中，所述不同应用程序包括第一应用和第二应用；所述第一应用用于录制音频，所述第二应用用于为音频添加水印；
    所述获取不同应用程序之间待共享的目标音频数据，将所述目标音频数 据存储到内存，包括：
    通过第一应用获取录制的音频，并将所述录制的音频存储在硬件寄存器中；
    将所述录制的音频作为所述第一应用和所述第二应用之间待共享的目标音频数据，将所述硬件寄存器中存储的所述录制的音频存储到物理内存。
  6. 根据权利要求1所述的方法，其中，所述不同应用程序包括第三应用和第四应用；所述第三应用用于播放包含水印的音频，所述第四应用用于验证所述包含水印的音频中的水印；
    所述获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存，包括：
    若在所述第三应用播放包含水印的音频时确定使用所述第四应用进行水印的验证，则将播放的包含水印的音频作为待共享的目标音频数据存储到物理内存；
    所述方法还包括：
    将所述包含水印的音频由所述物理内存转存到硬件寄存器，以使音频硬件从所述硬件寄存器中读取所述包含水印的音频并进行播放。
  7. 根据权利要求1～6任一所述的方法，其中，所述目标音频数据存储在物理内存；
    所述根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符，包括：
    将存储所述目标音频数据的物理内存地址，分别映射到不同应用程序的虚拟内存地址；其中虚拟内存地址在不同应用程序之间是相互隔离的；
    建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
  8. 根据权利要求7所述的方法，其中，所述根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符，包括：
    利用操作系统的内核，将存储所述目标音频数据的物理内存地址，分别 映射到不同应用程序的虚拟内存地址，以及建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符。
  9. 根据权利要求7所述的方法，其中，所述建立不同应用程序的虚拟内存地址和同一文件描述符的映射关系，根据所述映射关系确定所述目标音频数据对应的文件描述符，包括：
    建立不同应用程序的虚拟内存地址和同一句柄的映射关系，根据所述映射关系确定所述目标音频数据对应的句柄。
  10. 根据权利要求9所述的方法，其中，所述将所述文件描述符在所述不同应用程序中共享，包括：
    将不同应用程序的虚拟内存地址映射为同一句柄，在不同应用程序中共享所述句柄，以使不同应用程序对所述句柄映射的虚拟内存地址对应的目标音频数据进行相应处理。
  11. 根据权利要求1所述的方法，其中，所述待共享的目标音频数据包括所述不同应用程序同时处理的目标音频数据。
  12. 根据权利要求1所述的方法，其中，所述不同应用程序包括在安卓系统运行的不同应用程序。
  13. 根据权利要求1所述的方法，其中，所述将所述文件描述符在所述不同应用程序中共享，包括：
    利用音频框架将所述文件描述符传输给不同应用程序，以使所述文件描述符在所述不同应用程序中共享。
  14. 根据权利要求1～6任一所述的方法，其中，所述方法还包括：
    所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据，并在对所述目标音频数据进行处理；
    所述对所述目标音频数据进行处理，包括：
    所述不同应用程序对所述目标音频数据的处理具有时间延迟。
  15. 一种数据共享的系统，其中，包括音频驱动模块和音频框架模块， 其中：
    所述音频驱动模块，被配置为获取不同应用程序之间待共享的目标音频数据，将所述目标音频数据存储到内存；根据存储所述目标音频数据的内存地址，确定所述目标音频数据对应的文件描述符；
    所述音频框架模块，被配置为将所述文件描述符在所述不同应用程序中共享，以使所述不同应用程序根据所述文件描述符对应的内存地址获取所述目标音频数据。
  16. 一种数据共享的设备，其中，该设备包括处理器和存储器，所述存储器用于存储所述处理器可执行的程序，所述处理器用于读取所述存储器中的程序并执行权利要求1～14任一所述方法的步骤。
  17. 一种计算机存储介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如权利要求1～14任一所述方法的步骤。
PCT/CN2022/109186 2022-07-29 2022-07-29 一种数据共享的方法及设备 WO2024021096A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202280002470.4A CN117795485A (zh) 2022-07-29 2022-07-29 一种数据共享的方法及设备
PCT/CN2022/109186 WO2024021096A1 (zh) 2022-07-29 2022-07-29 一种数据共享的方法及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/109186 WO2024021096A1 (zh) 2022-07-29 2022-07-29 一种数据共享的方法及设备

Publications (1)

Publication Number Publication Date
WO2024021096A1 true WO2024021096A1 (zh) 2024-02-01

Family

ID=89705091

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/109186 WO2024021096A1 (zh) 2022-07-29 2022-07-29 一种数据共享的方法及设备

Country Status (2)

Country Link
CN (1) CN117795485A (zh)
WO (1) WO2024021096A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118037531A (zh) * 2024-03-04 2024-05-14 北京七维视觉传媒科技有限公司 一种基于UE5、Windows内存的纹理共享的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180349289A1 (en) * 2017-06-02 2018-12-06 Kai-Ting Amy Wang Global variable migration via virtual memory overlay technique for multi-version asynchronous dynamic software update
CN112802232A (zh) * 2021-03-22 2021-05-14 智道网联科技(北京)有限公司 视频流数据的传输方法及其相关装置
CN112906075A (zh) * 2021-03-15 2021-06-04 北京字节跳动网络技术有限公司 一种内存共享的方法及装置
CN113220262A (zh) * 2021-03-26 2021-08-06 西安神鸟软件科技有限公司 一种多应用程序的音频数据分发方法及终端设备
CN114595084A (zh) * 2022-05-10 2022-06-07 麒麟软件有限公司 一种Linux操作系统上系统级进程间视频共享方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180349289A1 (en) * 2017-06-02 2018-12-06 Kai-Ting Amy Wang Global variable migration via virtual memory overlay technique for multi-version asynchronous dynamic software update
CN112906075A (zh) * 2021-03-15 2021-06-04 北京字节跳动网络技术有限公司 一种内存共享的方法及装置
CN112802232A (zh) * 2021-03-22 2021-05-14 智道网联科技(北京)有限公司 视频流数据的传输方法及其相关装置
CN113220262A (zh) * 2021-03-26 2021-08-06 西安神鸟软件科技有限公司 一种多应用程序的音频数据分发方法及终端设备
CN114595084A (zh) * 2022-05-10 2022-06-07 麒麟软件有限公司 一种Linux操作系统上系统级进程间视频共享方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118037531A (zh) * 2024-03-04 2024-05-14 北京七维视觉传媒科技有限公司 一种基于UE5、Windows内存的纹理共享的方法

Also Published As

Publication number Publication date
CN117795485A (zh) 2024-03-29

Similar Documents

Publication Publication Date Title
US11656775B2 (en) Virtualizing isolation areas of solid-state storage media
US6950107B1 (en) System and method for reserving and managing memory spaces in a memory resource
US5864876A (en) DMA device with local page table
US8554987B2 (en) Nonvolatile memory system for improving stream data writing
US11256445B2 (en) Virtual disk file format conversion method and apparatus
US7707337B2 (en) Object-based storage device with low process load and control method thereof
KR20090026941A (ko) 복수개의 비휘발성 데이터 저장매체를 구비한 저장장치의가상 파일 시스템에서 어드레스 맵핑을 수행하는 방법 및그 장치
US9086920B2 (en) Device for managing data buffers in a memory space divided into a plurality of memory elements
US8407443B1 (en) Off-chip out of order memory allocation for a unified shader
WO2017005010A1 (zh) 音频处理方法及设备、计算机存储介质
KR20080056584A (ko) 비휘발성 데이터 저장장치에 구비된 가상 파일 시스템의작업 스케줄링 방법 및 장치
US20130246761A1 (en) Register sharing in an extended processor architecture
JP2007280068A (ja) フラッシュメモリ装置及びフラッシュメモリへのアクセス方法
US11989588B2 (en) Shared memory management method and device
US20110317763A1 (en) Information processing apparatus and information processing method
WO2024021096A1 (zh) 一种数据共享的方法及设备
JP2012510101A (ja) フラッシュ変換層を有するフラッシュ・ベースのメモリおよびファイル記憶方法
WO2024108825A1 (zh) 内存备份加速方法、装置、设备及非易失性可读存储介质
US7865632B2 (en) Memory allocation and access method and device using the same
JP2006294028A (ja) 直接実行機能を提供するためのシステム、コンピュータシステム、方法およびプログラム
KR20060017816A (ko) 주 메모리와 기억 장치 사이에서 데이터를 전송하는 방법및 장치
US7984240B2 (en) Memory compression implementation in a system with directly attached processor memory
US5918302A (en) Digital sound-producing integrated circuit with virtual cache
TW202132993A (zh) 堆疊管理
US9298460B2 (en) Register management in an extended processor architecture

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 202280002470.4

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22952543

Country of ref document: EP

Kind code of ref document: A1