Remove sof-test dependency on topology file, use /proc instead

[marc-hb]

From @ranj063

@plbossart @aiChaoSONG @marc-hb this PR (#430) is in the right direction. I think we should decouple sof-test from the topology file even when testing with the SOF driver and use the procfs info for the card/pcm info and even for the topology graph using the asoc dapm info. This will also make sure that we dont have assumptions about the default card number. What do you think?

[marc-hb]

From @plbossart

Agree that if we can use the /proc info then we have all the information needed for tests with PCM devices.
For probes it's actually the only solution since we expose a compressed interface that will never be shown in the topology but will be shown in the card properties (if it's not show it's a bug). The probes are like 'blue wires', they are not set in stone and not shown in the topology.

Having the topology would only help to show the graph as an information but would not have an functional input into the tests.

[marc-hb]

Agree that if we can use the /proc info then we have all the information needed for tests with PCM devices.

PR #430 has the following code:

for pcm in card_info['pcm']:
                # There are limited pipeline parameters in the proc file system,
                # add some default parameters to make use of sof-test for legacy HDA test
                pcm['fmt'] = 'S16_LE'
                pcm['fmts'] = 'S16_LE S24_LE S32_LE'
                pcm['rate'] = '48000'
                pcm['channel'] = '2'
                pcm['dev'] = 'hw:{},{}'.format(card_id, pcm['id'])

@ranj063 , @plbossart Is this not actually needed for testing?

BTW Auxiliary devices in SOF break SOFCARD #466 seems related.

EDIT, somewhat related check-alsabat.sh: remove use of plughw #241

[aiChaoSONG]

@marc-hb For SOF test, we have to depend on topology. Because we cannot get the information from proc, eg:

• We can't identify WoV pipeline/Echo Reference pipeline/DSM pipeline from proc, which need special test case for the feature.
• We can't get component parameters from proc, eg: SOF_TKN_VOLUME_RAMP_STEP_TYPE SOF_TKN_VOLUME_RAMP_STEP_MS

[xiulipan]

Agree that if we can use the /proc info then we have all the information needed for tests with PCM devices.

PR #430 has the following code:

for pcm in card_info['pcm']:
                # There are limited pipeline parameters in the proc file system,
                # add some default parameters to make use of sof-test for legacy HDA test
                pcm['fmt'] = 'S16_LE'
                pcm['fmts'] = 'S16_LE S24_LE S32_LE'
                pcm['rate'] = '48000'
                pcm['channel'] = '2'
                pcm['dev'] = 'hw:{},{}'.format(card_id, pcm['id'])

@marc-hb right, you have found the limitation for the proc info. This is the workaround code to provide a fake PCM capability (hw_params) to the PCMs from proc. In TPLG, we can get those info by parse the binary.
When you try to cat the hw_params info from a PCM in proc, you will only get

/proc/asound/card0/pcm0c/sub0$ cat hw_params
closed

Another gaps we have with proc info is that we could not get the info about the comps in pipeline for the PCM. Some test case is designed for special COMP (eg: MUX, EQ, WOV). So I think we can use proc as a fallback, but we could not relay on the proc info for our test.

[ranj063]

Another gaps we have with proc info is that we could not get the info about the comps in pipeline for the PCM. Some test case is designed for special COMP (eg: MUX, EQ, WOV). So I think we can use proc as a fallback, but we could not relay on the proc info for our test.

@xiulipan what are we missing for these special comps that we read from topology?

[ranj063]

@marc-hb For SOF test, we have to depend on topology. Because we cannot get the information from proc, eg:

• We can't identify WoV pipeline/Echo Reference pipeline/DSM pipeline from proc, which need special test case for the feature.

@aiChaoSONG wov is always the DMIC16k device. For DSM, the speaker PCM device will have the same name for the feedback pipeline and for echoref, the pipeline is simply called echo. What more info do we need from tplg?

[ranj063]

• We can't get component parameters from proc, eg: SOF_TKN_VOLUME_RAMP_STEP_TYPE SOF_TKN_VOLUME_RAMP_STEP_MS

What do we use these for?

[aiChaoSONG]

@ranj063 I think below useful information cannot be extracted from proc, either.

• rate, channel count and supported formats, need to query with alsa API.
• SOF_TKN_VOLUME_RAMP_STEP_MS: this defines the duration of the volume ramp in a PGA, which is useful in volume test
• PCM/pipeline <-> PGA mapping,

wov is always the DMIC16k device
Yes, But the reverse may not be true, right? should we run WoV test on all devices with DMIC16k, even it may not act as WoV pipeline? We do have such device with DMIC16k, but without WoV support.

[xiulipan]

@ranj063 @aiChaoSONG I think /proc info only is not enough to get similar info as TPLG parser can do.
We may need to use ALSA API to query the info (eg: aplay --dump-hw-params), we can do some experiment later to see if this would work in most case and get correct info for the test.

If above steps can work, TPLG reader can still be kept for PCM info validation test and some audio quality test that may need detailed configuration value.

[plbossart]

@xiulipan even for legacy HDaudio it's much better to query the capabilities instead of hard-coding 48kHz as suggested.

That said you are not going to do a volume test or PCM/pipeline->PGA mapping for legacy HDaudio, so we probably need to move to a mode where the topology is only used when absolutely needed, instead of being the source of all information.

[xiulipan]

@plbossart I think I have made some alignment with @ranj063 @aiChaoSONG to have a feature to read /proc or query from ALSA API to get the correct PCM info. But this will take time to make sure the read out info is trustful and won't break SOF FW before we start the test.

reference to get those info by API:

• https://chromium.googlesource.com/chromiumos/platform/audiotest/+/master/alsa_conformance_test.md
  alsa_conformance_test -P hw:0,0 --dev_info_only
  https://chromium.googlesource.com/chromiumos/platform/audiotest/+/refs/heads/master/alsa_conformance_test/alsa_conformance_helper.c#169

• aplay --dump-hw-params

• https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html

[aiChaoSONG]

some parameter can only be extracted from topology, so a full replacement is impossible, but for platforms use legacy HDA drivers like RKL-S, we can run sof-test on there platforms by reading /proc. close? @marc-hb