Advanced audio processing system

Abstract

An audio processing system may include at least one memory programmed to store a plurality of audio objects and first information corresponding to a plurality of cores associated with a system on chip (SoC) device; and a computing device programmed to: provide, on the display, first information corresponding to a plurality of cores associated with the SoC device; providing a plurality of audio objects on the display; receiving a first input indicating a tuning parameter to be applied to a first audio object of the plurality of audio objects; receiving a second input indicating a first selected SoC device to apply the tuning parameter to the first audio object; and applying the tuning parameter to the first audio object with the first selected SoC device to generate an audio output signal.

Description

[0001] This application is a divisional of application number 201880084738.7, filing date December 31, 2018, and titled “Advanced Audio Processing System”. Technical Field

[0002] An advanced audio processing system is disclosed herein. Background Art

[0003] Audio product development can include various applications of signal processing, setting assignments, parameters, etc. to new and existing products. As the number and diversity of products that include audio components increase, manufacturers are challenged by shortening product life cycles, increasing costs, consumer demands for rich experiences, and other constraints. Summary of the invention

[0004] An audio processing system may include: at least one memory configured to maintain a plurality of audio signal processing algorithms and audio components; and a server having a processor. The processor may be configured to: present an interface displaying at least a portion of the signal processing algorithms and the audio components; receive a user selection of at least one of the audio components; present the at least one selected audio component via the interface; receive a user selection of at least one of the signal processing algorithms to apply to the at least one selected audio component; apply the at least one selected algorithm to the at least one selected audio component; and provide measurements of the at least one selected algorithm and the at least one selected audio component via the interface.

[0005] A method for an audio processing system may include: presenting an interface displaying multiple signal processing algorithms and audio components; receiving a user selection of at least one of the audio components; presenting the at least one selected audio component via the interface; receiving a user selection of at least one of the signal processing algorithms to apply to the at least one selected audio component; applying the at least one selected algorithm to the at least one selected audio component; and providing measurements of the at least one selected algorithm and the at least one selected audio component via the interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Embodiments of the present disclosure are particularly pointed out in the appended claims. However, other features of the various embodiments will become more apparent and will be best understood by referring to the following detailed description in conjunction with the accompanying drawings, in which:

[0007] Figure 1 shows a block diagram of an audio processing system according to one embodiment;

[0008] Figure 2 An example extensible audio framework (xAF) is shown;

[0009] Figure 3 An example design flow for xAF is shown;

[0010] Figure 4 An example development kit integration is shown;

[0011] Figure 5A and Figure 5B A block diagram showing various aspects of a global tuning tool (GTT);

[0012] Fig. 6A An example audio panel of a GTT is shown;

[0013] Figure 6B Another example audio panel of the GTT is shown;

[0014] Figure 6C Another example audio panel of the GTT is shown;

[0015] Fig.6D Another custom audio panel from GTT is shown;

[0016] Fig. 6E An example signal flow design panel of a GTT is shown;

[0017] Fig. 6F An example database panel of a system with an algorithm toolbox is shown;

[0018] Figure 6G An example properties panel for a system is shown;

[0019] Figure 6H An example native panel for a selected object is shown;

[0020] Fig.6I An example system-on-chip (SoC) panel is shown;

[0021] Figure 6J An example system function editing panel is shown;

[0022] Figure 6K shows an example native panel created in response to an edit panel;

[0023] Figure 7 An example transaction process of a GTT is shown;

[0024] Figure 8 An example block diagram of the entire system is shown;

[0025] Fig. 9shows an example configuration of a GTT in which multiple devices are configured simultaneously;

[0026] Fig.10 An example flow chart showing a process for a measurement routine;

[0027] Fig.11 An example measurement panel is shown; and

[0028] Fig.12 An example links panel is shown. DETAILED DESCRIPTION

[0029] As required, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely examples of the present invention that can be embodied in various and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art to employ the present invention in various ways.

[0030] Manufacturers of audio components aim to implement the best possible audio and active noise management solutions for a given architectural framework with the ability to scale to multiple platforms. However, due to the demands on product development, a streamlined audio development and design process is beneficial.

