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

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

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
Name of the topology file
- Topology: sof-tgl-sdw-max98373-rt5682.m4
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

@yongzhi1

@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?

@plbossart

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!!

@bkokoszx

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)

@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!!

@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.

@yongzhi1

@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)

@yongzhi1

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

@bkokoszx

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.

@yongzhi1

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

@keyonjie

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

@RanderWang

@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.

@yongzhi1

@yongzhi1 here it is: #3599

@RanderWang

@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.

@keyonjie on FW side, SDW makes no difference.

@naveen-manohar

cc @naveen-manohar @ryans-lee

@slawblauciak

Hi, @slawblauciak, anyone tried to repro the issue yet?

@yongzhi1

@yongzhi1 @lgirdwood
Yes, we can reproduce that issue.

When we start only capture pipeline (with some additional logs) we get:

[222108184.635417] (     1839.375000) c0 dai          4.23           src/audio/dai.c:831  dai_copy(): avail_bytes: 384, dma_fmt: 2
[222108200.885417] (       16.250000) c0 dai          4.23           src/audio/dai.c:832  dai_copy(): buf->stream.size: 1536
[222108216.666667] (       15.781250) c0 dai          4.23           src/audio/dai.c:849  dai_copy(), dir: 1 copy_bytes= 0x180, frames= 24

Capture DAI copies only 24 frames per one period all the time (should copy 48 frames) and
it slows down playback pipeline during smart amp processing. I suspect there could be
some problem with SDW configuration - maybe capture SDW is configured to 2 channels
(pcm params) instead of 4 channels (DAI channels). It requires more debugging.

@RanderWang

Looks we can't support 2 channel FE + 4 channel BE for SDW at the moment, an alternate solution could be configuring SMART_REF_CH_NUM to 4.
@RanderWang @slawblauciak please chime in.

@yongzhi1

@yongzhi1 please check thesofproject/linux#2643

@RanderWang

Hi, @RanderWang, confirm the reported issue was fixed by thesofproject/linux#2643, thanks @keyonjie, @bkokoszx and @slawblauciak for your support!!

@RanderWang

@RanderWang @yongzhi1 feel free to close if this is now fixed.

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

plbossart commented on Oct 29, 2020

yongzhi1 commented on Oct 29, 2020

keyonjie commented on Oct 30, 2020

yongzhi1 commented on Oct 30, 2020

keyonjie commented on Oct 30, 2020

yongzhi1 commented on Oct 30, 2020

keyonjie commented on Nov 3, 2020

bkokoszx commented on Nov 4, 2020

yongzhi1 commented on Nov 5, 2020

keyonjie commented on Nov 6, 2020

yongzhi1 commented on Nov 6, 2020

keyonjie commented on Nov 10, 2020

keyonjie commented on Nov 10, 2020

RanderWang commented on Nov 11, 2020

yongzhi1 commented on Nov 17, 2020

yongzhi1 commented on Dec 3, 2020

bkokoszx commented on Dec 16, 2020

keyonjie commented on Dec 17, 2020

RanderWang commented on Dec 17, 2020

yongzhi1 commented on Dec 17, 2020

lgirdwood commented on Dec 18, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions