DYNAMIC topology should not be used for pipeline with volatile
Kcontrols.
Hence ensuring the flag is un defined before processing
smart amp related PCM and DAI configs
Suggested-by: Sridharan, Ranjani <ranjani.sridharan@linux.intel.com>
Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com>
Introduce a new component to perform configurable audio post processing
on playback path before smart amplifier.
1. Put google_audio_post_processing libs at $SOF_REPO/third_party/lib
- libgoogle_audio_post_processing.a
- libc++.a
- libc++abi.a
2. Enable google_audio_post_processing in config override
$SOF_REPO/src/arch/xtensa/configs/override
CONFIG_COMP_GOOGLE_AUDIO_POST_PROCESSING=y
3. Build the firmware and tool with xcc
4. To verify it works:
- aplay some audio
- amixer and grep GAPP
- sof-ctl to get/set control
Signed-off-by: Kehuang Li <kehuangli@google.com>
This reverts commit f50b6fe0ad.
I discovered the hard way that this change causes alsatplg version
1.2.2 (the default version in the current LTS Ubuntu) to corrupt just
a few bytes in .tplg output in an incredibly discrete and
time-consuming way: no error message at build time and same file size.
See example at https://github.com/thesofproject/sof/pull/5162.
We could/should just require a minimum alsatplg version at the CMake
level but at this moment we don't even know which minimum version is
needed and we would also need to take some time to test a few alsatplg
versions. If version 1.2.2 would just fail with an decent error
message that can be searched and discussed then everything would be
fine but silent corruption is really not OK.
So users of recent versions will unfortunately have to live with the
huge number of warnings for now.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
All .tplg output files have been compared and are strictly identical
after the change.
The deprecation warnings were added more than one year ago in
https://github.com/alsa-project/alsa-lib/commits//706192341d1d0bbb906
Now that we just upgraded our Docker image to ALSA 1.2.6
(https://hub.docker.com/r/thesofproject/sof/tags) so #5153 can enable
topology v2, the volume of warnings has became unbearable. For instance
good luck trying to find the actual error messages for the build
failures of #5155 - they're totally drowned in these deprecation
warnings.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Comments for calls to PIPELINE_PCM_ADD and DAI_ADD describe parameters
in the same order they are passed to the macros. The only exception is
order of "priority" and "core", and this can be very misleading. In
most cases the actual current values for the two parameters are 0,
making it even easier to make a mistake when modifying them.
Fix the order in the comments to match the actual order in which the
parameters should be passed to PIPELINE_PCM_ADD and DAI_ADD.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
In preparation for Topology2.0, move the current topology files
to the topology1 folder and once the 1.0 topologies are
built copy them to the /sof/tools/build-tools/topology folder.
When Topology2.0 topologies come along, they will be built into
the topology2 folder and the 2.0 binaries will be copied over
the 1.0 binaries.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Sathya Prakash M R