[0031] An enhanced system for both business-to-business and business-to-consumer uses is disclosed, allowing a single audio framework to be used globally across platforms and projects to provide a single workflow and structure for audio feature development and use. The audio processing system allows the power and flexibility of audio objects and tuning strategies to be used seamlessly to provide quality sound at various system levels from entry-level to high-complexity systems without the need for hardware upgrades. The system pushes updates over the air and provides pay-as-you-go monetization. The system allows an easily customizable audio product build mechanism that allows designers to pick and choose products, apply various parameters and processing to those products, and analyze the build to facilitate seamless optimization of product development.

[0032] The system provides a graphical signal flow designer that enables system engineers to configure, tune and measure their complex signal and data flows in one place. The system is device independent and comes with a virtual amplifier for simulation and rapid prototyping. The system is designed to work on one or more cores of a single processor, digital signal processor (DSP), or SoC. The system is designed to work on multiple devices simultaneously (e.g., signal flows on the head unit and amplifiers can all be configured and tuned through one instance of the system).

[0033] The system provides a host-server application (AmpSrv2) for communication with virtual or target devices and supports multiple physical interfaces. The system is designed to support full customization of tuning panels by using custom panels, native panels, and a mix of both panel types. The system has a proprietary tuning protocol (xTP) for efficient two-way communication with virtual or target devices. The system provides measurement modules designed to enable direct communication with target devices for simple and efficient automation of a wide range of audio measurement routines. The system provides a linking mechanism for state variables with an intuitive UX / UI concept.

[0034] Figure 1 A block diagram of an audio processing system 100 is shown. The system 100 may include: a processor 110, which includes a DSP library or DSP database 102; a global tuning tool (GTT) 105, which includes a DSP flow designer 104 and a DSP tuning block 106; a simulation block 108; and a compilation block 112. The processor 110 may be a general-purpose processor, a digital signal processor (DSP), etc. The processor 110 may be local to the system 100 or remote from the system. The processor 110 may include a controller (not shown). The controller may generally be coupled to a memory for operating instructions to execute the equations and methods described herein. Generally speaking, the controller is programmed to perform various methods as indicated herein.

[0035] The DSP database 102 may include a library of available tuning algorithms, digital signal processing applications and libraries, a library of devices, etc. The database 102 may include memory that is separate or shared by the controllers.

[0036] The database 102 may include an audio algorithm toolbox (AAT) consisting of hundreds of components of standardized audio algorithms. The database 102 may include an extensible audio framework (xAF), which consists of a standardized DSP framework, fast design, and fast porting on different hardware, with high flexibility and efficiency in the market. The database 102 may also include a GTT 105 to configure the audio algorithm database and DSP framework and tune and control various algorithms. Additionally or alternatively, the GTT 105 may be separate from the database, such as Figure 1 as shown in the example.

[0037] The audio processing system 100 allows a comprehensive audio development solution that can be quickly adapted to any hardware with audio processing capabilities. Integration of standardized audio objects as well as third-party objects can be easily included and combined with current products. The system 100 provides a simulation environment on a standardized PC architecture, which enables rapid prototyping, providing clues for benchmarking and performance evaluation. Throughout development, the system 100 ensures quality, efficiency, and better time to market.

[0038] The DSP database 102 maintains the latest and most effective signal processing algorithms for easy application across multiple business units. The database 102 catalogs hundreds of audio algorithms from all business units and development groups. The database 102 allows for a wide range of categories of products and settings. The system 100 allows for a plug-and-play type of application, making it easy to drop in, apply and tune algorithms for a wide range of products across multiple industries. The system 100 can be easily adapted on several hardware platforms via a laptop, PC or tablet.

[0039] The system 100 may provide various user interfaces that are standardized for ease of use. The system 100 may allow for comprehensive testing during setup, perform analysis, and provide in-depth documentation during the design process.

[0040] The DSP signal flow designer 104 may allow various audio signaling processes to be selected via a user interface. Basic algorithms may all be included and applied in the flow designer 104, including, for example, many types of filters (infinite impulse response (IIR), finite impulse response (FIR), tone control, equalization (EQ), etc.), mixers, volume, mute, routers, mergers, splitters, convolvers, resampling, fast Fourier transform (FFT). Advanced processing may also be applied, and the advanced processing may include examples such as compressors, limiters, gates, expanders, ACG, speaker protection, thermal protection. User-selectable signal generators, modulators, and synthesizers may also be included. There may also be noise, echo, and feedback controllers as well as signal analyzers, microphones, voice, and communication processing. Reverberation and sound effects may also be applied. Separate sound zones and virtual venues may also be applied.

[0041] The DSP tuning block 106 may allow for customizable tuning of various products and algorithm selections via the flow designer 104. This may be accomplished via screens presented at the human machine interface (HMI) described herein.

[0042] As described above, database 102 may include an extensible audio framework (xAF). Figure 2 An example xAF framework 120 is shown. The framework 120 can be modular, extensible, configurable, and portable to enable existing technology development processes.

[0043] The framework 120 may include a DSP framework that includes basic audio objects such as volume, biquadratic filters, limiters, etc. This framework 120 is portable across processors and platforms including multi-core SoCs. The framework 120 is highly efficient due to the hardware and operating system abstraction layers. The framework 120 supports a virtual amplifier method to simulate an amplifier in real time on a PC. The virtual amplifier may allow virtual studio technology (VST) and may allow an external third-party VST host or an embedded VST host inside the system 100 to enable direct debugging of the VST. The graphical designer within the framework allows flexible audio path definition. The framework 120 may be compatible with other GTTs and AATs and support third-party algorithms. The system 100 may work on a single DSP as well as multiple cores of a system on a chip (SoC). The GTT 105 may allow the creation of new devices and selected cores of the new devices. This is Fig.6I It is shown by way of example.

[0044] Figure 3 An example design flow for the xAF framework 120 is shown. First, a DSP database 102 is generated. As explained, the DSP database 102 is a comprehensive and standardized library of algorithms that are created and centrally stored. Signal flows can be dynamically changed by applying various algorithms, etc. The algorithm library can be read out by the GTT 105 so that a user can create a DSP project in the signal flow designer 104 via a user interface. The DSP tuning block 106 of the GTT 105 can allow customizable tuning of various products and algorithm selections via the flow designer 104.

[0045] The GTT 105 may create a database file to create a virtual amplifier as a plug-in optimized for the PC and compiled with the source code and flashed to the target amplifier 116. The GTT 105 may then read the database file to be configured from the virtual amplifier 114 or the target amplifier 116. The GTT 105 may control the virtual amplifier and / or the target amplifier to simulate the amplifier in real time on the PC.

[0046] Figure 4An example development kit integration of the GTT 105 is shown. The GTT 105 can establish a DSP framework 122. The DSP framework 122 can be part of the CoC SW Reference SDK (RSDK) and is periodically integrated with the reference hardware, the GTT 105, and more importantly, the audio algorithms. The DSP framework 122 contains minimal mandatory objects to establish a basic signal flow for the flow designer 104. The DSP framework 122 can combine and call various technologies such as ISZ, Virtual Venue, Clari-Fi, Audio Leveler, Sound2Target, etc. These technologies can be ported to the DSP framework 122 to ensure smooth integration and high quality. The RSDK ensures high-quality integration, testing and documentation of the entire package. The DSP framework 122 may include a virtual venue.

[0047] Figure 5A and Figure 5B A block diagram of various aspects of a global tuning tool (GTT) 105 is shown. The GTT 105 includes a comprehensive audio and tuning tool suite. Various measurements, tunings, and simulations for audio and acoustic experts are bundled in the GTT 105 to create unique flexibility for customization of simple to complex system designs. The GTT 105 supports true and complete virtual tuning. Tuning efficiency and quality are improved due to easy to use user interface or HMI and data processing. A comprehensive tool can be used for several applications, such as audio and HALOsonic / NVH tuning applications.

[0048] With the growing variety of audio development tools, it can be difficult to achieve a constant overview of existing audio algorithms and find the right solution for each product. Customers may want to find the perfect solution and combination for their products in an efficient and intuitive way. GTT 105 integrates the best tools by bundling knowledge and user experience all in the same place. The framework may include a modulated architecture to cover current and future needs from automotive, premium audio, and consumers for a wide range of audio applications and technologies. GTT 105 can be extended and add new features and create links between various applications.

[0049] Fig. 6A An example audio panel 602 of the GTT 105 is shown. The user interface can be linked to the properties of the processing blocks and support file configuration. The delay of each channel can be adjusted. The overall delay can be dynamically updated and displayed accordingly.

