[BUG]KWD: DMIC(pcm 99) recording speed is doubled with kwd tplg

Describe the bug
I tried the sof-glk-da7219-kwd.tplg on glk, but found the dmic(pcm99) 4ch recording speed is double, 2ch recording has no such issue.

To Reproduce

arecord -Dhw:0,99 -f s16_le -c 4 -r 48000 dmic.wav -vvv
Then use audacity to play the recorded wav file.

Expected behavior
normal speed

Impact
double speed

Environment
1). kernel: sof-dev/35d7759478
2). irmware: master/3f1b92 + PR #1365
3). tplg: sof-glk-da7219-kwd.tplg.
4). platform: GLK chromebook
5). Reproducibility Rate. 100%.

dmesg
no obvious errors.

trace

   0      2          IPC             58772.500000        69.583336    src/ipc/handler.c:658    ipc: pm -> restore
    0      2          IPC             59212.812500       440.312500    src/ipc/handler.c:240    ipc: comp 22 -> params
    0      2         PIPE 4.27        59223.541667        10.729167 src/audio/pipeline.c:314    pipeline_params()
    0      2         HOST             59228.177083         4.635417     src/audio/host.c:514    host_params()
    0      2          DMA             59236.718750         8.541667 intel/cavs/hda-dma.c:464    hda-dmac: 4 channel 1 -> get
    0      2          DMA             59241.406250         4.687500 intel/cavs/hda-dma.c:685    hda-dmac: 4 channel 1 -> config
    0      2       VOLUME             59247.968750         6.562500   src/audio/volume.c:221    volume_params()
    0      2          DAI 4.26        59252.604167         4.635417      src/audio/dai.c:389    dai_params()
    0      2         PIPE 4.27        59260.468750         7.864583 src/audio/pipeline.c:352    pipeline_prepare()
    0      2         HOST             59264.427083         3.958333     src/audio/host.c:635    host_prepare()
    0      2       VOLUME             59270.937500         6.510417   src/audio/volume.c:546    volume_prepare()
    0      2          DAI 4.26        59278.750000         7.812500      src/audio/dai.c:445    dai_prepare()
    0      2          IPC             80853.229167     21574.478516    src/ipc/handler.c:479    ipc: comp 22 -> trigger cmd 0x40000
    0      2         PIPE 4.27        80864.375000        11.145833 src/audio/pipeline.c:579    pipeline_trigger()
    0      2         HOST             80868.697917         4.322917     src/audio/host.c:283    host_trigger()
    0      2          DMA             80873.072917         4.375000 intel/cavs/hda-dma.c:533    hda-dmac: 4 channel 1 -> start
    0      2          DMA             80877.031250         3.958333 intel/cavs/hda-dma.c:369    hda-dmac: 4 channel 1 -> enable
    0      2       VOLUME             80914.843750        37.812500   src/audio/volume.c:488    volume_trigger()
    0      2          DAI 4.26        80919.218750         4.375000      src/audio/dai.c:508    dai_comp_trigger(), command = 1
    0      2          DAI 4.26        80922.864583         3.645833      src/audio/dai.c:519    dai_comp_trigger(), START
    0      2         DMIC             80935.208333        12.343750 rs/intel/cavs/dmic.c:1448   dmic_trigger()
    0      2         DMIC             80939.218750         4.010417 rs/intel/cavs/dmic.c:1280   dmic_start()
    0      2         DMIC             80942.968750         3.750000 rs/intel/cavs/dmic.c:1287   dmic_start(), dmic->fifo_a
    0      2         DMIC             80947.187500         4.218750 rs/intel/cavs/dmic.c:1323   dmic_start(), mic_a = 1, mic_b = 1, fir_a = 1, fir_b = 1
    0      2         DMIC             80951.614583         4.427083 rs/intel/cavs/dmic.c:1323   dmic_start(), mic_a = 1, mic_b = 1, fir_a = 1, fir_b = 1
    0      2         DMIC             80956.302083         4.687500 rs/intel/cavs/dmic.c:1359   dmic_start(), dmic_active_fifos = 1
    0      2         DMIC             80963.125000         6.822917 rs/intel/cavs/dmic.c:1371   dmic_start(), done
    0      2          IPC           1531343.385417   1450380.250000    src/ipc/handler.c:479    ipc: comp 22 -> trigger cmd 0x50000
    0      2         PIPE 4.27      1531354.687500        11.302083 src/audio/pipeline.c:579    pipeline_trigger()
    0      2         HOST           1531358.854167         4.166667     src/audio/host.c:283    host_trigger()
    0      2          DMA           1531363.437500         4.583333 intel/cavs/hda-dma.c:627    hda-dmac: 4 channel 1 -> stop
    0      2       VOLUME           1531367.916667         4.479167   src/audio/volume.c:488    volume_trigger()
    0      2          DAI 4.26      1531371.927083         4.010417      src/audio/dai.c:508    dai_comp_trigger(), command = 0
    0      2          DAI 4.26      1531375.625000         3.697917      src/audio/dai.c:572    dai_comp_trigger(), PAUSE/STOP
    0      2          DMA           1531379.479167         3.854167 src/drivers/dw/dma.c:460    dw_dma_stop(): dma 0 channel 3 stop
    0      2         DMIC           1531388.958333         9.479167 rs/intel/cavs/dmic.c:1448   dmic_trigger()
    0      2         DMIC           1531392.656250         3.697917 rs/intel/cavs/dmic.c:1380   dmic_stop()
    0      2         DMIC           1531396.822917         4.166667 rs/intel/cavs/dmic.c:1400   dmic_stop(), dmic_active_fifos = 1
    0      2          IPC           1531471.770833        74.947914    src/ipc/handler.c:368    ipc: comp 22 -> free
    0      2         PIPE 4.27      1531482.447917        10.677083 src/audio/pipeline.c:634    pipeline_reset()
    0      2         HOST           1531486.562500         4.114583     src/audio/host.c:699    host_reset()
    0      2          DMA           1531490.625000         4.062500 intel/cavs/hda-dma.c:627    hda-dmac: 4 channel 1 -> stop

dmesg.log

logger-t.log

@singalsu

@singalsu can you help answer if we can support FIFOA in 4 channels and FIFOB 2 channels simultaneously?

@keyonjie

@keyonjie It may be possible, I'll check it.

@keyonjie

@keyonjie I'm able to repeat the issue. The decimator is forced into two channels configuration due to latter request from topology. The capture take double time and runs at half of intended rate (sort of -- the stereo channels populate the 4ch stream). This is as intended but we can add the non-symmetrical configuration as new feature. It wasn't a requirement before.

I'll see if a quick topology hack (reverse order of configuring DAI) can fix this. But if this is technically possible the driver need to be able to handle the request without specific order.

I also noticed that four channels volume is not controlled correctly by kernel driver (volume impacts only channels 1,2 while channels 3,4 are not controlled), need to file an issue about it.

@singalsu

Thank you so much, @singalsu makes sense.

@keyonjie

@keyonjie The topology trick cannot be used, the driver always passes DAI configuration in order 0 -> 1.

However I was able to add this new feature into FW driver code. The non-symmetrical configuration works. I just successfully test capture of 32 bit 4 channels 48 kHz from DAI 0 and capture of 16 bit 2 channels 16 kHz from DAI 1. I need to test more to make sure I didn't break something else and make a FW PR.

@singalsu

I need to test more to make sure I didn't break something else and make a FW PR

@singalsu can you provide the PR today?

@wenqingfu

@wenqingfu @keyonjie There's PR #1432 that you can start testing with. I need to fix the bug with overlapping capture tomorrow. You don't need to use my test topologies, the sof-glk-da7219-kwd.tplg should be compatible with this driver enhance as such.

@singalsu

Thanks @singalsu.
Yes, PR #1432 can fix the 4ch dmic capture issue, but this PR also has an impact on 2ch DMIC capture. The 2ch capture is not that clear and the speed is also halved. Please help to check.

I tested it with UP2 and I didn't have issue with 2ch capture. The only thing that failed was the mentioned simultaneous capture from two DMIC DAI but I assume you did test it. I have the difference that I created the test topology for 4ch & 2ch from scratch and used fresh git for both kernel and firmware. I'll try to convert the topology from GLK to UP2 see if the issue is there. I didn't yet try this on ChromeOS since I could replicate the issue with UP2.

@keqiaozhang

@keqiaozhang Also could you test this PR with a much simpler topology like sof-apl-dmic-a4ch-b2ch.m4 to eliminate that issue would be possibly from some other component.

To simplify things I created this test topology for glk. For me when using my DMIC PR #1432 capture works with good quality for both recording devices. Can you please try this there to confirm.

#
# Topology for GeminiLake with Dialog7219.
#

