[fredoh9]

Instead of making new files for audio equalizer topology, reuse existing
topology and replace only volume pipeline by macro replacement.

Signed-off-by: Fred Oh fred.oh@linux.intel.com

[fredoh9]

@singalsu can you add your comment this too. Without creating new files, pipeline name is only replaced for maximum reuse.

[lgirdwood]

@fredoh9 now that you are getting up to speed with topology and M4 it would be worthwhile expanding sof-docs with the layout of the files, the includes, how we differentiate etc. We should also include the latest topology pipelines as examples (and can generate the png images using the tool).
@deb-intel - we have a tool that converts topology files to images. Is there some way we can include this in sof-docs and build it from latest git. i.e. have a list of pipelines and images for each pipeline.

[juimonen]

@lgirdwood just as reminder, we can still do graphs with m4 (to dot files) and the docs are here:
https://thesofproject.github.io/latest/developer_guides/topology/topology.html#debugging-topology

[deb-intel]

@fredoh9 now that you are getting up to speed with topology and M4 it would be worthwhile expanding sof-docs with the layout of the files, the includes, how we differentiate etc. We should also include the latest topology pipelines as examples (and can generate the png images using the tool).
@deb-intel - we have a tool that converts topology files to images. Is there some way we can include this in sof-docs and build it from latest git. i.e. have a list of pipelines and images for each pipeline.
@lgirdwood I'm not sure how to do this. I will need to ask Kevin Putnam about this. @intelkevinputnam, can you answer this question?

[intelkevinputnam]

To be clear, are we talking about pulling a topology file (.dot) from the sof repo when building hte sof-docs repo or simply placing the file in the sof-docs repo as seen here: https://thesofproject.github.io/latest/developer_guides/debugability/traces/index.html ?

Here's a source .dot file: https://github.com/thesofproject/sof-docs/blob/master/developer_guides/debugability/traces/images/process-traces.dot

[lgirdwood]

@intelkevinputnam my thinking here is that we process the topology pipeline library files (the building blocks used by all topologies) and some example pipelines into png files that can make up some of our docs. The tools needed for processing are all in the sof repos, so I'm guessing a script could be run as part of make html to generate the png files ?

[intelkevinputnam]

@lgirdwood we can definitely do that or something like it. As it is now, we have to run a few commands in the sof repo before we can build the docs, so it could happen then as well. Whether the script is included in the sof or sof-docs repo, we would need to include running it in the .travis.yml used to deploy the docs.

[xiulipan]

Some advance to make option more generic.

[singalsu]

I made those topologies for testing new components, cleaning them up sounds like a good idea. Though now the topologies in sof/tools/test/topology work in UP2 so these apl topologies for single algorithm are no more needed. So deleting them is also an option.

The processing component pipeline macro names should contain their component names in downstream order like sof/pipe-comp1-comp2-comp3-playback.m4, where compN are e.g. "asrc", "eq-fir", "eq-iir", "src", "volume", etc. E.g. pipe-eq-iir-capture.m4 doesn't contain volume but pipe-eq-iir-volume-capture.m4 does. A pipeline for tuned speaker output could be pipe-eq-iir-eq-fir-volume-playback.m4.

Confusing pipeline macro names like pipe-eq-capture.m4 or pipe-highpass-capture.m4 should be deleted. I'd like pass the processing configuration blobs to compN via PIPELINE_PCM_ADD() macro as shown in enhancement #2535. I tested it successfully in a PR that I closed for other reasons.

Also maybe the capture pipeline macros those are compatible with mute switch should have indication in their name. Or if all can be made compatible that's no more an issue.

There's also issue that we topology tokens and names conflicts for settings, see issue #2534. Changing the characteristic of a pipeline by editing volume tokens or processing blob does not always have impact.

[singalsu]

I'd like to combine this with other topology improvements I've been proposing. Could you include them to this work scope?

[lgirdwood]

@singalsu ack - can you link your PR to this one then @fredoh9 can build on top.

[fredoh9]

@singalsu As my understating is that
#2434 is the pr you mentioned. And I read throught #2535 , #2534 as well. Trying to include PIPELINE_PCM_ADD() update as well. I think I may need to break up some of your suggestions into different PR(s). If I include too much changes, it's hard to make sure no side effects nor hard to get reviewed.

[singalsu]

@fredoh9 Yep, that's the PR where I tested the idea. There's a lot of editing need so several commits or pull requests sound feasible to cover them. The _priv names in processing component blobs need to be aligned too and can be hand-edited. I'll then finally update the tools to produce the hand-edited compatible blob files.

[fredoh9]

@singalsu @xiulipan I handled only PROC change, can you review again?
For additional points Seppo brought up, I plan to submit another PR(s). I have still some questions on them. I don't want to delay too much because of new directions.

[lgirdwood]

SOFCI TEST

[lgirdwood]

@fredoh9 can you check CI

[fredoh9]

@fredoh9 can you check CI

DEVICE_TEST results are pretty normal.
For Internal Intel CI System/merge/build, WHL failed. I couldn't see log file. But this change doesn't affect WHL.

[fredoh9]

SOFCI TEST

[lgirdwood]

@wwittbrx @lbetlej any comments on Internal CI

[fredoh9]

Although Internal Intel CI System/merge/build show "Test failed", there is no error in details. DEVICE_TEST results also pretty normal.

[lgirdwood]

Jenkins known issues.