The previous patch 908876cc5f introduced a bug where the wrong input
buffer had the "consumed" field updated. This affected playing from
_only_ the second input stream in weird ways (specifically, sound was
slower and every other period I'd get a "no bytes to copy" message from
the active host component).
This patch fixes the indexing for that update.
Fixes: 908876cc5f "audio: mixer: Improve handling of inactive input streams"
Signed-off-by: Paul Olaru <email address hidden>
(cherry picked from commit 5da0812a81cb4e9aa64c35a210c68749f5474943)
audio: module_adapter: Ensure prepare always runs on modules
Some components like mixer have special handling of the prepare function
whenever they are already active. Ensure said handling has a chance to
run.
With the old code, that code doesn't run, mixer doesn't have a chance to
return PPL_STATUS_PATH_STOP and the DAI then receives a second prepare
request, which is invalid given that it's already active.
Signed-off-by: Paul Olaru <email address hidden>
Signed-off-by: Daniel Baluta <email address hidden>
(cherry picked from commit 5f26af949428603cb90645a750544cd6b002b42b)
audio: mixer: Improve handling of inactive input streams
The old code does not deal correctly with input streams going away
without everything stopping. This commit ensures only active streams are
considered as mixer input, and the other streams are ignored (considered
zeroed out).
Signed-off-by: Paul Olaru <email address hidden>
Signed-off-by: Daniel Baluta <email address hidden>
(cherry picked from commit 908876cc5f23301fb92bdaffd6d29ecffd950fec)
d36887b...
by
Iuliana Prodan <email address hidden>
mixer: skip inactive source
In case one of the sources is inactive, the avail_frames
for that source is 0 and the frames = 0.
So, later on, there is nothing to copy, even if, at least
one source is still active.
In this case, we get a "write error: Input/output error".
To fix this, allow mixer to process data from at least one
source, if that is active.
Or, in other words, if any source is inactive, skip it.
Signed-off-by: Iuliana Prodan <email address hidden>
Signed-off-by: Daniel Baluta <email address hidden>
(cherry picked from commit ffa8cad7ae750c1ef84d10e84d0fd1ecd1bd5277)
Maybe it's missing when installing with the graphical interface?
This symbolic link is surprisingly enough to make `xt-objcopy` work
_without_ the XTENSA_ variables. But when the variables _and_ the link
are both missing, then `xt-objcopy` fails with the usual error:
```
in current dir: work/current/sof; running command:
XtDevTools/install/tools/RG-2017.8-linux/XtensaTools/bin/xt-objcopy
--remove-section .comment sof/build-tgl/zephyr/zephyr.strip build-sof-staging/sof-info/tgl/stripped-zephyr.elf
Error: there is no Xtensa core registered as the default.
You need to either specify the name of a registered Xtensa core (with
the --xtensa-core option or the XTENSA_CORE environment variable) or
specify a different registry of Xtensa cores (with the --xtensa-system
option or the XTENSA_SYSTEM environment variable).
The following Xtensa cores are available:
hifiep_bd5
cavs2x_LX6HiFi3_2017_8
sample_config
sample_flix
...
```
Fix this failure by simply passing the XTENSA_ variables to xt-objcopy.
Kudos to Seppo Ingalsuo for the interactive debugging session that
allowed root-causing this problem extremely quickly.
Signed-off-by: Marc Herbert <email address hidden>
(cherry picked from commit 3aeb2bfd99b959e89d76f8070d676580b51e5050)
xtensa-build-zephyr: fix DEFAULT_TOOLCHAIN_VARIANT spill on next platf
xtensa-build-zephyr.py has always defined XTENSA_ and other environment
variables in the current environment shared by all platforms. This was
always bad but apparently never a problem until the addition of the new
DEFAULT_TOOLCHAIN_VARIANT (xcc or clang) variable.
Before DEFAULT_TOOLCHAIN_VARIANT, each platform's environment would
simply override the previous one. However with the new
DEFAULT_TOOLCHAIN_VARIANT, the current environment has precedence for
more flexibility. This makes each platform "spill" onto the next one and
`xtensa-build-zephyr.py -p tgl mtl` fail like this:
```
-- Board: intel_adsp_ace15_mtpm
-- Found toolchain: xcc (/home/XCC/install/tools)
CMake Error at zephyr/cmake/compiler/xcc/generic.cmake:9 (message):
Zephyr was unable to find the toolchain. Is the environment
misconfigured?
To fix this, stop modifying the current os.environ and use a new, fresh
os.environ.copy() for each platform instead.
Fixes commit 309fa264e29d ("xtensa-build-zephyr.py: upgraded Xtensa
toolchain for MTL")
History repeats itself: commit 6bedd8e7427c ("xtensa-build-zephyr: fix
RIMAGE_KEY when building multiple platforms") fixed the same logical
error months ago in a different script.
Signed-off-by: Marc Herbert <email address hidden>
(cherry picked from commit 8aab18351fd68d0719541451f35ff8aad7afd523)
c53ddec...
by
Adrian Bonislawski <email address hidden>
ipc4: fix NULL dereference
This will fix NULL dereference in ipc4_process_chain_dma()
Signed-off-by: Adrian Bonislawski <email address hidden>
(cherry picked from commit 1319163ea2c6d8bea6fd7189dea6275ac5e34bf5)
Signed-off-by: Kai Vehmanen <email address hidden>
dai-zephyr: possible division-by-zero if max_block_count is zero
If the max_block_count attribute is zero, this may lead to
division by zero error. Handle this explicitly but reporting
error if max_block_count is zero.
Signed-off-by: Kai Vehmanen <email address hidden>
(cherry picked from commit 82ae105de9e20d3a8c27805d971e1d78eeabfa7f)
