[BUG][CML] No data is recorded via DMIC pipeline after it being first muted and then resumed

Describe the bug
run arecord via dmic pipeline with -vvv parameter in one terminal, you should see the max peak change, open another terminal, and run alsamixer, adjust dmic volume from initial value to zero, wait a moment (>10 second), adjust dmic volume to its initial value. the max peak never changes, and stay zero. check recorded wave file, no data even after volume resumed. check sof-logger, and change dmic volume with alsamixer, you can see volume change still works. check dmesg, no error found.
Note: initial volume of dmic should not be zero, for me, I use 50

To Reproduce

reboot system with sudo reboot
open two terminal T1 and T2
run alsamixer in T1, and make sure dmic volume is not zero
play some music or make some sound for dmic to record
run arecord -Dhw:0,6 -f s32_le -r 48000 -c 2 -i -vvv ./1.wav in T2
change dmic volume to zero with alsamixer in T1
wait for a while (> 10s) (sometimes even don't need to wait)
change dmic volume to it's initial value with alsamixer in T1

Reproduction Rate
should be easy to reproduce

Expected behavior
record via dmic should have data after volume resumed

Environment

Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: {Sof-dev: 709427e}
- SOF: {Master: 0205c95}
Name of the topology file
- Topology: {sof-hda-generic-2ch.tplg}
Name of the platform(s) on which the bug is observed.
- Platform: {CML notebook with ALC3204 HDA codec}

Screenshots or console output

dmesg_dmic.log
sof-logger_trace.log

Note this Machine has two DMICs, one is 2ch 48K, the other is 2ch 16K, only the 2ch 48K DMIC has this issue.

Issue can't reproduce on sof-dev(3c39107) + v1.3 and sof-v5.0(32c6c62) + v1.3
recipe as below:

Kernel: https://github.com/thesofproject/linux/commits/topic/sof-dev 3c39107
Kernel: https://github.com/thesofproject/linux/commits/release/sof-v5.0 32c6c62
FW: https://github.com/thesofproject/linux-firmware/tree/master/intel/sof/cml/intel sof-cml-v1.3-0f73628.ri rename to sof-cml.ri
Platform: CML notebook with ALC3204 HDA codec

@dengyangchao

@dengyangchao can you run the following before and after the volume change and see if the values are correct:
"amixer contents | grep -i dmic -A2"
you should see dmic volumes and switches,,,

@juimonen

@juimonen Catch the value before and after volume change

ubuntu@ubuntu-cml-hda-5490:~$ amixer contents |grep -i dmic -A2
numid=48,iface=MIXER,name='Dmic0 Capture Switch'
  ; type=BOOLEAN,access=rw------,values=2
  : values=on,on
numid=47,iface=MIXER,name='Dmic0 Capture Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=70,step=0
  : values=50,50
--
numid=50,iface=MIXER,name='Dmic1 Capture Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=70,step=0
  : values=50,50


ubuntu@ubuntu-cml-hda-5490:~$ amixer contents |grep -i dmic -A2
numid=48,iface=MIXER,name='Dmic0 Capture Switch'
  ; type=BOOLEAN,access=rw------,values=2
  : values=on,on
numid=47,iface=MIXER,name='Dmic0 Capture Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=70,step=0
  : values=29,29
--
numid=50,iface=MIXER,name='Dmic1 Capture Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=70,step=0
  : values=50,50

@dengyangchao

@dengyangchao so the last log is after you changed the volume back? so it stays in 29 even though it should be in 50 (original value)?

@dengyangchao

@dengyangchao so the last log is after you changed the volume back? so it stays in 29 even though it should be in 50 (original value)?

@juimonen No, the log just showed before change the value and after change, i also tried to change the value back,
and via command"amixer contents | grep -i dmic -A2", dmic value are correct.

@dengyangchao

@dengyangchao ok. the logger log looks ok, I was thinking if the mute is for some reason turned on with volume going zero, but that doesn't seem to be the case. Only thing I see is the volume taking bigger values in the end than the initial 2exp16... @singalsu are the big volume values in the end of log acceptable or is it possibly overflowing or something similar?

@juimonen

@juimonen The topology defines capture volume scale up to 20-30 dB I recall, so the values greater than 65536 (equals 1.0 or 0 dB) are normal unless the topology defined the scale only up to 0 dB.

The alsa .conf file is as far as I know flat without hierarchy so need to make sure the things like tokens are with unique identifiers (e.g. append pipeline ID if there's only volume instance in a pipeline) to avoid some other volume instance to override settings for other. Alsatplg does not abort to error when compiling if there are competing "definitions" for things.

@singalsuo the dsp logger log attached shows that the volume down and up are going / should go to the same widget id... so for some reason we have flat output?

Also strange why the about 10s wait is needed for this issue to trigger. I have't tried this yes myself but will do. I've tested a lot with volume recently due to improving the volume ramp forcing PR but I've been only quickly changing volume without the wait.

I'm able to repeat this issue too.

I was able to fix this, doing a PR. The mute/unmute functions need to use volume_set_chan() to alter tvolume.

@aiChaoSONG

@aiChaoSONG can you please test if PR #2196 fixes this for you.

@singalsu

@singalsu After applied #2196 , issue can't reproduce.
platform: CML notebook with ALC3204 HDA codec

@dengyangchao

@dengyangchao Nice, thanks for testing! It would be good to have an automated test script for applying the controls in idle before and during streaming to measure the rec/play level vs. applied control. The logic in handling volume and mute controls is getting quite complex. I tried myself to test various cases but likely still without 100% coverage. E.g. very frequent controls applying before a previous ramp has completed is hard to test manually.

Issue can't be reproduced, since #2196 has been merged, close.

Navigation Menu

Repository navigation

[BUG][CML] No data is recorded via DMIC pipeline after it being first muted and then resumed #2165

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG][CML] No data is recorded via DMIC pipeline after it being first muted and then resumed #2165

Description

Activity

aiChaoSONG commented on Dec 4, 2019

dengyangchao commented on Dec 10, 2019

juimonen commented on Dec 10, 2019

dengyangchao commented on Dec 10, 2019

juimonen commented on Dec 10, 2019

dengyangchao commented on Dec 10, 2019

juimonen commented on Dec 10, 2019

singalsu commented on Dec 10, 2019

juimonen commented on Dec 10, 2019

singalsu commented on Dec 10, 2019

singalsu commented on Dec 11, 2019

singalsu commented on Dec 11, 2019

singalsu commented on Dec 11, 2019

dengyangchao commented on Dec 12, 2019

singalsu commented on Dec 12, 2019

dengyangchao commented on Dec 16, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions