[BUG] Peak Meter reports wrong value in case of 24/32 and 16/16 bit formats

[iganakov]

Describe the bug
In current implementation Peak Meter reports wrong volume. For example:
In 24/32 format case max volume reported is 0x007FFFFF instead of 0x7FFFFF00
In 16/16 format case max volume reported is 0x00007FFF instead of 0x7FFF7FFF

Reported value in Peak Meter register is much lower then expected

To Reproduce
Use firmware-automated-testing.fat framework and run test below:
test_10_gain_peak_vol_api.TestGainPeakVolApi.test_01_10_peakvol_read_volume

Reproduction Rate
100%

Expected behavior
In case of 24/32 and 16/16 bit formats Peak Meter register value has to be normalized
to represent volume in range 0x00000000 - 0x7FFFFFFF.

Impact
Showstopper

Environment
SOF: main
Platform: MTL

Screenshots or console output
Below screenshots are from the test output mentioned above

[iganakov]

@andrula-song I noticed you're an author of volume_hifi3_with_peakvol.c
Could you please help to fix this?

[andrula-song]

the 24/32 bit format fix is here #7669. And as we discussed, I'm still concerned about the "0x7FFF7FFF" of 16/16 bit format. It is reasonable as 0x7fff0000 or 0x7fff, but does not make sense for me as "0x7FFF7FFF", since we are seeking the max value of 16-bit data.

[mwasko]

the 24/32 bit format fix is here #7669. And as we discussed, I'm still concerned about the "0x7FFF7FFF" of 16/16 bit format. It is reasonable as 0x7fff0000 or 0x7fff, but does not make sense for me as "0x7FFF7FFF", since we are seeking the max value of 16-bit data.

@andrula-song the peak meter register value is 32bit and regardless to audio stream format we have to normalize this value to 32bit. While for 24/32 bit we can simply to the shift (the least significant 8 bytes has marginal impact) that for 16 bit the expectation of SW Driver is that it will be filled with 7FFF. This is required for Windows compatibility and to assure consistent behavior across Linux and Windows we should adjust this field to have single implementation. Otherwise we will end up with unnecessary FW variations.

[lgirdwood]

@andrula-song fixed in main ?

[andrula-song]

Sorry, I missed this issue. But actually, I still don't think the expected "0x7FFF7FFF" is a right value, it is because the closed fw use AE_MOVF32X2_FROMF16X4 to convert the ae_int16x4 to ae_int32x2, which filled the low 16 bits of a 32 element of ae_int32x2 with the second( or 4th) element of ae_int16x4(for example, ae_int16x4 is [0x12, 0x12,0x12, 0x12], then the result would be [0x120012, 0x120012]), and cut off the low 16 bits results in follow_up calculation.

Normalize the maximum value to 32bit makes sense, of course I can do this. But I still doubt the expected value is "0x7FFF7FFF" instead of "0x7FFF0000" whether a detection threshold setting error.

[lgirdwood]

@mwasko @kfrydryx @andrula-song topic for next tech sync.

[mengdonglin]

Fixed by #7934