Audio: MDRC: Restructure Multiband DRC for more effective memory alloc… #9195

ShriramShastry · 2024-06-05T04:29:21Z

This check-in attempts to decrease memory allocation overhead, enhance cache efficiency through data locality, and lessen heap fragmentation. Within the MDRC component, combine memory allocations for the crossover, emphasis, and deemphasis filter coefficients into a single block.

By streamlining memory management, the update lowers the possibility of memory leaks.

lyakh · 2024-06-05T07:14:17Z

src/audio/multiband_drc/multiband_drc.c

+
+ struct sof_eq_iir_biquad *coefficients_block =
+ rzalloc(SOF_MEM_ZONE_RUNTIME, 0, SOF_MEM_CAPS_RAM,
+ total_coefficients_size);


now this seems to be allocated twice: first time inside multiband_drc_init() and a second time here.

Thank you for your feedback regarding the memory allocation within the multiband DRC module

The allocation of memory for coefficients_block in multiband_drc_init_coef() is separate from the allocation of multiband_drc_comp_data in multiband_drc_init(). The latter is the component data for the multiband
DRC module, and it is allocated only once during module initialization.

I 've cross checked again.

The multiband_drc_comp_data allocation is for storing the component's state and is done once upon initialization (multiband_drc_init()).
The coefficients_block allocation is specifically for filter coefficients and occurs later during the module's preparation (multiband_drc_init_coef()).
The allocation for coefficients_block is not done in multiband_drc_init() and hence there is no duplication.
It looks like all allocations and initializations are following the correct sequence and avoiding double allocation for the same data structures. If there are any further concerns or points that require clarification, please let me know.

@ShriramShastry Maybe I didn't explain it well. See line 132 below that you're removing

sof/src/audio/multiband_drc/multiband_drc.c

Line 132 in fec9e99

crossover = config->crossover_coef;

- that's where previously crossover was coming from. Now you added an allocation for it. But I don't see where you removed that original data block? So the original array seems to still be there and you add a new one.

Thanks ! I'II make the adjustments.

Done ! Please have a look.

cujomalainey · 2024-06-05T17:07:33Z

src/audio/multiband_drc/multiband_drc.c

+ * deemphasis is situated after the emphasis coefficients.
+ * This ensures all filter coefficients are stored contiguously.
+ */
+ crossover = coefficients_block;


I would prefer a modification to the datatypes rather than just packing them into a single buffer and crossing fingers no one screws up the math in the future

Thank you for the review and comments. The changes to the allocation and pointer setup are intended to enhance memory efficiency and cache performance for the MDRC component.

Here’s a summary of the changes and the rationale behind them:

Memory Allocation Consolidation: By allocating a single block of memory for crossover, emphasis, and deemphasis filter coefficients, we avoid separate heap allocations which can incur additional overhead and fragmentation.

size_t total_coefficients_size = sizeof(struct sof_eq_iir_biquad) * num_bands * nch * 3; struct sof_eq_iir_biquad *coefficients_block = rzalloc(SOF_MEM_ZONE_RUNTIME, 0, SOF_MEM_CAPS_RAM, total_coefficients_size); if (!coefficients_block) { comp_err(dev, "multiband_drc_init_coef(), failed to allocate memory for coefficients"); return -ENOMEM; }

Pointer Assignment: After the allocation, pointers for crossover, emphasis, and deemphasis filters are pointed to the appropriate locations within the single allocated block.

crossover = coefficients_block; emphasis = coefficients_block + num_bands * nch; deemphasis = emphasis + num_bands * nch;

This design assures that the data used concurrently during processing is also kept in memory, which will assist with cache usage when processing audio data.

Error Handling: A clear error handling path (goto err;) ensures that the allocated memory block is freed in the event of an error occurring after the allocation, preventing memory leaks.

if (ret < 0) { comp_err(dev, "multiband_drc_init_coef(), could not assign coeffs to ch %d", ch); rfree(coefficients_block); goto err; }

The check-in ensure both accuracy and safety, the pointer arithmetic is based on the size, count, and channel configurations of the coefficients.

I understand the motivation, but the code you have written here (by nature) is much more fragile than if you simply made a toplevel struct which contained everything and just allocated that directly.

Pointer math is hard enough to debug, pointer math on an embedded device is much worse. Lets not add any more than we absolutely should.

Given that I'm organizing coefficients in contiguous memory, should multiband_drc_init_coef() be designed to handle separate coefficients instantiation for each channel and band?

If our architecture allows for different filters per channel/band, this could mean dynamically revising the processing loop in multiband_drc_init_coef() to fetch and apply the correct filter coefficients for each specific band.

Could you shed some light on whether unique filters per channel/band are an aspect of our system's design? If so, are there any particular considerations or adjustments to the coefficient fetch and allocation logic within multiband_drc_init_coef() that I should be aware of to implement this correctly?

/** *static int multiband_drc_init_coef(struct processing_module *mod, int16_t nch, uint32_t rate) *{ * struct comp_dev *dev = mod->dev; * struct multiband_drc_comp_data *cd = module_get_private_data(mod); * struct sof_eq_iir_biquad *crossover; * struct sof_eq_iir_biquad *emphasis; * struct sof_eq_iir_biquad *deemphasis; * struct sof_multiband_drc_config *config = cd->config; * struct multiband_drc_state *state = &cd->state; * uint32_t sample_bytes = get_sample_bytes(cd->source_format); * int i, ch, ret, num_bands; * * if (!config) { * comp_err(dev, "multiband_drc_init_coef(), no config is set"); * return -EINVAL; * } * * num_bands = config->num_bands; * * // Sanity checks * if (nch > PLATFORM_MAX_CHANNELS) { * comp_err(dev, * "multiband_drc_init_coef(), invalid channels count(%i)", nch); * return -EINVAL; * } * if (config->num_bands > SOF_MULTIBAND_DRC_MAX_BANDS) { * comp_err(dev, "multiband_drc_init_coef(), invalid bands count(%i)", * config->num_bands); * return -EINVAL; * } * * comp_info(dev, "multiband_drc_init_coef(), initializing %i-way crossover", * config->num_bands); * * // Crossover: collect the coef array and assign it to every channel * crossover = config->crossover_coef; * for (ch = 0; ch < nch; ch++) { * ret = crossover_init_coef_ch(crossover, &state->crossover[ch], * config->num_bands); * // Free all previously allocated blocks in case of an error * if (ret < 0) { * comp_err(dev, * "multiband_drc_init_coef(), could not assign coeffs to ch %d", ch); * goto err; * } * } * * comp_info(dev, "multiband_drc_init_coef(), initializing emphasis_eq"); * * // Emphasis: collect the coef array and assign it to every channel * emphasis = config->emp_coef; * for (ch = 0; ch < nch; ch++) { * ret = multiband_drc_eq_init_coef_ch(emphasis, &state->emphasis[ch]); * // Free all previously allocated blocks in case of an error * if (ret < 0) { * comp_err(dev, "multiband_drc_init_coef(), could not assign coeffs to ch %d", * ch); * goto err; * } * } * * comp_info(dev, "multiband_drc_init_coef(), initializing deemphasis_eq"); * * // Deemphasis: collect the coef array and assign it to every channel * deemphasis = config->deemp_coef; * for (ch = 0; ch < nch; ch++) { * ret = multiband_drc_eq_init_coef_ch(deemphasis, &state->deemphasis[ch]); * // Free all previously allocated blocks in case of an error * if (ret < 0) { * comp_err(dev, "multiband_drc_init_coef(), could not assign coeffs to ch %d", * ch); * goto err; * } * } * * // Allocate all DRC pre-delay buffers and set delay time with band number * for (i = 0; i < num_bands; i++) { * comp_info(dev, "multiband_drc_init_coef(), initializing drc band %d", i); * * ret = drc_init_pre_delay_buffers(&state->drc[i], (size_t)sample_bytes, (int)nch); * if (ret < 0) { * comp_err(dev, * "multiband_drc_init_coef(), could not init pre delay buffers"); * goto err; * } * * ret = drc_set_pre_delay_time(&state->drc[i], * cd->config->drc_coef[i].pre_delay_time, rate); * if (ret < 0) { * comp_err(dev, "multiband_drc_init_coef(), could not set pre delay time"); * goto err; * } * } * * return 0; * *err: * multiband_drc_reset_state(state); * return ret; *} */ static int multiband_drc_setup(struct processing_module *mod, int16_t channels, uint32_t rate) { struct multiband_drc_comp_data *cd = module_get_private_data(mod); int ret; /* Reset any previous state */ multiband_drc_reset_state(&cd->state); /* Setup Crossover, Emphasis EQ, Deemphasis EQ, and DRC */ ret = multiband_drc_init_coef(mod, channels, rate); }

Currently, the coefficients for each of the emphasis/de-emphasis filters and crossovers per channel are initialised, but it appears that the multiband DRC assumes a configured number of filters applied uniformly across channels; however, if individual adjustments/adapt to filters per channel/band are required, the code should fetch and set up the coefficients accordingly within the multiband_drc_setup and related functions.

Your expertise in this area will help to clarify the best course of action and ensure that our implementation remains efficient and in line with our system's architectural goals.

ShriramShastry

Please let me know if you have any specific concerns or suggestions for further improvements. Your feedback is extremely helpful, and I am willing to make any necessary changes to this patch..

Thank you for review.

ShriramShastry · 2024-06-06T04:38:15Z

src/audio/multiband_drc/multiband_drc.c

+ * deemphasis is situated after the emphasis coefficients.
+ * This ensures all filter coefficients are stored contiguously.
+ */
+ crossover = coefficients_block;


Thank you for the review and comments. The changes to the allocation and pointer setup are intended to enhance memory efficiency and cache performance for the MDRC component.

Here’s a summary of the changes and the rationale behind them:

Memory Allocation Consolidation: By allocating a single block of memory for crossover, emphasis, and deemphasis filter coefficients, we avoid separate heap allocations which can incur additional overhead and fragmentation.

size_t total_coefficients_size = sizeof(struct sof_eq_iir_biquad) * num_bands * nch * 3; struct sof_eq_iir_biquad *coefficients_block = rzalloc(SOF_MEM_ZONE_RUNTIME, 0, SOF_MEM_CAPS_RAM, total_coefficients_size); if (!coefficients_block) { comp_err(dev, "multiband_drc_init_coef(), failed to allocate memory for coefficients"); return -ENOMEM; }

Pointer Assignment: After the allocation, pointers for crossover, emphasis, and deemphasis filters are pointed to the appropriate locations within the single allocated block.

crossover = coefficients_block; emphasis = coefficients_block + num_bands * nch; deemphasis = emphasis + num_bands * nch;

This design assures that the data used concurrently during processing is also kept in memory, which will assist with cache usage when processing audio data.

Error Handling: A clear error handling path (goto err;) ensures that the allocated memory block is freed in the event of an error occurring after the allocation, preventing memory leaks.

if (ret < 0) { comp_err(dev, "multiband_drc_init_coef(), could not assign coeffs to ch %d", ch); rfree(coefficients_block); goto err; }

The check-in ensure both accuracy and safety, the pointer arithmetic is based on the size, count, and channel configurations of the coefficients.

ShriramShastry

Thanks for reviewing the code, I 'm in need of your/Google guidance on Coefficient allocation logic for Channel/Band-Specific Filters in multiband_drc_init_coef().

Because the task requires us to properly allocate and assign emphasis/de-emphasis filter coefficients within a shared memory block.

However, I need to know if our architecture requires these filters to be unique per channel/band, which will affect our allocation strategy and coefficient fetch logic.

ShriramShastry · 2024-06-08T16:59:32Z

src/audio/multiband_drc/multiband_drc.c

+ * deemphasis is situated after the emphasis coefficients.
+ * This ensures all filter coefficients are stored contiguously.
+ */
+ crossover = coefficients_block;


Given that I'm organizing coefficients in contiguous memory, should multiband_drc_init_coef() be designed to handle separate coefficients instantiation for each channel and band?

If our architecture allows for different filters per channel/band, this could mean dynamically revising the processing loop in multiband_drc_init_coef() to fetch and apply the correct filter coefficients for each specific band.

Could you shed some light on whether unique filters per channel/band are an aspect of our system's design? If so, are there any particular considerations or adjustments to the coefficient fetch and allocation logic within multiband_drc_init_coef() that I should be aware of to implement this correctly?

