[DO NOT MERGE] [DO NOT REVIEW] pcm_converter: Replace asserts with sample number check to if instruction

[ktrzcinx]

Using if with return instruction is not so fatal consequences
as assertion, so fw will keep running after such an error.

Signed-off-by: Karol Trzcinski karolx.trzcinski@linux.intel.com

Fix for #3146

[plbossart]

Something fishy is going on, all legacy platforms fail alsa-bat tests and the logger shows tons of errors

[4338062316.041667] ( nan) c0 pcm_conv ......../pcm_converter.c:48 ERROR Free samples 0 in sink < samples to convert 96 + offset 0

see https://sof-ci.01.org/sofpr/PR3156/build6552/devicetest/ and e.g. look at the results for Broadwell.

[paulstelian97]

Something fishy is going on, all legacy platforms fail alsa-bat tests and the logger shows tons of errors

[4338062316.041667] ( nan) c0 pcm_conv ......../pcm_converter.c:48 ERROR Free samples 0 in sink < samples to convert 96 + offset 0

see https://sof-ci.01.org/sofpr/PR3156/build6552/devicetest/ and e.g. look at the results for Broadwell.

This change shouldn't actually affect what happens, this error should only show up when there was a panic before. Surely wasn't there some recovery code that detected the panic and reloaded the firmware when this happened and the reload made everything happen successfully?

There is indeed a problem, though I feel like this patch only unmasks it rather than causing it.

[paulstelian97]

Maybe the biggest issue is that pcm_convert_as_linear returns void and the error is traced and swallowed instead of reported in the upper layers. I'd suggest you take a look into that instead, see if there is a way to actually do the error propagation.

[lgirdwood]

@ktrzcinx I've reverted the original PR, can we rework this on top.

[lgirdwood]

Is the last patch temp or for upsgtream ?

[ktrzcinx]

SOFCI TEST

[lgirdwood]

@ktrzcinx looks like it needs a rebase prior to a retest.

[lgirdwood]

@ktrzcinx I checked the CI failures and all I could see was

449252956.354167] (449252960.000000) c0 hda-dma ..../intel/hda/hda-dma.c:440 hda-dmac: 4 channel 0 -> copy 0x1060 bytes
[449254143.437500] ( 1187.083374) c0 hda-dma ..../intel/hda/hda-dma.c:440 hda-dmac: 5 channel 0 -> copy 0x180 bytes
[449254183.593750] ( 40.156250) c0 hda-dma ..../intel/hda/hda-dma.c:334 hda-dmac: 7 channel 0 -> copy 0x170 bytes
[449255393.854167] ( 1210.260376) c0 hda-dma ..../intel/hda/hda-dma.c:440 hda-dmac: 5 channel 0 -> copy 0x180 bytes
[449255434.583333] ( 40.729168) c0 hda-dma ..../intel/hda/hda-dma.c:334 hda-dmac: 7 channel 0 -> copy 0x190 bytes
[449256644.010417] ( 1209.427124) c0 hda-dma ..../intel/hda/hda-dma.c:440 hda-dmac: 5 channel 0 -> copy 0x180 bytes
[449256684.531250] ( 40.520832) c0 hda-dma ..../intel/hda/hda-dma.c:334 hda-dmac: 7 channel 0 -> copy 0x180 bytes
[449257893.437500] ( 1208.906250) c0 hda-dma ..../intel/hda/hda-dma.c:440 hda-dmac: 5 channel 0 -> copy 0x180 bytes
[449257934.166667] ( 40.729168) c0 hda-dma ..../intel/hda/hda-dma.c:334 hda-dmac: 7 channel 0 -> copy 0x180 bytes

I would have expected the timing to be on 1ms instead of 1.2ms ? Any clues ?

[paulstelian97]

@ktrzcinx If this PR is still applicable, I recommend you send it again based on the "main" branch.