Repository navigation
[BUG]Regression. MixInMixOut. Silent in captured files #7072
Description
Describe the bug
TEST DESCRIPTION:
Transfer data with Mix In -> maximum number of MixOuts test as host-host loopback.
MixIn -> multiple MixOuts is used in Linux topology.
Tested Topology:
+----+ +--------------------+ +--------------------+
| | | +------+ +-----+ | | +------+ +------+ | 1
| |--->|Copier|-->|MixIn|---+-->|MixOut|->|Copier|--------->+
| | | +------+ +-----+ | | | +------+ +------+ | |
| | +--------------------+ | +--------------------+ |
| | | |
| | | ... |
| | | |
| | | +--------------------+ |
| | | | +------+ +------+ | N |
| | +-->|MixOut|->|Copier|----->| |
| | | +------+ +------+ | | |
|HOST| +--------------------+ | |
| | | |
| | N | |
| |<--------------------------------------------------- | |
| | |
| |... |
| | |
| | 1 |
| |<-------------------------------------------------------+|
| |
| |
+----+
_____________________
TEST STEPS:
1. Load FW
2. Generate playback file
3. Build topology
4. Run all pipelines concurrently
5. Wait for playback stream to finish
6. Stop all pipelines concurrently
8. Verify recorded files
_____________________
ACCEPTANCE CRITERIA:
· No errors during test
· Successful output files verification
To Reproduce
pytest -s "tests/avs/fw_01_base_fw_modules/test_18_mixers_topologies.py::TestMixinMixout::test_01_18_mixers_max_outputs[channel_count_8-mixout_count_3]"
Reproduction Rate
100%
Impact
After Bisect:
Last passed: SOF_FW_MASTER_01.01.00.4022 (https://quickbuild.igk.intel.com/build/11180522) 2023-01-05 23:31:54
First failed: SOF_FW_MASTER_01.01.00.4025 (https://quickbuild.igk.intel.com/build/11184576) 2023-01-06 23:31:34
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: {SHA}
- SOF: [SOF_FW_MASTER_01.01.00.4059
- Name of the platform(s) on which the bug is observed.
- Platform: MTL RVP
Screenshots or console output
logsmixer.zip
Activity
wszypelt commentedon Feb 10, 2023
@ranj063 Can you look at this bug? I think it could be your changes
mengdonglin commentedon Mar 13, 2023
@wszypelt Can you please clarify which commit introduced this regression?
There are updates on module adapter and Zephyr:
Last Passed: https://quickbuild.igk.intel.com/build/11180522/log
First Failed: https://quickbuild.igk.intel.com/build/11184576/log
wszypelt commentedon Mar 13, 2023
@mengdonglin Okay, I'll try to clarify which commit introduced this regression
kv2019i commentedon Mar 13, 2023
MTL only, moving to v2.6
wszypelt commentedon Mar 14, 2023
@mengdonglin
@abonislawski already found the exact commit that causes this: fba35b1
lgirdwood commentedon Mar 14, 2023
@ranj063 can you check, looks like we are not copying data for capture.
wszypelt commentedon Apr 21, 2023
@ranj063 any update?
8 remaining items
lgirdwood commentedon May 11, 2023
@ranj063 @fredoh9 any update ?
ranj063 commentedon May 25, 2023
@mszleszy Thanks for the update. I will look into it today
ranj063 commentedon May 25, 2023
@mszleszy I created a topology with 2 mixouts connected to the mixin in the capture path as below and capture still works OK on Linux. I cannot create a host_copier->mix->mixout->host_copier on Linux as it just wont work.
Oh the only SOF PR I needed to get this working was:
mszleszy commentedon May 30, 2023
@ranj063
Unfortunately still having repro of the issue . I'm adding more details below
I took fw binary directly from 7693 PR.
When MixIn sinks end up on same MixOut module audio worked pretty well.
But couldn't get same results on MixIn into two MixOut->hostCopier
For final confirmation I used additional i2s loop:
Still when using one sink I have proper data, after binding module to MixIn second sink, I have only zeros on all output pins
ipc.log
mszleszy commentedon Jun 5, 2023
Just a short update of the situation. So in my opinion problem still exists, and here are some details:
I was able to get audio from topology with two sinks. Looks like the key is order of pipeline in MultiPipelineState ipc payload.
pipelines id are similar to graph in my last comment. (so starting from pipeline connected to last sink, then pipeline connected to pin 0 and pipeline with MixIn at the end). when using order [0, 1, 2] I have only zeros in output stream.
btw. Test are suing sync_stop_start=0x1 that suggests starting on the same time.
described walkaround does not work when using three sinks on MixIn (all capture pipelines recording only zeros)
mszleszy commentedon Jun 6, 2023
another update:
After #7746 I'm able to run all possible MixIn counts but if MultiPipelineSetState has payload order as described in last comment.
When running MixIn pipeline first and have 2 or more MixIn sink, I'm recording only zero samples.
I can change tests but I'm a bit afraid that I'll hide possible bug so need some architecture consultation
pblaszko commentedon Jun 12, 2023
Order of starting pipelines should not cause permanent problem with signal. Driver may start pipelines in various order.
lrudyX commentedon Oct 3, 2023
No longer reproduces