[0050] Figure 6B Another example audio panel 604 of the GTT is shown. The user interface can present key settings for each channel. The properties of each channel can be adjusted, including gain, invert, mute, etc.

[0051] Figure 6CAnother example audio panel 606 of the GTT is shown. The user interface can allow easy monitoring and streaming of data from the amplifier, as well as easy data analysis. The properties of each channel can be easily seen and adjusted, including gain, threshold, hold threshold, add, hold and release time, etc.

[0052] Fig.6D Another example audio panel 608 of the GTT 105 is shown. The user interface may present a combination of native panels and fully custom panels that may be provided via the ISZ input mixer. This mixer may allow the primary and secondary audio sources to be adjusted at the left and right channels, respectively. Presets may be applied to the mixer, and the source for each channel may be selected. Presets may be called up, saved / stored, and deleted.

[0053] Fig. 6E An example design panel 610 of the GTT 105 for the signal flow designer 104 is shown. The signal flow designer 104 enables the creation of simple and complex single flows including various blocks 611. Audio components / blocks 611 from the DSP database 102 can be added to the flow through drag and drop functionality. Blocks 611 can represent audio components such as amplifiers, speakers, filters, audio levelers, band splitters, matrices, etc. The frame can be aesthetically arranged to allow the user to easily see the flow design.

[0054] Although not shown, a similar view of the tuning view may be displayed. The user may switch from the design view to the tuning view. A panel for controlling tuning parameters may be automatically populated based on the adjusted properties. The audio pipeline configuration may also be sent to the amplifier via an extended tuning protocol. A specific object represented by block 611 may be selected by clicking or touching block 611. In response to the selection, a screen related to the selected object may be presented. Figure 6H An example of such a screen is shown in .

[0055] Fig. 6F An example database panel 612 of the system 100 is shown. The DSP database 102 may include various algorithms. Depending on the target device or amplifier, audio processing in the form of algorithms stored in the database 105 may be pre-selected and pre-filtered. Whether such algorithms are automatically applied to the target device may depend on the licensing and availability of the audio object.

[0056] Figure 6G An example properties panel 614 of the system 100 is shown. The properties of each audio object can be adjusted and customized for different use cases of the target device. Figure 6G In this example shown in , the object is configured with 2 channels and 10 elements or a biquadratic filter. Signal audio objects can have different configuration modes, which can also be adjusted in SFD.

[0057] Figure 6H An example native panel 616 for a selected object is shown. In addition to tuning, a panel 611 may be created with extended design functionality. Although not specifically shown, the system 100 may also include probe points anywhere in the audio pipeline. The probe points may allow the processor 110 to analyze processed signals between various audio objects. This may be managed via streaming and monitoring commands, which are part of the xTP tuning protocol.

[0058] Fig.6I An example SoC panel 618 is shown. The GTT 105 may allow for the creation of a new device and selected cores of the new device. The examples shown herein show a basic configuration of a multi-core SoC.

[0059] Figure 6J Shows the method used to create Figure 6J 622. In response to a user selecting "Launch Native Panel," a user may create a custom panel.

[0060] Figure 6K An example native panel 624 is shown that is created in response to the edit panel 622. This example native panel 624 may be programmed based on new UX / UI styles and customer and user requirements, but is native to the GTT 105.

[0061] A panel can be created that is a hybrid of both native and custom panels. The panel can include native features that have been customized as per user / customer requirements.

[0062] It should be noted that FIG. 6A to FIG. 6K is an example user interface, and the system may include various other user interfaces that a user may use to construct audio objects.

[0063] Figure 7 An example transaction process 702 of the GTT 105 is shown. The integrated DSP database 102 allows for easy and secure data handling. The transaction process 702 may begin at block 704, where the processor 110 receives a device selection. The device selection may include selecting a target device to be programmed / simulated. For example, the target device may include an amplifier, a speaker, a microphone, etc. The target device may have a specific application, such as a speaker for home audio, a speaker for car audio, professional audio, as well as a smartphone, a tablet, a personal computer, etc.

[0064] At block 706, the processor 110 may receive a selection of an item. The item may be a selection of programming for a target device.