# Include topology builder
include(`utils.m4')
include(`dai.m4')
include(`pipeline.m4')
include(`ssp.m4')

# Include TLV library
include(`common/tlv.m4')

# Include Token library
include(`sof/tokens.m4')

# Include bxt DSP configuration
include(`platform/intel/bxt.m4')
include(`platform/intel/dmic.m4')

define(KWD_PERIOD_FRAMES, 320)
define(KWD_PIPE_SCH_DEADLINE_US, 20000)

#
# Define the pipelines
#
# PCM99 <---- volume (pipe 4)   <----- DMIC0 (dmic01 , BE link 2)
# PCM8  <---- volume (pipe 8)   <----- DMIC1 (dmic16k, BE link 6)

# Low Latency capture pipeline 4 on PCM 99 using max 4 channels of s32le.
# Schedule 48 frames per 1000us deadline on core 0 with priority 0
PIPELINE_PCM_ADD(sof/pipe-volume-capture.m4,
	4, 99, 4, s16le,
	48, 1000, 0, 0)


# Passthrough capture pipeline 8 on PCM 8 using max 2 channels.
# Schedule 320 frames per 1000us deadline on core 0 with priority 0
PIPELINE_PCM_ADD(sof/pipe-volume-capture-16khz.m4,
	8, 8, 2, s16le,
	KWD_PERIOD_FRAMES,
	KWD_PIPE_SCH_DEADLINE_US,
	0, 0)

#
# DAIs configuration
#


# capture DAI is DMIC0 using 2 periods
# Buffers use s32le format, with 48 frame per 1000us on core 0 with priority 0
DAI_ADD(sof/pipe-dai-capture.m4,
	4, DMIC, 0, dmic01,
	PIPELINE_SINK_4, 2, s16le,
	48, 1000, 0, 0)

# capture DAI is DMIC 1 using 2 periods
# Buffers use s16le format, with 320 frame per 1000us on core 0 with priority 0
DAI_ADD(sof/pipe-dai-capture.m4,
	8, DMIC, 1, dmic16k,
	PIPELINE_SINK_8, 2, s16le,
	KWD_PERIOD_FRAMES,
	KWD_PIPE_SCH_DEADLINE_US,
	0, 0)


PCM_CAPTURE_ADD(DMIC01, 99, PIPELINE_PCM_4)
PCM_CAPTURE_ADD(DMIC16k, 8, PIPELINE_PCM_8)

#
# BE configurations - overrides config in ACPI if present
#

# dmic01 (ID: 2)
DAI_CONFIG(DMIC, 0, 2, dmic01,
	DMIC_CONFIG(1, 500000, 4800000, 40, 60, 48000,
		DMIC_WORD_LENGTH(s16le), DMIC, 0,
		# FIXME: what is the right configuration
		PDM_CONFIG(DMIC, 0, FOUR_CH_PDM0_PDM1)))

# dmic16k (ID: 6)
DAI_CONFIG(DMIC, 1, 6, dmic16k,
           DMIC_CONFIG(1, 500000, 4800000, 40, 60, 16000,
                DMIC_WORD_LENGTH(s16le), DMIC, 1,
                PDM_CONFIG(DMIC, 1, STEREO_PDM0)))

## remove warnings with SST hard-coded routes

I just ran the test this way

localhost ~ # time arecord -Dhw:0,99 -r 48000 -c 4 -f S16_LE -d 10 glk-rec48k.wav
Recording WAVE 'glk-rec48k.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4

real	0m11.077s
user	0m0.003s
sys	0m0.038s
localhost ~ # time arecord -Dhw:0,8 -r 16000 -c 2 -f S16_LE -d 10 glk-rec16k.wav
Recording WAVE 'glk-rec16k.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo

real	0m11.076s
user	0m0.002s
sys	0m0.016s

The resulting wav files are attached. Please compare if you can get similar result.
glk-rec-si.zip

Also when inspecting the waveform (subtract channels 1 and 2) the result is all zeros so it confirms our GLK device has only one microphone. The single microphone drives both L and R slots of bus into PDM0 so it appears as stereo or dual mono stream.

@singalsu

@singalsu
There are some misunderstandings between us, the 2ch dmic recording issue is from PCM99. Sorry, I didn't describe it clearly. pcm99 4ch and pcm8 2ch recording devices works with good quality to me also.
Below are the test commands for each device. The songs are the same. For pcm99 2ch, real time is not right.

pcm99 2ch 48k recording

$ time arecord -Dhw:0,99 -f s16_le -c 2 -r 48000  pcm99-2ch-48k.wav -d 10
Recording WAVE 'pcm99-2ch-48k.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

real    0m6.176s
user    0m0.002s
sys     0m0.013s

pcm99-2ch-48k.zip

pcm99 4ch 48k recording

$ time arecord -Dhw:0,99 -f s16_le -c 4 -r 48000  pcm99-4ch-48k.wav -d 10
Recording WAVE 'pcm99-4ch-48k.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4

real    0m10.161s
user    0m0.009s
sys     0m0.013s

pcm99-4ch-48k.zip

pcm8 2ch 16k recording (with your above test topology)

time arecord -Dhw:0,8 -f s16_le -c 2 -r 16000  pcm8-2ch-16k.wav -d 10
Recording WAVE 'pcm8-2ch-16k.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo

real    0m10.264s
user    0m0.005s
sys     0m0.009s

pcm8-2ch-16k.zip

Test recipe:
kernel: sof-dev/44443 + thesofproject/linux#942
sof: glk-012-stable-branch/94e0f0b + pr #1432
tplg: your above test tplg

@singalsu

I just ran the test this way

localhost ~ # time arecord -Dhw:0,99 -r 48000 -c 4 -f S16_LE -d 10 glk-rec48k.wav
Recording WAVE 'glk-rec48k.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4

real	0m11.077s
user	0m0.003s
sys	0m0.038s
localhost ~ # time arecord -Dhw:0,8 -r 16000 -c 2 -f S16_LE -d 10 glk-rec16k.wav
Recording WAVE 'glk-rec16k.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo

real	0m11.076s
user	0m0.002s
sys	0m0.016s

The resulting wav files are attached. Please compare if you can get similar result.
glk-rec-si.zip

Hi @singalsu you haven't run the error test case what keqiao run here:
$ time arecord -Dhw:0,99 -f s16_le -c 2 -r 48000 pcm99-2ch-48k.wav -d 10

@singalsu

@singalsu not sure if that(using only 2 channels doesn't work with DMIC0 which is FOUR_CH_PDM0_PDM1 configured) is under your expectation or not.

@keyonjie

@keyonjie No, the capture channels count cannot be changed after it has been defined in topology. The DAI does not pass the channels count to DMIC driver. If the topology defines the DMIC DAI as 4ch all capture must be 4ch. Isn't it the same with SSPs too?

@keyonjie

@keyonjie No, the capture channels count cannot be changed after it has been defined in topology. The DAI does not pass the channels count to DMIC driver. If the topology defines the DMIC DAI as 4ch all capture must be 4ch. Isn't it the same with SSPs too?

Yes, make sense, the same with SSPs, thank you for confirming.

@keqiaozhang

@keqiaozhang can you help verify if simultaneously capture for 99 and 8 PCM works fine?

@keyonjie

@keyonjie
Confirmed that pcm99-4ch-48k and pcm8-2ch-16k capture can work at same time.

@keqiaozhang

@keqiaozhang Thanks!

@mrajwa

@mrajwa
PR #1432 is landed on master branch. Please help to merge #1446 to glk-012-stable-branch.
They are the same PR but for different branches.

The PR is now merged to glk-012-stable too.

@singalsu

thank you, @singalsu @keqiaozhang

fixed by #1432

Navigation Menu

Repository navigation

[BUG]KWD: DMIC(pcm 99) recording speed is doubled with kwd tplg #1412

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG]KWD: DMIC(pcm 99) recording speed is doubled with kwd tplg #1412

Description

Activity

keyonjie commented on May 14, 2019

singalsu commented on May 14, 2019

singalsu commented on May 14, 2019

keyonjie commented on May 14, 2019

singalsu commented on May 14, 2019

wenqingfu commented on May 14, 2019

singalsu commented on May 14, 2019

keqiaozhang commented on May 15, 2019

singalsu commented on May 15, 2019

singalsu commented on May 15, 2019

2 remaining items

singalsu commented on May 15, 2019

singalsu commented on May 15, 2019

singalsu commented on May 15, 2019

keqiaozhang commented on May 16, 2019

keyonjie commented on May 16, 2019

keyonjie commented on May 16, 2019

singalsu commented on May 16, 2019

keyonjie commented on May 16, 2019

keyonjie commented on May 16, 2019

keqiaozhang commented on May 16, 2019

singalsu commented on May 16, 2019

keqiaozhang commented on May 17, 2019

singalsu commented on May 17, 2019

wenqingfu commented on May 17, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions