You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running the multi pipeline tests for capture, the test picks all the possible capture devices and if thats less than the max count allowed, the remaining ones are filled up with playback pipelines. That is a bit misleading. This becomes a different test than just multiple-pipeline-capture then. Not sure if multiple-pipeline-playback does something similar.
If the number of capture pipelines are less than max count, the test should process with just those.
If the number of capture pipelines are less than max count, the test should process with just those.
This sounds like a simple enough change, could you do it? Warning: it could conflict with some work in progress in this file, notably #497. Maybe wait until #497 is done. Also : good habit to have a quick look at shellcheck -x output before starting to code.
This sounds like a simple enough change, could you do it? Warning: it could conflict with some work in progress in this file, notably #497. Maybe wait until #497 is done. Also : good habit to have a quick look at shellcheck -x output before starting to code.
The change is simple but I dont want to lose the current multiple-pipeline-capture test either. it is a perfectly valid test with multiple-pipeline-playbackandcapture test. So we should keep this and create a new test for a simple multi capture test
So we should keep this and create a new test for a simple multi capture test
I just put multiple-pipeline-playback and multiple-pipeline-capture side by side for the first time and realized the unbelievable amount of copy/paste/diverge :-(
Activity
marc-hb commentedon Nov 10, 2020
This sounds like a simple enough change, could you do it? Warning: it could conflict with some work in progress in this file, notably #497. Maybe wait until #497 is done. Also : good habit to have a quick look at
shellcheck -xoutput before starting to code.ranj063 commentedon Nov 10, 2020
The change is simple but I dont want to lose the current multiple-pipeline-capture test either. it is a perfectly valid test with multiple-pipeline-playbackandcapture test. So we should keep this and create a new test for a simple multi capture test
marc-hb commentedon Nov 11, 2020
cc: @fredoh9
I just put multiple-pipeline-playback and multiple-pipeline-capture side by side for the first time and realized the unbelievable amount of copy/paste/diverge :-(
plbossart commentedon Nov 17, 2020
this needs to be addressed. We have recurring failures for cases that rely on mixers
https://sof-ci.01.org/linuxpr/PR2565/build4887/devicetest/?model=BSW_CYN_MAX98090&testcase=multiple-pipeline-capture
https://sof-ci.01.org/linuxpr/PR2565/build4887/devicetest/?model=APL_UP2_NOCODEC&testcase=multiple-pipeline-capture
And those two are completely unrelated to capture...
marc-hb commentedon Nov 18, 2020
The second, APL_UP2_NOCODEC failure is a test regression I just introduced in #497, apologies and tentative fix in #521. Please help review.
The BSW_CYAN_MAX98090 looks different.
marc-hb commentedon Jun 22, 2023
@ranj063 , was this fixed by @fredoh9 in commit 41c1427? If yes then please close.
marc-hb commentedon Jan 2, 2024
@ranj063 , good to close?