[BUG] s24_4le unused/obsolete definitions?

[plbossart]

We seem to have obsolete/unused definitions for s24_4le? Is this intentional or leftover from the past?

git grep s24_4le
test/cmocka/src/audio/mux/demux_copy.c:                         tests[ti].name = get_test_name(j, "s24_4le");
test/cmocka/src/audio/mux/mux_copy.c:                           tests[ti].name = get_test_name(j, "s24_4le");
test/cmocka/src/audio/mux/mux_get_processing_function.c:static void test_mux_get_processing_function_valid_s24_4le(void **state)
test/cmocka/src/audio/mux/mux_get_processing_function.c:                TEST_CASE(test_mux_get_processing_function_valid_s24_4le),
tools/test/audio/sof_test_perf.m:       case 's24_4le'
tools/topology/m4/utils.m4:     $1, `s24_4le', `4',

[plbossart]

@lgirdwood @mmaka1 @ranj063 @singalsu any memories on format definitions?

[lgirdwood]

Possibly as a topology string only as SOF_IPC_FRAME_S24_4LE is supported.

[cujomalainey]

looks like this is being picked up by some of the codec adapters

[lgirdwood]

@juimonen can you take a look at this for v1.7 - and make sure all our s24 format string are aligned.
@cujomalainey fwiw, should not be an issue in the new topology 2.0 since everything will be validated at runtime (so all strings should align)

[lgirdwood]

@juimonen any update here ?

[lgirdwood]

@juimonen apologies, you are getting all the small fixes atm. Have you had any chance to fix ?

[juimonen]

I don't fully get what's the issue here... all of these in tests directory are strings for naming, I mean they could be like "foobar_24_xyrx", just giving some meaningful names to the tests. the utils.m4 in topology defines the sample format, which I assume should be left there (we are not using it anywhere in topology currently though).

[lgirdwood]

@juimonen I think we may have more than one s24_4le definition, it's about aligning to only use a single definition for each format.

[juimonen]

@lgirdwood, hmm I think we have a lot of following:

sof-icl-rt700.m4:PIPELINE_PCM_ADD(sof/pipe-volume-capture.m4,
sof-icl-rt700.m4- 2, 1, 2, s24le,
sof-icl-rt700.m4- 1000, 0, 0,
sof-icl-rt700.m4- 48000, 48000, 48000)

from where the s24le is going to PIPELINE_FORMAT -> used in COMP_SAMPLE_SIZE macro, which checks for s24_4le, but not s24le -> it defaults to value "4", why this works.... So yes I think this is actually a bug in topology definitions, just doesn't manifest itself as the default value in the sample size macro happens to match.