This removes a lot of warning noise and may help spot other warnings
like `ALSA lib ops.c:48:(lookup_ops) wrong kcontrol ops value string ''`
and others.
Now that commit 1b1ec6c492 ("topology/cmake: skip all topologies when
alsatplg < 1.2.5") enforces alsatplg version >= 1.2.5, it is finally safe
to do this!
I compared the generated .tplg files before/after this commit and
they're bit for bit identical. Tested with alsatplg v2.6.1 from
Ubuntu 22.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
A simplified copy of previous bxt.m4 is made as local
platform/generic.m4 with SSP and other platform definitions
for test topologies build. It is included to test-all,
test-capture, and test-playback macros definitions.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Test pipelines with SRC due internal block processing constraints need
this to avoid fail due to insufficient buffer. Other pipelines continue
to use 2 buffer periods.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.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>
This patch updates the tplg-build.sh script by omitting DMIC capture
test topologies generation, tone topolgies generation due to no
use and no maintenance. They can be fixed later.
The all DAI permutations are generated only for volume pipeline. The
src is removed. Instead a new algorithms topologies generation loop
is added for UP2 (APL) compatible topologies. The algorithms are
ASRC, FIR, IIR, and SRC.
The test-all, capture, playback macros are updated to use
PIPELINE_PCM_ADD and set up DAI for SCHEDULE_TIME_DOMAIN_TIMER. The
duplication of TEST_DAI_PORT in macro call is replaced by 0 to
prevent topology load fail on device.
The test-equalizer-playback-ssp.m4 is removed as obsolete.
Pipelines are added for FIR and IIR playback and capture. SRC playback
pipeline is improved by making tokens instance specific. The SRC
capture pipeline macro is only cosmetically improved.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Enable setting pcm min and max rate from top level m4 pipeline macro.
This way it is possible to configure the whole pipeline to correct
samplerate range in 1 file. Previously you needed to modify the pipeline
macros where the rate was hardcoded. As the frame count is calculated
from pcm/dai rate and scheduling time the frame count is obsolete.
Introduce pipeline rate parameter to help configuring components with
fixed output rate. We can't deduce this from pcm range since for example
src might accept bigger max rate than the following dai. Even though the
parameter is named "pipeline rate" it essentially means the "final"
output rate to which this pipeline is connected to (dai or other
pipeline). In capture pipelines it means the originating fixed dai rate.
Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
Marc Herbert