Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audio: Aria: Fix handling of S24_LE format, update blob ABI headers in topologies #9614

Merged
merged 6 commits into from
Oct 28, 2024

Conversation

singalsu
Copy link
Collaborator

plus other smaller

@singalsu singalsu marked this pull request as ready for review October 24, 2024 16:05
@singalsu singalsu requested a review from abonislawski October 24, 2024 16:06
@@ -57,17 +57,19 @@ inline void aria_algo_calc_gain(struct aria_data *cd, size_t gain_idx,
inu = AE_LA128_PP(in);
for (i = 0; i < n; i += 4) {
AE_LA32X2X2_IP(in_sample, in_sample1, inu, in);
in_sample = AE_MAXABS32S(in_sample, in_sample1);
max_data = AE_MAXABS32S(max_data, in_sample);
max_data = AE_MAXABS32S(max_data, AE_SLAI32(in_sample1, 8));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this intentional? So in_sample below is used as set in line 59 above?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's intentional. I think this is more clear, and no need to have left shift for both first AE_MAXABS32S input arguments.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, now all (generic, hifi3/4, hifi5) versions of Aria are bit exact with the input that I use.

return -EINVAL;
}
memcpy_s(&cd->att, sizeof(uint32_t), fragment, sizeof(uint32_t));
cd->att = (size_t)(*(uint32_t *)fragment);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so presumably fragment is always aligned?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know it's ensured... should I then memcpy() it to a local uint32_t and then type cast it to Aria's component data. I think it was a mistake to use size_t for most of Aria's internal state. But I didn't want to change everything with this fix.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like the align is ensured to be aligned. Even in handler.c ipc4_set_vendor_config_module_instance drv->ops.set_large_config() the type is char. Maybe it's best that I change the Aria component data type to uint32_t and keep the memcpy().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could just fix the types instead ? Sounds like we need to do it anyway ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, optimizing the code needs fixing the types.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed now, it needed only one aria.h edit to change the memcpy destination type.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like the align is ensured to be aligned. Even in handler.c ipc4_set_vendor_config_module_instance drv->ops.set_large_config() the type is char. Maybe it's best that I change the Aria component data type to uint32_t and keep the memcpy().

@singalsu there isn't a huge difference (supposedly on all 32-bit platforms, at least on Xtensa) between size_t and uint32_t, both are unsigned 32-bit integers. But if this should run on 64-bit ARM cores too, then there could be a difference

Copy link
Collaborator Author

@singalsu singalsu Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It failed in testbench 64bit x86 build.

The bits 31:24 are defined as don't care for S24_LE format
while the code in functions aria_algo_calc_gain() and
aria_algo_get_data() can work only if the bits contain the
sign extension. If such data is received, the processed
audio output is be corrupt.

The generic C version is fixed with use of helper function
sign_extend_s24().

Signed-off-by: Seppo Ingalsuo <[email protected]>
These changes implement the missing sign extension handling
for input data. The highest 8 bits in S24_LE format are don't
care. The presence of sign extension can't be assumed.

The max of max_data can be moved out from while loop as a
small improvement.

Signed-off-by: Seppo Ingalsuo <[email protected]>
These changes implement the missing sign extension handling
for input data. The highest 8 bits in S24_LE format are don't
care. The presence of sign extension can't be assumed.

The max of the two max values can be moved out from while
loop as a small improvement.

Signed-off-by: Seppo Ingalsuo <[email protected]>
The impact of parameter attenuation applied at aria_init()
and in bytes control blob is explained in more clear way.

Signed-off-by: Seppo Ingalsuo <[email protected]>
It depends on architecture but size_t and uint32_t are not
necessarily bits compatible (on 64bit arch like testbench
on x86). Therefore the type for att in component data of
Aria is changed to uint32_t.

A similar check as in aria_init() is added to avoid an illegal
value in the blob to break the processing algorithm.

An info level trace is added to see in trace if the blob
is applied by the Linux topology or in run-time.

Signed-off-by: Seppo Ingalsuo <[email protected]>
@singalsu singalsu force-pushed the aria_s24_format_fixes branch from dbef83a to ea6548d Compare October 25, 2024 16:52
@singalsu singalsu requested a review from lyakh October 25, 2024 16:55
Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, good commit messages, easy to follow!

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0x00, 0x00, 0x00"
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When looking at the quite similar hex values of the blob it might be that this would have worked if I had first done the size_t vs. uint32_t fix to code that failed on 64 bit build. I think I should rewrite the commit message to say it's a blob ABI update and blobs added for all allowed configurations of Aria.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

The blob for Aria is updated for current ABI version and
with options for all possible configurations. The new blobs
are passthrough.conf, and blobs for parameter values 1 - 3.
The benchmark topologies are configured to to use parameter
value 2 (+12 dB level boost target) and parameter value 1
(+6 dB boost target).

Signed-off-by: Seppo Ingalsuo <[email protected]>
@singalsu singalsu force-pushed the aria_s24_format_fixes branch from ea6548d to 6392107 Compare October 28, 2024 09:44
@singalsu singalsu changed the title Audio: Aria: Fix handling of S24_LE format, fix incorrect setup blob in topologies Audio: Aria: Fix handling of S24_LE format, update blob ABI headers in topologies Oct 28, 2024
@lgirdwood
Copy link
Member

@wszypelt @lrudyX good to merge ?

@wszypelt
Copy link

@lgirdwood all green

@lgirdwood lgirdwood merged commit fd1cdc8 into thesofproject:main Oct 28, 2024
43 of 47 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants