-
Notifications
You must be signed in to change notification settings - Fork 349
Description
Describe the bug
The volume control is applied to first two channels for 16 kHz pipeline. The volume control in 48 kHz DMIC capture works OK.
To Reproduce
The output of amixer shows that volume is applied for two channels despite attempt to set four.
$ amixer cset name='Dmic1 2nd Capture Volume' 60,60,60,60
numid=49,iface=MIXER,name='Dmic1 2nd Capture Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=70,step=0
: values=60,60
| dBscale-min=-50.00dB,step=1.00dB,mute=1
In comparison the volume command for Dmic0 looks like next with all four channels set to 60.
$ amixer cset name='Dmic0 Capture Volume' 60,60,60,60
numid=46,iface=MIXER,name='Dmic0 Capture Volume'
; type=INTEGER,access=rw---R--,values=4,min=0,max=70,step=0
: values=60,60,60,60
| dBscale-min=-50.00dB,step=1.00dB,mute=1
Reproduction Rate
Always.
Expected behavior
In above example volume step applied to channels 1-4.
Impact
Annoyance.
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: {SHA}
- SOF: Binary v1.6.1 release
- Name of the topology file
- Topology: sof-hda-generic-4ch.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: Lenovo X1
Screenshots or console output
The audio level on first two channels is higher than last two. They should be nearly the same.
It seems that pipeline macro pipe-eq-iir-volume-capture-16khz.m4 is using a hard-coded channels 2ch map for volume. For 48 kHz it's defined by DMIC_VOL_CH_MAPS. It works for DMIC but will fail if this pipeline is used for any other than DMIC end-point. Also pipe-volume-capture-16khz.m4 has this issue.
