[BUG] [TGL] [SDW] [DSM]: 2xCh ref capure slows down the playback

[yongzhi1]

Describe the bug
When playback is running with smart_amp_test module enabled, 2xch echo ref capture will slow down the playback noticeably, the playback speed resumes to normal upon ref capture exits.

The issue is not reproducible with 4xch capture.

To Reproduce

• aplay -Dhw:0,2 -c2 -f S16_LE /home/play16.wav -vvv
• arecord -Dhw:0,3 -f S16_LE -r48000 -c2 -d100 /home/echo.wav -vvv

Reproduction Rate
100%

Expected behavior
The echo reference can support 2 to 4 ch, the capture is running independently of smart playback. Use DMUX to change/select capture ch number should not influence the playback quality.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Environment

1. Branch name and commit hash:

   • Kernel: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ceab26b0e4f27f44465d88799119dc4572cefe2b
   • SOF: e0d648b (tag: releases/tgl/v10.0-rc1) codec_adapter: make certain .copy logs verbose

2. Name of the topology file

   • Topology: sof-tgl-sdw-max98373-rt5682.m4

3. Name of the platform(s) on which the bug is observed.

   • Platform: TGL

Screenshots or console output
smart-test-echoref-2ch-capure.zip
smt-test-log.txt

[plbossart]

@yongzhi1 I wasn't able to open your attachments neither on Ubuntu nor Mac.

what does 'slow down' mean?

a) the time to render a file of 10s is larger than 10s? can you run a 'time aplay ... file_10s.wav' so that we know the speed difference
b) you get underflows in the output?
c) something else?

[yongzhi1]

Hi, @plbossart

The zip file contains mp4 video, I uploaded it here:
https://www.youtube.com/watch?v=qMrD6ip_YHM&feature=youtu.be

The left side is the playback console, I then start 2xch capture from right console, stop and they tried 4xch.
(also tried S16_LE for both play and record, same observation) Thanks!!

[keyonjie]

since our demux component accepts output channel configs via configuration only and runtime configuration is not supported, looks we should shrink the channel support range from the pcm capability, @bkokoszx change like this could help:

diff --git a/tools/topology/sof/pipe-amp-ref-capture.m4 b/tools/topology/sof/pipe-amp-ref-capture.m4
index 1ade59786..08569a336 100644
--- a/tools/topology/sof/pipe-amp-ref-capture.m4
+++ b/tools/topology/sof/pipe-amp-ref-capture.m4
@@ -115,5 +115,5 @@ indir(`define', concat(`PIPELINE_PCM_', PIPELINE_ID), Echo Reference Capture PCM
 
 
 # PCM capabilities supported by FW
-PCM_CAPABILITIES(Echo Reference Capture PCM_ID, CAPABILITY_FORMAT_NAME(PIPELINE_FORMAT), 48000, 48000, 2, PIPELINE_CHANNELS, 2, 16, 192, 16384, 65536, 65536)
+PCM_CAPABILITIES(Echo Reference Capture PCM_ID, CAPABILITY_FORMAT_NAME(PIPELINE_FORMAT), 48000, 48000, PIPELINE_CHANNELS, PIPELINE_CHANNELS, 2, 16, 192, 16384, 65536, 65536)

[yongzhi1]

Hi, @keyonjie

It makes sense to restrict pcm capability ch_min = ch_max, but the playback issue is still there when PIPELINE_CHANNELS=2, thanks!!

[keyonjie]

Hi, @keyonjie

It makes sense to restrict pcm capability ch_min = ch_max, but the playback issue is still there when PIPELINE_CHANNELS=2, thanks!!

@yongzhi1 after restrict ch_min=ch_max=4, you will not be able to run arecord with PIPELINE_CHANNELS=2, the '-c4' is the only one mode supported.

[yongzhi1]

@yongzhi1 after restrict ch_min=ch_max=4, you will not be able to run arecord with PIPELINE_CHANNELS=2, the '-c4' is the only one mode supported.

Hi, @keyonjie, does above mean only 4 ch is supported to work correctly at the moment?

Right now, SMART_REF_CH_NUM is set to 2 for SSP 4893e70 followed by SDW version 2de5060, '-c2' is being used for 2 spk solution based on #3409.

[keyonjie]

@yongzhi1 the SMART_REF_CH_NUM counts here, if it is set to 2, then our PCM should claim to support 2 channels only, some change like this:

diff --git a/tools/topology/sof/pipe-amp-ref-capture.m4 b/tools/topology/sof/pipe-amp-ref-capture.m4
index 1ade59786..08569a336 100644
--- a/tools/topology/sof/pipe-amp-ref-capture.m4
+++ b/tools/topology/sof/pipe-amp-ref-capture.m4
@@ -115,5 +115,5 @@ indir(`define', concat(`PIPELINE_PCM_', PIPELINE_ID), Echo Reference Capture PCM
 
# PCM capabilities supported by FW
-PCM_CAPABILITIES(Echo Reference Capture PCM_ID, CAPABILITY_FORMAT_NAME(PIPELINE_FORMAT), 48000, 48000, 2, PIPELINE_CHANNELS, 2, 16, 192, 16384, 65536, 65536)
+PCM_CAPABILITIES(Echo Reference Capture PCM_ID, CAPABILITY_FORMAT_NAME(PIPELINE_FORMAT), 48000, 48000, SMART_REF_CH_NUM, SMART_REF_CH_NUM, 2, 16, 192, 16384, 65536, 65536)

[bkokoszx]

@yongzhi1
Could you try to reproduce this issue with #3583 PR?

[yongzhi1]

Hi, @bkokoszx,

Thanks for the patches, cherry-picked them on top of tgl v10.0-rc1:

d3a6f84010de (HEAD -> v10.0-rc1) demux: add demux_prepare_active_look_up() function
ad9bad42c016 mux: add channels check in mux_prepare_active_look_up()
8d5ac579ee11 mux: change prepare_active_look_up() function name

Issue is still reproducible.

I also noticed the 4xch ref capture for L and R amp, the expected layout is VIVI, but what captured looks like IVIV. Right now I am using yongzhi1@085c460 as a workaround.

[keyonjie]

@yongzhi1 I add the capability restriction patch I mentioned above and try 'arecord -c2' with SSP and the playback speed looks correct here.

[yongzhi1]

Hi, @keyonjie , thanks for sharing, somehow this problem only manifested itself for SDW not SSP.

[keyonjie]

@RanderWang do you think there is anything special here for SDW?

Anyway, let me submit the restriction PR as it is a right thing to do.