-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] multiple-pause-resume misses failure due to random wait times #694
Comments
BTW both timeout -k 5 12 aplay -d 10 -bla -blah & aplayPID=$!
# do other things
wait $aplayPID || die "aplay ... failed" # or just set -e, see #312 It's "green failure crime" to ignore the exit status of audio commands in an audio test suite! See See also #312 |
thesofproject/sof#4304 should have been caught earlier with this test |
expressions such as "set sleep_t [expr int([expr rand() * $rnd_range]) + $rnd_min ]" should be used to fuzz the sleep duration. For CI we do want the sleep times to be a predictable pattern with a known/controlled seed that's reset to the same value every time the script is run. Different requirements -> different solutions. |
|
Can't believe it's been nearly a year since we discussed this random seed thing... |
@plbossart on the one hand, using a known seed will be good because the wait times will be pre-determined. But on the other hand, if this known seed causes the failure to be missed, we will always miss this. The problem I pointed out is because of the difference in behaviour when one DMIC PCM is stopped while the other is paused/unpaused. I feel like there's no point is randomizing the wait time at all. |
The explanation is here:
|
Just filed |
Describe the bug
pausing/releasing pipelines with random wait times results in missing the failure with the multiple-pause-resume test.
To Reproduce
Expected behavior
Pausing/release for the second DMIC pipeline after the first pipeline is stopped should work normally
Detail Info
The text was updated successfully, but these errors were encountered: