Audio: aec: optimize acoustic echo cancellation processing #8877

ShriramShastry · 2024-02-21T16:45:36Z

This check-in introduces performance optimization modifications to the audio Echo Cancellation (AEC) implementation. The enhancements primarily focus on refining loop structures and memory copy operations to ensure more efficient use of cycles.

lyakh

looks wrong to me

lyakh · 2024-02-22T07:27:47Z

src/audio/google/google_rtc_audio_processing.c

+	float **ref_ptr = cd->aec_reference_buffer_ptrs;
+
+	while (ref != ref_end)
+		*ref_ptr++ = convert_int16_to_float(ref++);


this looks very different from what it was, and it looks wrong to me. convert_int16_to_float() is now called for a pointer, and the LHS *ref_ptr = ... now does a pointer assignment.

Yes, that was a good catch.
The LHS code snippet calls convert_int16_to_float(ref[channel]) for each channel and stores the result in cd->aec_reference_buffer_ptrs[channel][i]. This suggests that convert_int16_to_float() is a function that accepts an int16_t and returns a float value.

In the RHS code snippet,convert_int16_to_float(ref++)is called in a loop, with the result assigned to *ref_ptr++. This implies that convert_int16_to_float() is a function that accepts a pointer to int16_t and returns a pointer to float. This is a considerable deviation from the LHS code snippet and may cause problems if convert_int16_to_float() is not intended to handle pointers.

Furthermore, in the RHS code snippet, *ref_ptr++ = convert_int16_to_float(ref++); does a pointer assignment, which implies it changes the position of ref_ptr rather than the value it points to. This could be troublesome if ref_ptr is meant to point to a specific memory address.

I'II fix it.
Thank you.

lgirdwood

@singalsu @cujomalainey pls review.

lgirdwood · 2024-02-23T09:50:54Z

src/audio/google/google_rtc_audio_processing.c

 	 */
+	// Optimization:Reduce cycle waste by streamlining the inner loop,
+	// converting from array indexing to pointer arithmetic,
+	// and putting data copy verification outside the loop.


lgirdwood · 2024-02-23T09:54:35Z

src/audio/google/google_rtc_audio_processing.c

+	while (ref != ref_end) {
+		if (ref && (void *)ref >= (void *)ref_buf_start &&
+		    (void *)ref < (void *)ref_buf_end) {
+			*ref_buf++ = *ref++;
+		} else {
+			// ref does not point to valid int16_t data
+			return -2;
 		}


Wont it be better to work out start and end for both buffers and then memcpy ? This should also have a comment on what we are doing. i.e. why we copy from A to B.

Hope memcpy_s is ok

Yeah, it should be - I think @singalsu and @andrula-song have used it elsewhere in modules and IIUC it can take advantage of HiFi memcpy for better MCPS.

lgirdwood · 2024-02-23T09:56:01Z

src/audio/google/google_rtc_audio_processing_mock.c

 						 int16_t *const dest)
 {
+	if (!state || !src || !dest || !state->aec_reference)
+		return -1; // Return an error code if any of the pointers are null


Lets have proper errno codes for all negative error numbers. Most of these are passed up the stack and could result in confusion if we are passing wrong codes.

Sure, I will include the proper error code.

Done - please have a look

Here and some lines below still -1 in use. @thesofproject/google 's comments would be useful for error codes from mockup. If the real library uses similar, returning them would be better if the error code macros are possible to share in this public open-source version.

The internal library does not have error code. 0 means success any negative value mean error.

lyakh · 2024-02-26T07:06:31Z

src/audio/google/google_rtc_audio_processing.c

+	const int16_t *ref_end = ref + cd->num_frames * cd->num_aec_reference_channels;
+
+	if ((void *)ref_end >= (void *)ref_buf_end)
+		ref_end = (void *)ref_buf_start;


ref_buf_end? Also, please don't type-cast to non-const types const pointers. I'd do

if ((const int8_t *)ref_end > ref_buf_end) ref_end = (const int16_t *)ref_buf_end;

lyakh · 2024-02-26T07:07:21Z

src/audio/google/google_rtc_audio_processing.c

+		for (s_chan = 0; s_chan < cd->num_aec_reference_channels; ++s_chan) {
+		/*  Check that ref is within the valid range of the ref_buf buffer */
+			if (ref && (void *)ref >= (void *)ref_buf_start &&
+			    (void *)ref < (void *)ref_buf_end)


no need to check ref for NULL at all. You anyway check, that it's in a range

lyakh · 2024-02-26T07:14:10Z

src/audio/google/google_rtc_audio_processing.c

+	int16_t *ref_buf = cd->aec_reference_buffer;
+
+	/*  Check that ref is within the valid range of the ref_buf buffer */
+	if (ref && (void *)ref >= (void *)ref_buf_start && (void *)ref < (void *)ref_buf_end) {


ditto, and please use proper types for comparison type-casts

lyakh · 2024-02-26T07:15:05Z

src/audio/google/google_rtc_audio_processing.c

+
+		if (memcpy_s(ref_buf, num_bytes, ref, num_bytes) != 0) {
+			/*  Handle error */
+			return -2;


what is a -2?

lyakh · 2024-02-26T07:15:57Z

src/audio/google/google_rtc_audio_processing.c

+	const int16_t *src_end = src + cd->num_frames * cd->config.output_fmt.channels_count;
+
+	if ((void *)src_end >= (void *)src_buf_end)
+		src_end = (void *)src_buf_start;


types and end

lyakh · 2024-02-26T07:16:31Z

src/audio/google/google_rtc_audio_processing.c

+	while (src != src_end) {
+		/* Check if src has exceeded the buffer end */
+		if ((void *)src >= (void *)src_buf_end)
+			src = (void *)src_buf_start;


please, fix types everywhere

lyakh · 2024-02-26T07:17:03Z

src/audio/google/google_rtc_audio_processing.c

+	int16_t *dst_end = dst + cd->num_frames * cd->config.output_fmt.channels_count;
+
+	if ((void *)dst_end >= (void *)dst_buf_end)
+		dst_end = (void *)dst_buf_start;


lyakh · 2024-02-26T07:19:06Z

src/audio/google/google_rtc_audio_processing.c

-						   cd->process_buffer_ptrs[channel][i]);
+	float **proc_ptr = cd->process_buffer_ptrs;
+
+	while (dst != dst_end && *proc_ptr)


for loops would fit better here since you need to step your pointers

ShriramShastry

Thanks for reviewing the code,; I have made the changes based on the review comments.

lgirdwood · 2024-02-26T16:41:21Z

@thesofproject/google pls review. Thanks !

singalsu · 2024-02-26T17:12:33Z

src/audio/google/google_rtc_audio_processing_mock.c

 						 int16_t *const dest)
 {
+	if (!state || !src || !dest || !state->aec_reference)
+		return -1; // Return an error code if any of the pointers are null


Here and some lines below still -1 in use. @thesofproject/google 's comments would be useful for error codes from mockup. If the real library uses similar, returning them would be better if the error code macros are possible to share in this public open-source version.

singalsu · 2024-02-26T17:16:46Z

src/audio/google/google_rtc_audio_processing.c

+#define ERR_INVALID_REF -1
+#define ERR_MEMCPY_FAIL -2
+#define ERR_INVALID_SRC -3
+#define ERR_INVALID_DST -4


We use typically -EINVAL or -ENOMEM depending on the case and text description of issue, so not sure if this detail level is needed. They might also cause confusion with errno.h values 1- 4 when reported back.

@ShriramShastry NAK, this file as well as most of the SOF use POSIX error codes, please don't invent any new ones and mix them with existing ones.

singalsu · 2024-02-26T17:26:03Z

src/audio/google/google_rtc_audio_processing.c

+	for (i = 0; i < cd->num_frames; ++i) {
+		for (s_chan = 0; s_chan < cd->num_aec_reference_channels; ++s_chan) {
+			/* Check that ref is within the valid range of the ref_buf buffer */
+			if ((int16_t const *)ref >= ref_buf_start &&


In what condition could the else happen? Can this check be done before the loop with known num_frames and num reference channels and o ther information?

singalsu · 2024-02-26T17:27:32Z

src/audio/google/google_rtc_audio_processing.c

+		/* If it does, wrap the reference buffer end pointer back to the start
+		 * of the buffer
+		 */
+		ref_end = (const int16_t *)ref_buf_start;


Would something like ref_data_end be a better name? I was first confusing this with ref_buf_end.

singalsu · 2024-02-26T17:29:10Z

src/audio/google/google_rtc_audio_processing.c

-		ref += cd->num_aec_reference_channels;
-		if ((void *)ref >= (void *)ref_buf_end)
-			ref = (void *)ref_buf_start;
+		if (memcpy_s(ref_buf, num_bytes, ref, num_bytes) != 0) {


I would not use mempcy_s() in hot code parts. There's num_bytes in both source and dest size so memcpy_s() never will return error. This seems to apply for all memcpy_s() usages in this patch.

singalsu · 2024-02-26T17:36:24Z

src/audio/google/google_rtc_audio_processing.c

+	const int16_t *src_end = src + cd->num_frames * cd->config.output_fmt.channels_count;
+
+	/* Check if the calculated end of the source buffer exceeds the actual end of the buffer */
+	if (src_end >= (const int16_t *)src_buf_end)


There's quite many of these pointer check and wrap code lines. An inline function or macro (ternary?) would make cleaner looking code.

E.g. cir_buf_wrap() from audio_stream.h.

lyakh · 2024-02-27T07:29:07Z

@ShriramShastry could you please explain in simple terms what exactly you're trying to optimise in this PR - which algorithms you find non-optimal, how you replace them, and - very importantly - how you test the result? Can you provide a single simple example like "I take this kind of a loop and replace it with this and this brings X% performance gain?"

cujomalainey · 2024-02-28T17:22:35Z

Sorry but google is going to NACK this until we at least get a release and stabilize this component first

lgirdwood · 2024-02-29T13:35:37Z

Sorry but google is going to NACK this until we at least get a release and stabilize this component first

Okay, we'll wait till the release and stable component are available.

Pushing it out to v2.10 to allow stabilization, baseline MCPS measurements and alignment.

singalsu

Can you check these please.

singalsu · 2024-02-29T12:27:59Z

src/audio/google/google_rtc_audio_processing.c

 	int16_t *dst;
 	int8_t *dst_buf_start;
 	int8_t *dst_buf_end;
 	size_t dst_buf_size;


Please add to commit message how much is MCPS performance is before and after (assuming stub library) in some platform you tested , or at least some cycles reduce % with some simulator core config. The optimization seems to cover both IPC3 and IPC4 parts. For IPC3 the relevant platform is e.g. TGL (or ADL - but in this context same), and for IPC4 MTL.

singalsu · 2024-02-29T12:56:41Z

src/audio/google/google_rtc_audio_processing.c

-			cd->aec_reference_buffer[buffer_offset++] = ref[channel];
-#endif /* CONFIG_COMP_GOOGLE_RTC_USE_32_BIT_FLOAT_API */
+	int16_t *ref_buf = cd->aec_reference_buffer;
+	size_t sizeofrefbuffer = sizeof(cd->aec_reference_buffer);


This is used only one, could use this directly later (if correct code, looks suspicious). This would be size of of the content of the pointer, a single float or int16.

I believe you are correct about the problem with size_t sizeofrefbuffer = sizeof(cd->aec_reference_buffer); because in C, the sizeof operator returns the size of the variable's type rather than the buffer it points to. If sizeofrefbuffer is expected to represent the buffer's size, it may cause incorrect behavior. sizeof cannot be used to calculate the size of cd->aec_reference_buffer if it is a dynamically allocated array because it must be tracked separately when created. sizeof can be used to determine the size of a statically allocated array, but only in the scope where the array is defined, not on a pointer to the array. As a result, I feel the goal is to determine the size of the buffer cd->aec_reference_buffer. I'II fix bug.

Thank you

singalsu · 2024-02-29T12:59:43Z

src/audio/google/google_rtc_audio_processing.c

-		ref += cd->num_aec_reference_channels;
-		if ((void *)ref >= (void *)ref_buf_end)
-			ref = (void *)ref_buf_start;
+	if (num_bytes > sizeofrefbuffer) {


Isn't this now comparing num_bytes to sizeof(int16_t)?

singalsu · 2024-02-29T13:03:23Z

src/audio/google/google_rtc_audio_processing.c

+	const int16_t *src_end = src + cd->num_frames * cd->config.output_fmt.channels_count;
+
+	/* Check if the calculated end of the source buffer exceeds the actual end of the buffer */
+	src_end = (int16_t *)cir_buf_wrap((void *)src_end,


I dont' think cir_buf_wrap needs type casts for input arguments.

I see the following warning.

[14/33] Building C object modules/sof/CMakeFiles/modules_sof...f_aec/sof/src/audio/google/google_rtc_audio_processing.c.obj /home/shastry/work/sof/sof_aec/sof/src/audio/google/google_rtc_audio_processing.c:952:25: warning: passing 'const int16_t * ' (aka 'const short *') to parameter of type 'void *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers ] src_end = cir_buf_wrap(src_end, src_buf_start, src_buf_end);

And so on for all of the cir_buf_wrap() calls in the code.

To address these warnings, we could change the cir_buf_wrap function to accept const void * parameters instead. The cir_buf_wrap_const() change allows to pass const pointers to the function without discarding the const qualifier.

singalsu · 2024-02-29T13:26:46Z

src/audio/google/google_rtc_audio_processing.c

+		/* If the source pointer has reached or exceeded the end of the source
+		 * buffer, wrap it back to the start
+		 */
+		src = (int16_t *)cir_buf_wrap((void *)src,


same, no type casts for arguments needed?

singalsu · 2024-02-29T13:34:08Z

src/audio/google/google_rtc_audio_processing.c

+			/* If we haven't filled the buffer yet, copy the data */
+			if (cd->raw_mic_buffer_frame_index < cd->num_frames) {
+				size_t num_bytes = sizeof(int16_t) * cd->num_capture_channels;
+				size_t buffer_size = sizeof(cd->raw_mic_buffer);


Is this correct, this would be size of a single sample?

The original code calculates the total size of the memory block pointed to by cd->raw_mic_buffer using cd->num_frames * cd->num_capture_channels * sizeof(cd->raw_mic_buffer[0]). To calculate the memory block's total size in bytes, multiply the total number of frames by the number of samples per frame and the size of a single sample.

Modified code: The line size_t buffer_size = sizeof(cd->raw_mic_buffer); calculates the size of the pointer cd->raw_mic_buffer, not the entire memory block it points to. The sizeof operator returns the _pointer's size_ rather than the _memory block_ to which it points.

Yes, your right -this a Bug, I'II fix it.

singalsu · 2024-02-29T13:35:08Z

src/audio/google/google_rtc_audio_processing.c

+				size_t buffer_size = sizeof(cd->raw_mic_buffer);
+				size_t frame_index = cd->raw_mic_buffer_frame_index;
+				size_t buffer_used = frame_index * sizeof(int16_t);
+				size_t buffer_remaining = buffer_size - buffer_used;


You can combine these equations and eliminate variables those are not used later in this inner loop.

cujomalainey · 2024-02-29T17:27:45Z

Sorry but google is going to NACK this until we at least get a release and stabilize this component first

Okay, we'll wait till the release and stable component are available.

Thanks :) just remember, premature optimization is the root of all evil

ShriramShastry

Thank you for reviewing the code. I 've included the modification, please have a look.

ShriramShastry · 2024-02-29T07:03:16Z

src/audio/google/google_rtc_audio_processing.c

+	float **proc_ptr = cd->process_buffer_ptrs;
+
+	/* Check for null pointers and buffer overflows */
+	if (!dst || !proc_ptr || dst >= dst_end || *proc_ptr >= *proc_ptr + cd->num_frames)


The cir_buf_wrap function wraps circular buffers if a pointer goes beyond the buffer's end. It determines dst_end by determining the number of frames and channels. If dst >= dst_end, it means all data has been processed. However, the condition *proc_ptr >= *proc_ptr + cd->num_frames is always false, I would like your opinion and may need to be altered for safety.

ShriramShastry · 2024-02-29T14:18:44Z

src/audio/google/google_rtc_audio_processing.c

+	size_t num_bytes = (ref_data_end - ref) * sizeof(*ref);

-		ref += cd->num_aec_reference_channels;
-		if ((void *)ref >= (void *)ref_buf_end)


The changed code does not explicitly include the logic for incrementing the ref pointer by cd->num_aec_reference_channels and verifying if ref has reached or surpassed ref_buf_end.

However, the changed code retains similar reasoning in a new way. The changed code's line ref = ref_data_end; essentially shifts the ref pointer to the end of the most recently processed data. In the original code, cd->num_aec_reference_channels was used to increment ref.

The original code's check if ((void *)ref >= (void *)ref_buf_end) is used to return the ref pointer to the buffer's beginning if it has reached or beyond the end. In the changed code, the cir_buf_wrap function calculates src_end.

ShriramShastry · 2024-02-29T14:19:48Z

src/audio/google/google_rtc_audio_processing.c

 	/* 32float: de-interlace ref buffer, convert it to float, skip channels if > Max
 	 * 16int: linearize buffer, skip channels if > Max
 	 */
+	/* Reduce cycle waste by streamlining the inner loop,


OK, I keep the comment here and add in commit message. Hope it is ok.

ShriramShastry · 2024-02-29T14:20:45Z

src/audio/google/google_rtc_audio_processing.c

 	assert(!ret);
 	src_buf_end = src_buf_start + src_buf_size;

+	/* The second optimization eliminates the inner loop


Yup, I'II add in the commit message, and keep the comment.

This check-in proposal enhances the audio Echo Cancellation AEC) implementation. The enhancements seek to enhance loop designs and memory copy operations, reducing cycle consumption. When pointer arithmetic is substituted for array indexing, it expedites performance and enhances data processing. To maximize efficiency, data copy verification is done outside of the loop, and performance is increased by using pointer arithmetic instead of inner loops. Error management is included when the size of the destination buffer is exceeded by the source data. Before converting or copying data, the pointers "ref," "src," and "dst" are verified to be inside the valid range of "ref_buf," "src_buf," and "dst_buf." These changes improve the code's robustness and efficiency by adding the necessary error checks. Signed-off-by: shastry <malladi.sastry@intel.com>

ShriramShastry

Thank you for reviewing the code; I've included your suggestions, and please take a look.

Thank you.

ShriramShastry · 2024-03-02T11:49:54Z

src/audio/google/google_rtc_audio_processing.c

-			cd->aec_reference_buffer[buffer_offset++] = ref[channel];
-#endif /* CONFIG_COMP_GOOGLE_RTC_USE_32_BIT_FLOAT_API */
+	int16_t *ref_buf = cd->aec_reference_buffer;
+	size_t sizeofrefbuffer = sizeof(cd->aec_reference_buffer);


I believe you are correct about the problem with size_t sizeofrefbuffer = sizeof(cd->aec_reference_buffer); because in C, the sizeof operator returns the size of the variable's type rather than the buffer it points to. If sizeofrefbuffer is expected to represent the buffer's size, it may cause incorrect behavior. sizeof cannot be used to calculate the size of cd->aec_reference_buffer if it is a dynamically allocated array because it must be tracked separately when created. sizeof can be used to determine the size of a statically allocated array, but only in the scope where the array is defined, not on a pointer to the array. As a result, I feel the goal is to determine the size of the buffer cd->aec_reference_buffer. I'II fix bug.

Thank you

ShriramShastry · 2024-03-03T08:14:18Z

src/audio/google/google_rtc_audio_processing.c

+			/* If we haven't filled the buffer yet, copy the data */
+			if (cd->raw_mic_buffer_frame_index < cd->num_frames) {
+				size_t num_bytes = sizeof(int16_t) * cd->num_capture_channels;
+				size_t buffer_size = sizeof(cd->raw_mic_buffer);


The original code calculates the total size of the memory block pointed to by cd->raw_mic_buffer using cd->num_frames * cd->num_capture_channels * sizeof(cd->raw_mic_buffer[0]). To calculate the memory block's total size in bytes, multiply the total number of frames by the number of samples per frame and the size of a single sample.

Modified code: The line size_t buffer_size = sizeof(cd->raw_mic_buffer); calculates the size of the pointer cd->raw_mic_buffer, not the entire memory block it points to. The sizeof operator returns the _pointer's size_ rather than the _memory block_ to which it points.

Yes, your right -this a Bug, I'II fix it.

ShriramShastry · 2024-03-03T11:48:54Z

src/audio/google/google_rtc_audio_processing.c

+	const int16_t *src_end = src + cd->num_frames * cd->config.output_fmt.channels_count;
+
+	/* Check if the calculated end of the source buffer exceeds the actual end of the buffer */
+	src_end = (int16_t *)cir_buf_wrap((void *)src_end,


I see the following warning.

[14/33] Building C object modules/sof/CMakeFiles/modules_sof...f_aec/sof/src/audio/google/google_rtc_audio_processing.c.obj /home/shastry/work/sof/sof_aec/sof/src/audio/google/google_rtc_audio_processing.c:952:25: warning: passing 'const int16_t * ' (aka 'const short *') to parameter of type 'void *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers ] src_end = cir_buf_wrap(src_end, src_buf_start, src_buf_end);

And so on for all of the cir_buf_wrap() calls in the code.

To address these warnings, we could change the cir_buf_wrap function to accept const void * parameters instead. The cir_buf_wrap_const() change allows to pass const pointers to the function without discarding the const qualifier.

ShriramShastry · 2024-05-09T13:19:27Z

Sorry but google is going to NACK this until we at least get a release and stabilize this component first

Okay, we'll wait till the release and stable component are available.

Thanks :) just remember, premature optimization is the root of all evil

@cujomalainey , Do you have any progress ?
Thank you

cujomalainey · 2024-06-11T17:06:40Z

Sorry but google is going to NACK this until we at least get a release and stabilize this component first

Okay, we'll wait till the release and stable component are available.

Thanks :) just remember, premature optimization is the root of all evil

@cujomalainey , Do you have any progress ? Thank you

#8919 is still blocked

lyakh · 2024-06-12T12:10:07Z

src/audio/google/google_rtc_audio_processing.c

+/* Function prototype for google_rtc_safe_memcpy */
+int google_rtc_safe_memcpy(struct google_rtc_audio_processing_comp_data *cd, int16_t *dst,
+			   int16_t *src, size_t num_bytes, size_t buffer_size,
+			   size_t frame_index);


this prototype makes no sense here. Either please make the function static or declare it in a header - if it needs to be called from other files.

lyakh · 2024-06-12T12:11:47Z

src/audio/google/google_rtc_audio_processing.c

+
+		/* Copy the source data to the destination buffer */
+		buffer_start += offset;
+		memcpy(buffer_start, src, num_bytes);


how about just memcpy(dst + offset,...)

lyakh · 2024-06-12T12:12:57Z

src/audio/google/google_rtc_audio_processing.c

+	/* Free the old buffer if it exists */
+	if (cd->aec_reference_buffer) {
+		free(cd->aec_reference_buffer);
+		cd->aec_reference_buffer = NULL;


redundant, it's overwritten 4 lines later

lyakh · 2024-06-12T12:13:49Z

src/audio/google/google_rtc_audio_processing.c

+	size_t number_of_elements = cd->num_frames * cd->num_aec_reference_channels;
+
+	/* Free the old buffer if it exists */
+	if (cd->aec_reference_buffer) {


redundant, freeing NULL should be ok

lyakh · 2024-06-12T12:14:35Z

src/audio/google/google_rtc_audio_processing.c

+
+	/* Free the old buffer if it exists */
+	if (cd->aec_reference_buffer) {
+		free(cd->aec_reference_buffer);


what is this function? Are you calling Zephyr libc free()? Is this what is needed here?

lyakh · 2024-06-12T12:15:04Z

src/audio/google/google_rtc_audio_processing.c

+	}
+
+	/* Allocate the new buffer */
+	cd->aec_reference_buffer = malloc(number_of_elements * sizeof(int16_t));


malloc()?

memory allocation inside processing? I'll stop here.

kv2019i · 2024-09-06T10:33:42Z

Release reminder - one week to v2.11-rc1.

lyakh requested changes Feb 22, 2024

View reviewed changes

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch from 1fee8c6 to 7ab7496 Compare February 23, 2024 07:46

ShriramShastry requested review from cujomalainey, johnylin76, lgirdwood and singalsu February 23, 2024 07:49

ShriramShastry marked this pull request as ready for review February 23, 2024 09:09

ShriramShastry requested a review from a team as a code owner February 23, 2024 09:09

ShriramShastry requested review from lyakh and marcinszkudlinski February 23, 2024 09:09

lgirdwood reviewed Feb 23, 2024

View reviewed changes

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch 6 times, most recently from 33fcded to 6ec3be3 Compare February 26, 2024 07:30

lyakh reviewed Feb 26, 2024

View reviewed changes

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch from 6ec3be3 to cfd021f Compare February 26, 2024 11:33

ShriramShastry requested review from lgirdwood and lyakh February 26, 2024 12:05

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch from cfd021f to e71095c Compare February 26, 2024 12:28

ShriramShastry requested review from lkoenig and perahgren February 26, 2024 12:48

ShriramShastry commented Feb 26, 2024

View reviewed changes

singalsu reviewed Feb 26, 2024

View reviewed changes

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch from e71095c to 7d2d12d Compare February 28, 2024 15:27

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch from b612915 to 7c91c4e Compare February 29, 2024 06:59

lgirdwood added this to the v2.10 milestone Feb 29, 2024

singalsu reviewed Feb 29, 2024

View reviewed changes

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch from 7c91c4e to 05745bd Compare March 1, 2024 17:29

ShriramShastry commented Mar 1, 2024

View reviewed changes

ShriramShastry requested a review from johnylin76 March 2, 2024 03:30

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch 2 times, most recently from fdf5826 to a3376f3 Compare March 3, 2024 14:26

ShriramShastry requested review from dbaluta, kv2019i, lbetlej, mmaka1 and plbossart as code owners March 3, 2024 14:26

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch 2 times, most recently from 09cd6df to 2822725 Compare March 3, 2024 14:45

ShriramShastry force-pushed the shastry_aec_optimization_perf_dev branch from 2822725 to 476dd43 Compare March 3, 2024 15:19

ShriramShastry commented Mar 3, 2024

View reviewed changes

ShriramShastry requested a review from singalsu March 3, 2024 16:01

lgirdwood modified the milestones: v2.10, v2.11 Apr 16, 2024

lyakh reviewed Jun 12, 2024

View reviewed changes

kv2019i modified the milestones: v2.11, v2.12 Sep 13, 2024

kv2019i removed this from the v2.12 milestone Jan 3, 2025

Audio: aec: optimize acoustic echo cancellation processing #8877

Are you sure you want to change the base?

Audio: aec: optimize acoustic echo cancellation processing #8877

Uh oh!

Conversation

ShriramShastry commented Feb 21, 2024

Uh oh!

lyakh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShriramShastry left a comment

Choose a reason for hiding this comment

Uh oh!

lgirdwood commented Feb 26, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

singalsu Feb 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lyakh commented Feb 27, 2024

Uh oh!

cujomalainey commented Feb 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lgirdwood commented Feb 29, 2024

singalsu Feb 26, 2024 •

edited

Loading

cujomalainey commented Feb 28, 2024 •

edited

Loading

ShriramShastry left a comment •

edited

Loading