[0065] At block 708, the processor 110 may receive a selection of a signal flow. This may be established by the flow designer 104 based on various user inputs at the HMI. Additionally, a project may have multiple signal flows.

[0066] At block 710 , the processor 110 may receive tuning data. This may be established as part of the tuning block 106 of the GTT 105 .

[0067] At block 712, the processor 110 may process various measurements and store the measurement data for each tuning. This measurement data may be used by the user to make adjustments to the tuning, the device, the algorithms used, etc. The measurement data may be communicated directly to the target device to enable simple and efficient automation of audio measurement routines of various ranges. The measurement data may be accessed on the same PC or via a network. Connection may be made via, among other things, an Asio or MME sound card.

[0068] At block 714, the processor 110 may store and / or display the post-measurement data as it relates to the device and the algorithms applied. This may include outputting an output signal based on the input signal after a simulation framework and based on the measurement data.

[0069] Figure 8 1 shows an example block diagram of the entire system 100. The system 100 may include at least one business unit 130. Figure 8 In the example shown in FIG. 1 , a first business unit 130a and a second business unit 130b are shown. Each business unit 130 can access and utilize the system 100. One or more of the business units 130 can be associated with a business database 132 that is associated with the business database 132. Figure 1 102. For example, the first business unit 130a may be associated with the first business database 132a, and the second business unit 130b may be associated with the second business database 132b. The business units 130 may provide various DSP algorithms to the system. These databases 102 may be added to the DSP database 102. Additionally or alternatively, third-party products and algorithms may also be provided to the DSP database 102.

[0070] By allowing the business database 132 to upload to the DSP database 102, the DSP database 102 can be continuously updated to include the latest versions of various algorithms. The system 100 including xAF, AAT and GTT can access the DSP database 102 to facilitate building various products using the algorithms and products stored in the database 102.

[0071] In addition to the business unit 130, various third parties 134 can access the DSP database. The third party 134 can receive the algorithm from the DSP database 102 and save the algorithm to its local third party database 136. In some examples, the third party 134 can also upload to the DSP database 102.

[0072] Various business units 130 and third parties 134 can extract, apply and tune various algorithms and products via HMI 122. HMI 122 can provide easy-to-use tools, and system 100 and database 102 can allow for easily configurable and updateable product libraries to be used to build various audio products. HMI 122 can present screens similar to those shown and described herein.

[0073] Prior to using the system 100, the business unit 130 and the third party 134 may be authenticated. Authentication may be granted in response to the authentication of the user. The authentication of the user may depend on the subscription to the system 100. Authentication may depend on the third party contractual relationship or business unit. For example, some third party vendors may have different access levels than other third party vendors.

[0074] Fig. 9 An example configuration of the GTT 105 is shown in which multiple devices are configured simultaneously. All devices can be configured and tuned at once. The first device 124a can be a host unit. The second device 124b can be an amplifier with a SoC. The device 124 can also be an amplifier used in a multiple room configuration in a consumer or professional audio application. The device 124 can also be a table, a phone, a laptop or a PC. The system 110 can tune and calibrate the two devices 124 via the processor 110. The system 100 can handle multiple cores, processors, devices, etc. The processor 110 can simulate various output signals based on the object 611 and the parameters applied to the object. Communication with each device 124 can be achieved through the AmpSrv2 application. Each device 124 can be treated as a new client. The GTT 105 can facilitate the adjustment of tuning and process parameters.

[0075] The AmpSrv2 application allows communication between virtual devices and target devices supported by multiple physical interfaces. Data can be sent and received via a globally standardized and recognized protocol. In one example, the protocol can be xTP (Extended Tuning Protocol). This enables data to be flashed into the device and metadata to be read out from the audio framework. The AmpSrv2 application can support various interfaces such as RS232, MOST, CAN, Ethernet (sockets), Ethernet (UDP messages). The application can display, analyze and record continuous communication with connected devices. Programs and data can be updated. Simulation of the head unit and other vehicle data can include volume, bass, treble, audio attenuator, and vehicle data such as speed, throttle position, rpm, etc. The application can also perform diagnostic functions, including speaker checks, reading error logs, microphone calibration, etc.

[0076] Fig.10 An example flow chart of a process 1000 for a measurement routine is shown. The measurement routine may be about Figure 7 Part of the measurement data acquisition discussed at block 712. As explained, this measurement data can be used by the user to make adjustments to the tuning, the device, the algorithms used, etc. The measurement data can be communicated directly to the target device to enable simple and efficient automation of a wide range of audio measurement routines. The measurement data can be accessed on the same PC or via a network. Inter alia, the connection can be made via an Asio or MME sound card.

[0077] Process 1000 may include a client measurement block 1002 and a tuning block 1004. The client measurement block 1002 may include front-end measurements provided by the client. The tuning block 1004 may include other measurements, such as those from an EQ panel, etc. The client measurement block 1002 and the tuning block 1004 may communicate with each other. The tuning block 1004 may send and receive presentations, tune-outs, etc. Measurement selections, trigger events, measurement configurations, results, etc. may also be transmitted between the client measurement block 1002 and the tuning block 1004.

[0078] The process 1000 may include a middleware interface 1008 configured to communicate with a backend 1010. Measurement results, presets, etc. may be transmitted from the GTT 105 to the backend 1010. The backend 1010 may be a process executed by the processor 110. For example, at block 1020, the available measurement list 1012 and the measurement instance 1014 that may be created by the user may be combined to select a measurement. The measurement interface 1022 may present the measurement results to the user.

[0079] Fig.11 An example measurement panel 1102 is shown. Fig.11The measurement panel 1102 in shows an example panel for car audio measurements with six microphones. By directly controlling the parameters of the audio objects in the pipeline and along the signal flow, measurements can be made automatically.

[0080] Fig.12 An example link panel 1202 is shown. The link panel may allow linking of state variables with an intuitive UX / UI concept.

[0081] Thus, the interoperability of audio functions in complex systems can be facilitated via the above system. This intelligent, seamless and intuitive solution allows the possibility to easily configure the audio algorithm database and the DSP framework, as well as to tune and control the various algorithms. High-quality audio products with the highest degree of flexibility and efficiency on the market can be created via this system. The system allows fast design, rapid prototyping on different hardware, and ensures a fast time to market.

[0082] The system can be tuned for third-party requirements and enables a wide range of business models. HaloSonic allows the integration of sound management, including third-party solutions. This can include exhaust sound generation, exhaust cancellation, active noise and vibration mount algorithms, and general sound tuning tool functionality. NVH and audio processes can work together fluidly to maximize performance in each domain.

[0083] Any hardware anywhere can be quickly adapted and optimized due to hardware and operating system (OS) abstraction layers. The system can run on legacy hardware from head units or amplifiers to powerful processors in smartphones. The tool can run on PCs, smartphones or tablets and can support multi-instances, multi-cores, multi-processors, multi-devices, all running with a single GTT instance.

[0084] All algorithms and objects can use standardized interfaces and are managed through a certification process to ensure consistent quality and interoperability. Third-party algorithms can be easily integrated. The certification process ensures that third-party algorithms meet pre-defined / modified quality standards.

[0085] Complete sound tuning can be performed virtually based on multi-physics simulation, virtual acoustics, auralization, and virtual amplifier solutions. This enables sound tuning to be performed very early in the development cycle, when the physical product and / or amplifier does not yet exist.

[0086] The system enables rapid prototyping through real-time file configuration for processor MIPS and memory. New designs can be tested, demonstrated, and benchmarked very early in the project development phase.

[0087] The computing devices described herein generally include computer-executable instructions, wherein the instructions can be executed by one or more computing or hardware devices (such as those listed above). The computer-executable instructions can be compiled or interpreted from a computer program created using a variety of programming languages ​​and / or technologies, including but not limited to Java, PHP, PHP, and others, alone or in combination. TM , C, C++, Visual Basic, Java Script, Perl, etc. In general, a processor (e.g., a microprocessor) receives instructions, such as from a memory, a computer-readable medium, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. A variety of computer-readable media can be used to store and transmit such instructions and other data.

[0088] Although exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the present invention. Rather, the words used in this specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the present invention. In addition, the features of the various embodiments of implementation may be combined to form other embodiments of the present invention.

Claims

