[BUG IMX] Loopback implementation using demux

[giuzan]

Premise

I think that the loopback feature could be very useful in SOF. With loopback I basically mean a capture PCM from which we can read the samples that are written in playback. You can find this functionality in ALSA, known as ALSA Loopback. I think that performing the loopback job inside the DSP would be very useful. Developers who want to integrate its own echo canceller block can really take advantage of this feature.

I think that I have found a good example of that in sof-apl-demux-pcm512x.m4 topology.

I tried to port that topology into imx8 cs42888. You can find the m4 file here https://github.com/giuzan/sof/blob/c5f4111078e052597e233d3770d773f02f18f1e2/tools/topology/sof-imx8-cs42888-demux.m4.

The topology I build is shown in the following picture:

Unfortunately, I experienced an issue (see description below). It is the reason why I opened this [BUG]. If you think that the loopback topic is beyond this issue, please let me know if it should be treated as a proposed [FEATURE].

Describe the bug

If you run the command
arecord -D hw:1,1 -c 2 -r 48000 -f S16_LE record.wav
the following error is printed
arecord: pcm_read:2149: read error: Input/output error

Moreover, if you arecord during an aplay, the playback stream stops until the arecord does not exit after the error.

To reproduce

arecord -D hw:1,1 -c 2 -r 48000 -f S16_LE record.wav

or

aplay -D hw:1,0 file.wav & arecord -D hw:1,1 -c 2 -r 48000 -f S16_LE record.wav

Reproduction rate

100%

Expected behavior

The file record.wav recorded through the capture pipeline should contain the samples processed by the playback pipeline.

Impact

I cannot implement loopback for echo cancellation.

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: https://source.codeaurora.org/external/imx/linux-imx/tree/?h=imx_5.4.47_2.2.0
   • SOF: giuzan@c5f4111 (it basically is the imx-stable-v1.5 branch with the topology above applied)
2. Name of the topology file
   • Topology: sof-imx8-cs42888-demux.m4
3. Name of the platform(s) on which the bug is observed.
   • Platform: i.MX8QM

[lgirdwood]

@giuzan buffers cant do any processing here. i.e. your buf2.0 has 2 inputs. Shouldn't this be demix1.0 -> buf -> echoref2 instead ?

[giuzan]

@lgirdwood

Yes, I agree, it sounds weird to me too that a buffer has two input streams. I would expect that the only components which are allowed to have more than one stream (in input or in output) should be only: mixer (that mixes N streams into one) and demux/mux (the first creates one stream from many, the second creates more streams from one). Am I wrong? Or in general is it allowed also for other non-buffer components?

Anyway, I took inspiration from sof-apl-demux-pcm512x that has the same "double input". See picture below.

Do you think the issue I experienced is related to this kind of configuration in general or it could be limited to imx platform only?

[giuzan]

@lgirdwood

About your suggestion demix1.0 -> buf -> echoref2

Do you mean something like that?

[lgirdwood]

@giuzan so a buffer only has 1 sink and 1 source but a processing component can have N sinks and N sources (it's upto the component designer). Your pipeline above should have a buffer between ESAI0.IN and ECHO_REF2 but otherwise looks good. Your first pipeline is good if you also connect MUX to ECHO REF (i.e. echo ref has 2 inputs). Note you will need to tell topology that it's OK for some buffer to overrun/underrun (since the user can start PCM0P and PCM0C at different times and in different orders).

[giuzan]

Hi @lgirdwood and @dbaluta,

I tried the topology in the picture below. You can find the M4 here https://github.com/giuzan/sof/blob/giuzan_imx-stable-v1.6_loop/tools/topology/sof-imx8-cs42888-demux-loop.m4.

I implemented a custom component (test loop) that takes as sources the demux output (BUF2.2) and the DAI input (BUF2.1). My wish is that this component would couple the two 2-channels input sources in an output sink containing 2+2 channels (2 from BUF2.2 and 2 from BUF2.1). As first step I tried with a simpler scenario where the sink has only 2 channels, for the moment the DAI input samples are discarded.

Unfortunately I experienced the same input/output error above in capture scenario. And dmesg shows the following errors:

[  101.618087] sof-audio-of 556e8000.dsp: error: ipc timed out for 0x60050000 size 12
[  101.625698] sof-audio-of 556e8000.dsp: error: waking up any trace sleepers
[  101.632639] sof-audio-of 556e8000.dsp: error: trace IO error
[  101.634108]  Capture: ASoC: trigger FE cmd: 0 failed: -110
[  102.162080] sof-audio-of 556e8000.dsp: error: ipc timed out for 0x60030000 size 12
[  102.169689] sof-audio-of 556e8000.dsp: error: waking up any trace sleepers
[  104.722083] sof-audio-of 556e8000.dsp: error: ipc timed out for 0x40010000 size 7

About buffer overrun/underrun, I did not be able to allow it through topology configuration. Hence I hardcoded in buffer.c (just to perform the test):

buffer->stream.underrun_permitted = true;
buffer->stream.overrun_permitted = true;

---

I tried also another scenario (M4 in https://github.com/giuzan/sof/blob/giuzan_imx-stable-v1.6_loop/tools/topology/sof-testloop-imx8qm-cs42888.m4) where I used the test loop component also in playback, to copy the source in two sinks. I experienced the same issue, in playback also. Could be that is there something wrong with my test component? The code is here https://github.com/giuzan/sof/blob/giuzan_imx-stable-v1.6_loop/src/audio/test_loop/test_loop.c.

In particular, I have the issue when I connect the two pipelines, in other words if I remove the following lines from the the topology M4 the streaming (both playback and capture) works:

SectionGraph."PIPE_LOOP" {
	index "0"

	lines [
		dapm(PIPELINE_LOOPBACK_IN_BUFFER_2, PIPELINE_LOOPBACK_OUT_1)
		dapm(PIPELINE_LOOPBACK_IN_2, PIPELINE_LOOPBACK_IN_BUFFER_2)
	]
}

[iuliana-prodan]

Hi @giuzan,

I intend to look on the loopback, also. So, please, let me give it a try and I'll come back to you.

First thing to notice on your topology is that you should have two registrable tasks since you have ESAI input and ESAI output.
The SCHEDULE_TIME_DOMAIN_DMA was written with the assumption that there is only one registrable task.

Also, after how many iterations do you get the ipc timeout?
Maybe, try to apply this commit.

Thanks,
Iulia

[giuzan]

Hi @iuliana-prodan,

Thanks for your feedback.

I get the ipc at the first iteration.

Ok, let me know after your try. In the middle, I'll try to apply the commit you linked and repeat the test.

[iuliana-prodan]

I get the ipc at the first iteration.

Great, this will be much easier to reproduce :)

[lgirdwood]

@giuzan the IPC timout looks like a hang somewhere ?

[giuzan]

@lgirdwood On DSP side is difficult to evaluate that, because the sof-logger crashes after the error. I cannot see the log prints before, since I guess that they are not yet flushed.