[BUG] DSP panic problem in ASRC component

[kkarask]

Describe the bug
In tests 19_00_TestAsrcPlayback8000Hz32b32b2ch and 19_00_TestAsrcPlayback48000Hz16b16b2ch Panic notification occurred.

Topology

              +---------------------------------+
    +------+    | +---+  +----+  +---+  +-------+ |
    | Host |----->|Buf|->|Asrc|->|Buf|->|SSP Dai|---+
    +------+    | +---+  +----+  +---+  +-------+ | |
                +---------------------------------+ |
                                                    |
                +------------------+                |
    +------+    | +---+  +-------+ |                |
    | Host |<-----|Buf|<-|SSP Dai|<-----------------+
    +------+    | +---+  +-------+ |
                +------------------+

To Reproduce
Run tests with Diagnostic driver 19_00_TestAsrcPlayback8000Hz32b32b2ch and 19_00_TestAsrcPlayback48000Hz16b16b2ch.

Reproduction Rate
100%
Problem doesn't exist before dc0ab8a

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • SOF: BRANCH: main HASH: dc0ab8a
2. Name of the platform(s) on which the bug is observed.
   • Platforms:
     • WHL RVP
     • ICL RVP
3. Test environment:
   • SOF: BRANCH: master HASH: b7ed915d911acda055bbb822800b76557e9fe7de

Screenshots or console output

2021_04_19_23_43_01.zip

[lgirdwood]

@singalsu 100% reproducible so should be easy to find.

[iuliana-prodan]

@singalsu 100% reproducible so should be easy to find.

I can confirm that I also found this issue.
Tried to add ASRC components in an imx pipeline who looked like: PCM0 <----> ASRC <----> volume <-----> SAI1 (wm8960).
When trying to playback a wav, even with 48kHz it crashes in SOF, I only get the IPC reply in kernel
(sof-audio-of 556e8000.dsp: error: hw params ipc failed for stream 0) and no logs in sof-logger.

[singalsu]

Thanks for reporting this! I will start checking tomorrow.

[singalsu]

Yep, confirm the panic happens with normal SOF linux driver controlled device, no need to set up diagnostic driver that eases the debugging for me.

Edit: The stack dump shows it happens at dai_ts_config(). I'll find out more next week.

[singalsu]

This avoid the panic but the pipeline no more works (with SSP DAI and setting up timestamp for SSP uses this information). I wonder if dd->chan has got deprecated.

diff --git a/src/audio/dai.c b/src/audio/dai.c
index 44c033671..07c80228f 100644
--- a/src/audio/dai.c
+++ b/src/audio/dai.c
@@ -1161,7 +1161,13 @@ static int dai_ts_config(struct comp_dev *dev)
        cfg->direction = dai->direction;
        cfg->index = dd->dai->index;
        cfg->dma_id = dd->dma->plat_data.id;
-       cfg->dma_chan_index = dd->chan->index;
+       if (dd->chan) {
+               cfg->dma_chan_index = dd->chan->index;
+       } else {
+               comp_err(dev, "dai_ts_config(), NULL chan");
+               return -EINVAL;
+       }
+
        cfg->dma_chan_count = dd->dma->plat_data.channels;
        if (!dd->dai->drv->ts_ops.ts_config)
                return -ENXIO;

@lgirdwood Do you remember if this has been changed?

Edit: Seems like dai_config_prepare() sets it. Maybe ASRC prepare happens before DAI has been prepared. Maybe ASRC should set up timestamps in first copy instead.

Edit 2: A fix where ASRC sets up timestamping in trigger start seems to work. Testing...

[lgirdwood]

@singalsu any asynchronous APIs should not assume a previous state. In this case the DAI API assumes that the timestamp is setup by prepare(). The DAI API needs to make this clear (where the timestamp and other async features APIs are ready) and survive any attempts to use the API prior to setup. i.e. we check for NULL

[iuliana-prodan]

@singalsu I've tested i.MX topology with ASRC, with your patches (#4095), and I don't get the DSP panic, anymore.

But I still have some questions regarding ASRC.
It seems to me that I can only convert from 8000 11025 16000 22050 32000 44100 48000 to 48000 Hz.
If I try a downsampling from 64000 to 48000 I get:

asrc         1.1      src/audio/asrc/asrc.c:571  asrc_prepare()
asrc         1.1   ...../asrc/asrc_farrow.c:750  ERROR initialise_filter(), fs_in = 64000
asrc         1.1   ...../asrc/asrc_farrow.c:384  ERROR asrc_initialise(), failed filter initialise
asrc         1.1      src/audio/asrc/asrc.c:695  ERROR initialise_asrc(), error -5

Which seems expected, by looking in asrc_farrow.c, in initialise_filter() and the asrc_conversion_ratios

But, I'm wondering why do you, in Intel's topologies, like sof-apl-asrc-pcm512x.m4 use 192000 Hz as max rate - see here .
Is this really converted to 48000 Hz? If yes, how?

Thanks!