[BUG]DEMUX comp not work normally with channel 4 to 2 with format conversion

[xiulipan]

Describe the bug
Used to be #2533
The DEMUX should copy the data from source to sink without any error, but now with DEMXU comp, the copy out data is broken when copy channel 4 to channel 2 with format conversion

To Reproduce
Use demux test tplg sof-apl-demux-pcm512x.tplg (#2958 ) to replace the sof-apl-nocodec.tplg with sof-apl-demux-nocodec.tplg

aplay -Dhw:0,0 -f s32_le -c 4 -r 48000 wav/32le-4ch-sin-100-400hz.wav -vvv
arecord -Dhw:0,4 -f s16_le -c 2 -r 48000 2ch_s16.wav -vvv
arecord -Dhw:0,4 -f s32_le -c 2 -r 48000 2ch_s32.wav -vvv

Reproduction Rate
100%

Expected behavior
The record wav should be same with s16le and s32le

Impact
This will be a stopper for echo reference and smart amplifier

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: sof-dev 3914cd2
   • SOF: master d9e3d4d(TPLG from [RFC]topology: Add nocodec demux test tplg #2958 )
2. Name of the topology file
   • Topology: sof-apl-demux-nocodec.tplg rename to sof-apl-nocodec.tplg
3. Name of the platform(s) on which the bug is observed.
   • Platform: APL

Screenshots or console output

All wav files and trace log attached.
wavandlog.zip

[juimonen]

@xiulipan can you still be more specific, so you are playing s32, so is the 32 or 16 bit demux data broken?

[juimonen]

@xiulipan although all bugs are bad, we should probably try playing S16 data as I don't see too many user space folks/apps ever using s32. Demux should be able to convert this to s32/s24 if some fw internal component uses that (or use the original S16).

Or is CRAS for example playing s32? just checking here, as I don't know...

[xiulipan]

@juimonen Playing s32 and demux extract s16 is broken.
I will try to playback s16 and update the test case. Not sure what CRAS will behave
@keyonjie Could you help to give more info with the smart amp usage here?

[xiulipan]

@juimonen with s16 source. the s32 demux is not working. So I think we do not support format switch in the demxu.

[keyonjie]

yes, @xiulipan mux/demux is expected to do channel mux/demux only, no sample rate or sample format changing inside it.

[lgirdwood]

Can we fix demux #2687 please. This will greatly simplify the code too. i.e.

/* stores all copy src/dest with increments - built during prepare() */
struct copy_elem {
    void * src;
    int src_increment;
    void *dest;
    int dest_increment;
};

/* copy - check for overflow BEFORE copy and alter num_copies to fit */
for (i = 0; i < num_copies; i++) {
    for (j = 0; j < num_elems; j++) {
        memcpy(elem[j].dest, elem[j].src, size); // memcpy used as example, but do this directly to save func call
        elem[j].dest += elem[j].dest_increment;
        elem[j].src += elem[j].src_increment;
    }
}

[keyonjie]

@mmaka1 has a discussion topic related to this here: https://github.com/orgs/thesofproject/teams/sof-developers/discussions/38

I am not clear what the implementation plan for that, but the PR #2788 should help to reject and avoid getting and providing wrong data to the user space.

[lgirdwood]

@keyonjie @xiulipan I want demux/mux to only to muxing and demuxing only. No mixing or format conversions please. I am not following from your comments if you are aligned with this ?

[keyonjie]

@keyonjie @xiulipan I want demux/mux to only to muxing and demuxing only. No mixing or format conversions please. I am not following from your comments if you are aligned with this ?

I got your point, but looks nobody is working on that #2687, everybody is waiting for the mux/demux author @akloniex to work on that?

[lgirdwood]

@juimonen fyi on #2687