Writing a modular Audio Post Processing DSP algorithm

By Prashant Jagtap, einfochips

1. Objective

The objective of this paper is to provide a high-level process of designing and implementing an Audio Algorithm, specifically written for Soc’s multi-core, low-power audio processing DSP processors. These algorithms can be optimized for a specific DSP processor and offload its processing on the DSP to lower the power consumption of a SoC.

2. What is DSP offloading?

Nowadays, IC manufacturers are coming up with System on Chips where multiple cores of application processor and DSP processors are integrated into a single chip. A hardware and software architecture are designed/developed in house to exchange the data transfer or software processing between the Application and DSP processor. The processing of any algorithm that is optimized for a specific DSP processor can be transferred to the DSPs present on such SoC’s, this method of transferring the processing of a DSP algorithm from the application processor to DSP processor is called a DSP offloading. As the algorithm is written specifically from a DSP processor, the power consumption is fairly reduced as compared with the application processor. This provides an efficient power management for a SoC when used in any of the consumer and automotive products.

3. What is Audio post processing DSP algorithm?

An Audio algorithm is a piece of software used to enhance the specific frequency elements in an Audio signal. It can also be used to reduce the unwanted noisy data from the Audio signals. Such Audio Post Processing algorithm uses a technique such as filtering, compression, expansion, and equalization to improve the signal quality to the desired level for a better user experience.

4. What is modular DSP algorithm and why do we need it?

An Audio algorithm that is intended to perform only specific processing such as Compression, Limiter, Normalization, Decimation, and Mixer is called a modular DSP algorithm. Such an algorithm takes an input signal and provides output signals by processing audio data for a specific task.

Traditionally, An Audio post-processing algorithm was developed considering a specific DSP architecture. The design of the Audio algorithm was mainly dependent on features required in the algorithm and the performance of an algorithm when ported on specific DSP processors. As mentioned earlier, these DSP algorithms are developed with different features such as Limiter, Dynamic Range compressor, Equalizer, and Automatic Gain control to improve audio signals.

Usually, traditional DSP algorithms are implemented as a single monolithic library exposing the Create(), Init(), process(), destroy(), SetParam(), and GetParam() API’s from the library/algorithm. As these libraries are implemented for a specific DSP processor and all the features are combined in a single monolithic library, such design loses the modularity of the algorithm to be used for different DSP processors available in the market.

Nowadays, due to technological advancement, the frequency of the new SoC hitting the market has increased. Additionally, silicon providers are adding multiple DSP cores in a single chipset. This is helping parallel computation processing of the Audio signal with new hardware architecture.

a. Drawbacks of monolithic library:

1. As all the features are loaded into a single library, effective use of multicore hardware architecture is not achieved to its full extent.
2. Bundling all the features into a single library also adds up additional maintenance and debugging efforts if any issue arises for the DSP library in the production environment.
3. Additionally, if any OEM requires only a few features for its product, such a DSP algorithm library takes the entire software lifecycle time before it gets used in a final product.

Let’s understand this with an example:

Support a DSP module is developed and tested with feature set in the below sequence:

Automatic Gain Control -> Downmixer -> Mutirate processing -> Equilizer -> Compressor -> Limiter.

Now if customer ABC requires only a few features out of the above: DownMixer -> Compressor ->Limiter. As these new feature requirements differ from the one that was implemented and tested earlier, additional efforts are required to redevelop the code for a new requirement and test it again to cater to the customer ABC’s requirement.

5. Key points while writing Audio Algorithm

The problem with the monolithic library can be removed with different implementation ways that can be used while designing the audio algorithm. One of the simplest ways is to implement one feature of an entire library as a single library. This will divide a monolithic library into separate libraries. As the individual feature is divided into a single library below benefits can be achieved:

• Debugging and testing efforts can be minimized.
• Multiple customer requirements can be addressed with minimal engineering efforts.
• Maintenance time will be reduced.

Below are the key points to be considered while developing the DSP modules:

• Design and implement core features as a single library.
• For performance optimization, write separate assembly-level implementations for individual functions in a DSP feature.
• Use software build tools such as CMAKE/SCONS for an efficient build process.
• Prepare a unique API list to be exposed from each DSP module.
• Write a separate test suite for each featured library for testing.
• Generate reference test output for each feature and use it for test verification once the algorithm is ready to test.
• Use scripting language to automate the test process.
• Use different build procedures for the below library configurations.
  • Bit depth: 16, 24, and 32 bits
  • Audio Channel: Mono, stereo, 5.1 and 7.1
  • Sampling frequency: 44.1 KHz, 48 KHz, 96 KHz
  • Computation: Fixed, Float format
• Write a code to measure the memory and performance of a library for a specific DSP processor.
• Always make sure to write code that does not use Global variables. This is useful while creating multiple instances of a library on the same core and avoiding a potentially unknown state of the DSP algorithm at runtime.
• Avoid passing the filter coefficient from the application as much as possible. This will ensure a reduced no. of data bytes transferred to the DSP module while SetParam() and GetParam call.
• Generate the default filter coefficient required for the DSP algorithm once at the time of initialization. At runtime, only take the parameters that are required to regenerate these coefficients. Note. This might affect the performance of the DSP module for a few process frames.

Below is the set of common APIs that can be implemented in the DSP library:

• GetMemoryRequirement ()
• CreateInstance ()
• Initialize ()
• ProcessFrame ()
• SetControlParameters ()
• GetControlParameters ()
• GetDefaultParameters ()
• GenerateDefaultFilterCoeffs ()
• DestroyInstance ()

6. Designing the Framework

By following the key points described in the above section, a modular DSP features library can be implemented, and this can be reused with very minimal effort for different customer requirements.

One of the problems that might occur with this implementation while integrating these DSP modules with the Audio frameworks available in the market such as from Qualcomm, Intel, and AMD chipsets.

To address this problem, an audio framework can be designed in a manner that will serialize the Audio processing Feature. A set of framework APIs can be exposed from the framework library to get an Audio algorithm integrated into the customer’s environment.

Below are the key points while developing the framework:

• It should provide a build time / run time provision to add OR delete a specific DSP module.
• It should provide support to open multiple Audio stream sessions and Control APIs to handle those sessions.
• It should support a unique API interface so that a pluggable DSP module can be designed and interfaced.
• It should be portable to any platform with minimalistic efforts. Note: High-level language such as C. C++ are preferred as compiler support for most of the DSP processors becomes easily available.

7. Summary

In this fast-changing world of the 21st century, the use of Audio Algorithms has increased in multiple verticals such as Medical, Automotive, and Aerospace and their requirements are highly volatile based on the rapid technological changes. To manage such a high volatile requirement, it is always recommended and required to design, and develop reusable DSP-featured libraries/frameworks to reduce the time to market and cater to highly volatile customer demands.

About the Author:

Prashant Jagtap is a Technical Architect at einfochips. He has over 17 years of experience in the development of embedded system applications and verification of safety-critical system software. He possesses strong expertise in C application development and porting of Audio algorithms on Qualcomm snapdragon 835, 845, SM8150, SM8250, SM8450/8550, Intel’s Smart Sound Technology platform (TigerLake, RaptorLake and MeteorLake) and AMD LPAP platforms (Rembrandt, Mendocino). He likes to play cricket and Badminton in his free time.

If you wish to download a copy of this white paper, click here