1. An audio processing system, comprising: at least one memory programmed to store a plurality of audio objects and first information corresponding to a plurality of cores associated with a plurality of system-on-chip (SoC) devices; as well as A computing device programmed to: providing, on a display, first information corresponding to a plurality of cores associated with a plurality of SoC devices; providing a plurality of audio objects on a display; receiving a first input indicating a tuning parameter to be applied to a first audio object of the plurality of audio objects; receiving a second input instructing a first selected SoC device to apply the tuning parameters to the first audio object; and The tuning parameters are applied to the first audio object using the first selected SoC device to generate an audio output signal.

2. The audio processing system of claim 1 , wherein the first information corresponding to a plurality of cores associated with a plurality of SoC devices also corresponds to an available core located within the system, the available core being executable to apply the tuning parameters to the first audio object to generate an audio output signal.

3. The audio processing system of claim 1, wherein the at least one memory is further programmed to store second information corresponding to an available core for selection of a plurality of cores associated with the plurality of SoC devices.

4. The audio processing system of claim 1, wherein the computing device is further programmed to provide the plurality of audio objects on the display for user selection to select the first audio object before applying the tuning parameters to the first audio object. 5 . The audio processing system of claim 1 , wherein the first audio object comprises one of an amplifier, a filter, an equalizer, a band splitter, and a matrix mixer.

6. The audio processing system of claim 1, wherein the computing device is further programmed to receive a third input from a user, the third input indicating a second selected core of the plurality of cores corresponding to a second selected SoC device located within the system.

7. The audio processing system of claim 6, wherein the computing device is further programmed to apply the tuning parameters to the first audio object using the second selected SoC device to generate the audio output signal.

8. The audio processing system of claim 7, wherein the first selected SoC device is different from the second selected SoC device.

9. The audio processing system according to claim 1, wherein: The computing device is one of a mobile device, a tablet computer, a personal computer, and a laptop computer.

10. A method for an audio processing system, the method comprising: storing a plurality of audio objects and first information corresponding to a plurality of cores associated with a plurality of system-on-chip (SoC) devices; providing, on a display, first information corresponding to a plurality of cores associated with a plurality of SoC devices; providing a plurality of audio objects on a display; receiving a first input indicating a tuning parameter to be applied to a first audio object of the plurality of audio objects; receiving a second input instructing a first selected SoC device to apply the tuning parameters to the first audio object; and The tuning parameters are applied to the first audio object using the first selected SoC device to generate an audio output signal.

11. The method of claim 10, wherein the first information corresponding to a plurality of cores associated with a plurality of SoC devices further corresponds to available cores located within a system, the available cores executable to apply the tuning parameters to the first audio object to generate an audio output signal. 12 . The method of claim 10 , further comprising storing second information corresponding to a selected available core for a plurality of cores associated with the plurality of SoC devices.

13. The method of claim 10, further comprising providing the plurality of audio objects on the display for user selection to select the first audio object before applying the tuning parameters to the first audio object.

14. The method of claim 10, wherein the first audio object comprises one of an amplifier, a filter, an equalizer, a band splitter, and a matrix mixer.

15. The method of claim 10, further comprising receiving a second input from a user, the second input indicating a second selected core of the plurality of cores corresponding to a second selected SoC device located within the system.

16. The method of claim 15, further comprising applying the tuning parameters to the first audio object using the second selected SoC device to generate the audio output signal.

17. The method of claim 16, wherein the first selected SoC device is different from the second selected SoC device.

18. A computer program product embodied in a non-transitory computer readable medium and executable by a processor to perform an audio processing system, the computer program product comprising instructions for: storing a plurality of audio objects and first information corresponding to a plurality of cores associated with a plurality of system-on-chip (SoC) devices; providing, on a display, first information corresponding to a plurality of cores associated with a plurality of SoC devices; providing a plurality of audio objects on a display; receiving a first input indicating a tuning parameter to be applied to a first audio object of the plurality of audio objects; receiving a second input instructing a first selected SoC device to apply the tuning parameters to the first audio object; and The tuning parameters are applied to the first audio object using the first selected SoC device to generate an audio output signal.

19. The computer program product of claim 18, wherein the first information corresponding to a plurality of cores associated with the SoC device further corresponds to available cores located within the system, the available cores executable to apply the tuning parameters to the first audio object to generate an audio output signal.

20. The computer program product of claim 18, further comprising storing second information corresponding to available cores for selection of a plurality of cores associated with the SoC device.

Images