/** *static int multiband_drc_init_coef(struct processing_module *mod, int16_t nch, uint32_t rate) *{ * struct comp_dev *dev = mod->dev; * struct multiband_drc_comp_data *cd = module_get_private_data(mod); * struct sof_eq_iir_biquad *crossover; * struct sof_eq_iir_biquad *emphasis; * struct sof_eq_iir_biquad *deemphasis; * struct sof_multiband_drc_config *config = cd->config; * struct multiband_drc_state *state = &cd->state; * uint32_t sample_bytes = get_sample_bytes(cd->source_format); * int i, ch, ret, num_bands; * * if (!config) { * comp_err(dev, "multiband_drc_init_coef(), no config is set"); * return -EINVAL; * } * * num_bands = config->num_bands; * * // Sanity checks * if (nch > PLATFORM_MAX_CHANNELS) { * comp_err(dev, * "multiband_drc_init_coef(), invalid channels count(%i)", nch); * return -EINVAL; * } * if (config->num_bands > SOF_MULTIBAND_DRC_MAX_BANDS) { * comp_err(dev, "multiband_drc_init_coef(), invalid bands count(%i)", * config->num_bands); * return -EINVAL; * } * * comp_info(dev, "multiband_drc_init_coef(), initializing %i-way crossover", * config->num_bands); * * // Crossover: collect the coef array and assign it to every channel * crossover = config->crossover_coef; * for (ch = 0; ch < nch; ch++) { * ret = crossover_init_coef_ch(crossover, &state->crossover[ch], * config->num_bands); * // Free all previously allocated blocks in case of an error * if (ret < 0) { * comp_err(dev, * "multiband_drc_init_coef(), could not assign coeffs to ch %d", ch); * goto err; * } * } * * comp_info(dev, "multiband_drc_init_coef(), initializing emphasis_eq"); * * // Emphasis: collect the coef array and assign it to every channel * emphasis = config->emp_coef; * for (ch = 0; ch < nch; ch++) { * ret = multiband_drc_eq_init_coef_ch(emphasis, &state->emphasis[ch]); * // Free all previously allocated blocks in case of an error * if (ret < 0) { * comp_err(dev, "multiband_drc_init_coef(), could not assign coeffs to ch %d", * ch); * goto err; * } * } * * comp_info(dev, "multiband_drc_init_coef(), initializing deemphasis_eq"); * * // Deemphasis: collect the coef array and assign it to every channel * deemphasis = config->deemp_coef; * for (ch = 0; ch < nch; ch++) { * ret = multiband_drc_eq_init_coef_ch(deemphasis, &state->deemphasis[ch]); * // Free all previously allocated blocks in case of an error * if (ret < 0) { * comp_err(dev, "multiband_drc_init_coef(), could not assign coeffs to ch %d", * ch); * goto err; * } * } * * // Allocate all DRC pre-delay buffers and set delay time with band number * for (i = 0; i < num_bands; i++) { * comp_info(dev, "multiband_drc_init_coef(), initializing drc band %d", i); * * ret = drc_init_pre_delay_buffers(&state->drc[i], (size_t)sample_bytes, (int)nch); * if (ret < 0) { * comp_err(dev, * "multiband_drc_init_coef(), could not init pre delay buffers"); * goto err; * } * * ret = drc_set_pre_delay_time(&state->drc[i], * cd->config->drc_coef[i].pre_delay_time, rate); * if (ret < 0) { * comp_err(dev, "multiband_drc_init_coef(), could not set pre delay time"); * goto err; * } * } * * return 0; * *err: * multiband_drc_reset_state(state); * return ret; *} */ static int multiband_drc_setup(struct processing_module *mod, int16_t channels, uint32_t rate) { struct multiband_drc_comp_data *cd = module_get_private_data(mod); int ret; /* Reset any previous state */ multiband_drc_reset_state(&cd->state); /* Setup Crossover, Emphasis EQ, Deemphasis EQ, and DRC */ ret = multiband_drc_init_coef(mod, channels, rate); }

Currently, the coefficients for each of the emphasis/de-emphasis filters and crossovers per channel are initialised, but it appears that the multiband DRC assumes a configured number of filters applied uniformly across channels; however, if individual adjustments/adapt to filters per channel/band are required, the code should fetch and set up the coefficients accordingly within the multiband_drc_setup and related functions.

Your expertise in this area will help to clarify the best course of action and ensure that our implementation remains efficient and in line with our system's architectural goals.

cujomalainey · 2024-06-10T17:09:30Z

src/audio/multiband_drc/multiband_drc.c

 struct sof_multiband_drc_config *config = cd->config;
 struct multiband_drc_state *state = &cd->state;
 uint32_t sample_bytes = get_sample_bytes(cd->source_format);
 int i, ch, ret, num_bands;
+ bool alloc_success = false;


you don't need this, you can just check if coefficients_block == NULL in the error path.

cujomalainey · 2024-06-10T17:15:00Z

src/audio/multiband_drc/multiband_drc.h

+ struct sof_eq_iir_biquad crossover[SOF_MULTIBAND_DRC_MAX_BANDS * PLATFORM_MAX_CHANNELS];
+ struct sof_eq_iir_biquad emphasis[SOF_MULTIBAND_DRC_MAX_BANDS * PLATFORM_MAX_CHANNELS];
+ struct sof_eq_iir_biquad deemphasis[SOF_MULTIBAND_DRC_MAX_BANDS * PLATFORM_MAX_CHANNELS];
+} __packed;


Won't packing cause a lot of slow reads/writes because things might not be aligned?

While check-in I was getting the error if I do __attribute__((packed)); instead of "} __packed; so I drop the attribute.

"

No codespell typos will be found - file '/usr/share/codespell/dictionary.txt': No such file or directory WARNING: Prefer __packed over __attribute__((packed)) #10: FILE: src/audio/multiband_drc/multiband_drc.h:28: +} __attribute__((packed)); total: 0 errors, 1 warnings, 8 lines checked

Understood. We're using __packed to save memory, but could you confirm if the potential misalignment outweighs the memory gain in our context? And whether our target platform can handle unaligned accesses efficiently.

@ShriramShastry we mainly using packing for any data shared with host, but in this case isn't this data provate to FW only ? If so, we can drop the packed and allow compiler to best organise the data.

@ShriramShastry please read this

The odds here are you saving at most 10s of bytes and paying back way worse in code size and access times

agree, packed isn't needed. It should only be used where data format is important and must be preserved, e.g. when sending data over networks, or between the host and the DSP

Done, removed packed

cujomalainey · 2024-06-10T17:15:59Z

src/audio/multiband_drc/multiband_drc.c

+ struct multiband_drc_comp_data *cd = rzalloc(SOF_MEM_ZONE_RUNTIME, 0,
+ SOF_MEM_CAPS_RAM, sizeof(*cd));
+ if (!cd) {
+ comp_err(dev, "multiband_drc_init(), allocation for multiband_drc_comp_data failed");


Could you please clarify if the removal of the NULL check after rzalloc is due to guaranteed error handling within the allocator, or are we following a specific coding standard that omits such checks?

the change is unneeded (i.e. the trace), the check is still very much needed

cujomalainey · 2024-06-10T17:17:01Z

src/audio/multiband_drc/multiband_drc.c

+
+ /* Allocation for coefficients_block */
+ if (!cd->coefficients_block) {
+ cd->coefficients_block = rballoc(0, SOF_MEM_CAPS_RAM,


just allocate this upfront directly into cd so you don't have to constantly check this.

Could you provide more detail on how to allocate coefficients_block directly with cd upfront, given that we typically need to check and allocate each separately in standard C?

Just do it at the module creation step so you don't have to check if the memory exists when you are parsing params

ShriramShastry

The allocation of coefficients_block is currently conditional on whether it is NULL. Would you prefer that this allocation be performed unconditionally at the time of cd allocation, ensuring that coefficients_block is never NULL and eliminating all subsequent NULL checks on it?

lgirdwood · 2024-06-12T14:47:21Z

The allocation of coefficients_block is currently conditional on whether it is NULL. Would you prefer that this allocation be performed unconditionally at the time of cd allocation, ensuring that coefficients_block is never NULL and eliminating all subsequent NULL checks on it?

I would allocate it when needed if it relies on IPC configuration data for allocation size, if its always constant size you could allocate per instance when pipeline is created.

cujomalainey · 2024-06-13T02:42:38Z

The allocation of coefficients_block is currently conditional on whether it is NULL. Would you prefer that this allocation be performed unconditionally at the time of cd allocation, ensuring that coefficients_block is never NULL and eliminating all subsequent NULL checks on it?

I would allocate it when needed if it relies on IPC configuration data for allocation size, if its always constant size you could allocate per instance when pipeline is created.

+1, I think the only thing that would possibly vary is the crossover bands and that is fairly small

cujomalainey · 2024-06-17T19:43:15Z

src/audio/multiband_drc/multiband_drc.c

+ struct multiband_drc_comp_data *cd = rzalloc(SOF_MEM_ZONE_RUNTIME, 0,
+ SOF_MEM_CAPS_RAM, sizeof(*cd));
+ if (!cd) {
+ comp_err(dev, "multiband_drc_init(), allocation for multiband_drc_comp_data failed");


the change is unneeded (i.e. the trace), the check is still very much needed

cujomalainey · 2024-06-17T19:53:07Z

src/audio/multiband_drc/multiband_drc.h

+ struct sof_eq_iir_biquad crossover[SOF_MULTIBAND_DRC_MAX_BANDS * PLATFORM_MAX_CHANNELS];
+ struct sof_eq_iir_biquad emphasis[SOF_MULTIBAND_DRC_MAX_BANDS * PLATFORM_MAX_CHANNELS];
+ struct sof_eq_iir_biquad deemphasis[SOF_MULTIBAND_DRC_MAX_BANDS * PLATFORM_MAX_CHANNELS];
+};


the more I read this code the more I think this change is incorrect. Look at the struct directly below. This is a copy of that struct which is already directly embedded in the component data. How does this benefit anything when the data was already allocated in place in a single block?

Thanks ! Please take a look at the latest changes. The patch saves 54 MCPS in TGL i.e. from 188 to 134

singalsu · 2024-06-18T09:06:48Z

This PR version has an issue with TGL HiFi3 build. If I set with topology sof-hda-benchmark-drc_multiband32.tplg the control amixer cset name='Analog Playback MULTIBAND_DRC enable' on the playback becomes silent. Sound can be heard with setting amixer cset name='Analog Playback MULTIBAND_DRC enable' off. The current DRC versin does not follow the switch control in runtime, the control needs to be applied when streaming is stopped (or stop the stream to get impact of previously applied control).

I have no idea if MTL HiFi4 has the issue, I don't have a suitable device to check own FW builds.

cujomalainey · 2024-06-18T18:02:11Z

This PR version has an issue with TGL HiFi3 build. If I set with topology sof-hda-benchmark-drc_multiband32.tplg the control amixer cset name='Analog Playback MULTIBAND_DRC enable' on the playback becomes silent. Sound can be heard with setting amixer cset name='Analog Playback MULTIBAND_DRC enable' off. The current DRC versin does not follow the switch control in runtime, the control needs to be applied when streaming is stopped (or stop the stream to get impact of previously applied control).

I have no idea if MTL HiFi4 has the issue, I don't have a suitable device to check own FW builds.

@singalsu no that is by design for our code that the on/off switch is applied while the stream is open.

lyakh · 2024-06-25T06:21:44Z

src/audio/multiband_drc/multiband_drc.c

- int i, ch, ret, num_bands;
+ struct sof_eq_iir_biquad *crossover, *emphasis, *deemphasis;
+ int i, ch, ret;
+ int num_bands = config ? config->num_bands : 0;


no need to check for config twice. The original code, checking config != NULL in line 137 below and then assigning num_bands unconditionally was fine. This change isn't an improvement IMHO.

lyakh · 2024-06-25T06:56:14Z

src/audio/multiband_drc/multiband_drc.h

@@ -21,6 +21,7 @@
 /**
 * Stores the state of the sub-components in Multiband DRC
 */
+


avoid drive-by changes

lyakh · 2024-06-25T06:57:44Z

src/audio/multiband_drc/multiband_drc.h

+ * phase. This allows efficient access to filter parameters required for audio
+ * processing across all channels and bands.
+ */
+ struct multiband_drc_coefficients *coefficients_block; /**< Filter coefficients */


this adds a member of a structure called coefficients_block and I don't see it being used anywhere. And this is a 1-commit PR. This doesn't seem right.

lyakh · 2024-06-25T06:59:24Z

src/audio/multiband_drc/multiband_drc.c

@@ -28,6 +28,7 @@
 #include <sof/ut.h>
 #include <user/eq.h>
 #include <user/trace.h>
+#include <stdbool.h>


I don't see this commit adding any uses of this header, or was it missing before?
To the commit text: sorry, I don't see in the code what is described in the commit text

it was a previous version, this needs to be removed

Remove redundant struct multiband_drc_coefficients and simplify memory management by handling memory allocation directly. 1. Removed `struct multiband_drc_coefficients` from multiband_drc.h and multiband_drc.c. 2. Updated `multiband_drc_init` function to eliminate the allocation of the obsolete `coefficients_block`. 3. Adjusted `multiband_drc_free` to no longer check and free the now-nonexistent `coefficients_block`. 4. Directly handled memory allocation and initialization of crossover, emphasis, and de-emphasis coefficients in `multiband_drc_init_coef`. 5. Simplified overall memory management, removing unnecessary layers of indirection. This change reduces memory allocation overhead, improves data locality to enhance cache efficiency, and mitigates heap fragmentation. The refactoring of memory management adds robustness to the component by reducing the chances of memory leaks and simplifying the initialization and cleanup process. By streamlining memory management, the update lowers the possibility of memory leaks. Ensured thorough testing to verify no functionality is broken or new issues introduced. Signed-off-by: Shriram Shastry <[email protected]>

ShriramShastry force-pushed the improve_multiband_drc_memory_optimization branch 2 times, most recently from d6d6854 to 012e192 Compare June 5, 2024 04:33

ShriramShastry requested review from lyakh, lgirdwood and singalsu June 5, 2024 05:02

ShriramShastry force-pushed the improve_multiband_drc_memory_optimization branch 2 times, most recently from a8a3a75 to aee6da8 Compare June 5, 2024 05:44

lyakh requested changes Jun 5, 2024

View reviewed changes

ShriramShastry marked this pull request as ready for review June 5, 2024 14:18

ShriramShastry requested a review from a team as a code owner June 5, 2024 14:18

cujomalainey requested changes Jun 5, 2024

View reviewed changes

ShriramShastry commented Jun 6, 2024

View reviewed changes

ShriramShastry requested review from cujomalainey and lyakh June 6, 2024 05:20

ShriramShastry commented Jun 8, 2024

View reviewed changes

ShriramShastry force-pushed the improve_multiband_drc_memory_optimization branch 2 times, most recently from 3b6a9cd to b5919ce Compare June 10, 2024 12:36

cujomalainey requested changes Jun 10, 2024

View reviewed changes

ShriramShastry force-pushed the improve_multiband_drc_memory_optimization branch from b5919ce to c86a1f7 Compare June 11, 2024 08:14

ShriramShastry commented Jun 11, 2024

View reviewed changes

ShriramShastry requested a review from cujomalainey June 11, 2024 08:45

ShriramShastry force-pushed the improve_multiband_drc_memory_optimization branch from c86a1f7 to f770cd2 Compare June 14, 2024 06:33

cujomalainey requested a review from johnylin76 June 17, 2024 19:44

cujomalainey requested changes Jun 17, 2024

View reviewed changes

ShriramShastry force-pushed the improve_multiband_drc_memory_optimization branch from f770cd2 to 9ce82c1 Compare June 24, 2024 13:08

ShriramShastry requested a review from cujomalainey June 24, 2024 13:12

lyakh requested changes Jun 25, 2024

View reviewed changes

ShriramShastry force-pushed the improve_multiband_drc_memory_optimization branch from 9ce82c1 to 65260b2 Compare June 27, 2024 08:18

Audio: MDRC: Restructure Multiband DRC for more effective memory alloc… #9195

Are you sure you want to change the base?

Audio: MDRC: Restructure Multiband DRC for more effective memory alloc… #9195

Conversation

ShriramShastry commented Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

ShriramShastry Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShriramShastry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShriramShastry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShriramShastry Jun 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShriramShastry left a comment

Choose a reason for hiding this comment

lgirdwood commented Jun 12, 2024

cujomalainey commented Jun 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShriramShastry Jun 24, 2024 • edited Loading

Choose a reason for hiding this comment

singalsu commented Jun 18, 2024 • edited Loading

cujomalainey commented Jun 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ShriramShastry commented Jun 5, 2024 •

edited

Loading

ShriramShastry Jun 5, 2024 •

edited

Loading

ShriramShastry Jun 11, 2024 •

edited

Loading

ShriramShastry Jun 24, 2024 •

edited

Loading

singalsu commented Jun 18, 2024 •

edited

Loading