volume-basic-test.sh: don't skip "playback volume" controls

[marc-hb]

Superseded by PR #1193.

Looking for "PGA" is not enough.

Other minor fixes.

cc:

• check-pause-resume: handle volume MAX output in expect #931

[marc-hb]

just a draft for now, reset_sof_volume would have to be fixed too. Maybe also check-volume-levels.sh and some other test.

[marc-hb]

Houston, we have a problem
https://sof-ci.01.org/softestpr/PR1068/build502/devicetest/index.html

cmd: TPLG=/lib/firmware/intel/avs-tplg/sof-adl-nocodec.tplg MODEL=ADLP_RVP_NOCODEC_IPC4ZPH ~/sof-test/test-case/volume-basic-test.sh
====================
framework load: ssh ubuntu@sh-adlp-rvp-nocodec-01.sh.intel.com 'nohup bash -c "TPLG=/lib/firmware/intel/avs-tplg/sof-adl-nocodec.tplg MODEL=ADLP_RVP_NOCODEC_IPC4ZPH ~/sof-test/test-case/volume-basic-test.sh 2>&1 | nc -N 10.54.29.142 50659" >/dev/null &'
====================
framework run: 'netcat -l -k 50659'
====================
2023-06-27 00:38:35 UTC [REMOTE_INFO] ktime=661 sof-test PID=8285: starting
2023-06-27 00:38:35 UTC [REMOTE_INFO] /home/ubuntu/sof-test/test-case/volume-basic-test.sh will use topology /usr/lib/firmware/intel/avs-tplg/sof-adl-nocodec.tplg to run the test case
2023-06-27 00:38:35 UTC [REMOTE_INFO] Pipeline list to ignore is specified, will ignore 'pcm=HDA Digital' in test case
2023-06-27 00:38:35 UTC [REMOTE_INFO] Run command to get pipeline parameters
2023-06-27 00:38:35 UTC [REMOTE_COMMAND] sof-tplgreader.py /usr/lib/firmware/intel/avs-tplg/sof-adl-nocodec.tplg -f 'type:playback' -b ' pcm:HDA Digital' -s 0 -e
2023-06-27 00:38:35 UTC [REMOTE_INFO] Starting /usr/local/bin/mtrace-reader.py
2023-06-27 00:38:35 UTC [REMOTE_COMMAND] aplay -D hw:0,0 -c 2 -r 48000 -f S16_LE /dev/zero &
Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
numid=11,iface=MIXER,name='eqiir.14.1 DMIC0 capture Iir Eq'
numid=1,iface=MIXER,name='gain.1.1 Pre Mixer Port0 Playback Volume'
numid=10,iface=MIXER,name='gain.13.1 DMIC Raw Capture Volume'
numid=12,iface=MIXER,name='gain.17.1 Post Demux Port0 2nd Capture Volu'
numid=13,iface=MIXER,name='gain.18.1 Post Demux DMIC SFX1 Capture Volu' <======== truncated !!!
numid=14,iface=MIXER,name='gain.19.1 Pre Demux DMIC SFX1 Capture Volum'
numid=2,iface=MIXER,name='gain.2.1 Post Mixer Port0 Playback Volume'
numid=15,iface=MIXER,name='gain.20.1 Post Demux DMIC SFX2 Capture Volu'
numid=4,iface=MIXER,name='gain.3.1 Pre Mixer Port1 Playback Volume'
numid=5,iface=MIXER,name='gain.4.1 Post Mixer Port1 Playback Volume'

EDIT: all the (new!) tests passed in cavs25 https://sof-ci.01.org/softestpr/PR1068/build502/devicetest/index.html

[ranj063]

@marc-hb I am wondering if it makes ense to filter the mixer controls at all based on the name. Why not test all of them. This will mean we end up testing those that aren't created from our topology but I suppose that should be fine. @plbossart what do you think?

[marc-hb]

cavs25 still passing volume-basic-test.sh in https://sof-ci.01.org/softestpr/PR1068/build560/devicetest/index.html

volume-basic-test.sh still not part of the ACE test plan in https://sof-ci.01.org/softestpr/PR1068/build562/devicetest/index.html

stable-v2.2 https://sof-ci.01.org/softestpr/PR1068/build561/devicetest/index.html all green.

[plbossart]

@marc-hb I am wondering if it makes ense to filter the mixer controls at all based on the name. Why not test all of them. This will mean we end up testing those that aren't created from our topology but I suppose that should be fine. @plbossart what do you think?

I don't know if it's possible for topologies that include an EQ and bytes control, where you need to know what to write in the binary data.

[marc-hb]

SOFCI TEST

[marc-hb]

Why not test all of them.

You need to filter on "something", you can't set the volume of "Playback Channel Map" or of
a Mute switch.

How about testing all the controls which have a dBscale-min? Would that make sense?

EDIT: some answers in related:

• [WIP][RFC] Test-case: Set PGAs to unity gain in script check-alsabat.sh #437 (comment)

[marc-hb]

Superseded by PR #1193.

Discuss in issue #1069.