-
Notifications
You must be signed in to change notification settings - Fork 59
Test-case: Add check volume levels #410
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
Test-case: Add check volume levels #410
Conversation
d25cc21 to
60e4330
Compare
|
Update: I changed echo commands to dlogi and dloge. |
60e4330 to
60aa062
Compare
|
Fixed environment variable declarations / exports. |
60aa062 to
3fe0934
Compare
|
For fun I added it to run-all-tests.sh. It will fail on most devices due to no Octave installed. Also the nocodec topologies do not create the required mute switch control. I'll do a separate SOF PR for it. |
84956de to
fa8a4cd
Compare
|
@marc-hb Thanks for all the help! I've tried to address all your comments now. Though there are two cases where I'm not yet sure the approach is the best one. I'll still add to Octave part channels filtering for center frequencies. It will catch then also channels swaps. Also I'll test adding ramp length verification for the 0-100% transitions. Can this be merged to sof-test as non-enabled test (while need for Octave)? |
marc-hb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience, I think we're getting very close with the shell script. Need someone to review the matlab code and logic.
fa8a4cd to
b9fe1c0
Compare
|
This test code needs sof-test PR #417 to not fail with channel count and device strings and SOF PR thesofproject/sof#3509 to have needed full-blown volume component controls instantiated. |
b9fe1c0 to
63f7df0
Compare
63f7df0 to
f3a1108
Compare
marc-hb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe no one reviewed the Octave code yet :-( Who could do this?
I would be very worrying if we have only one person who can review Octave code, maybe we shouldn't even be using Octave in validation in that case! :-((
This test code needs sof-test PR #417 to not fail with channel count and device strings and SOF PR thesofproject/sof#3509 to have needed full-blown volume component controls instantiated.
I still have a few minor comments but the shell script looks basically ready to me. However considering this test cannot run in CI (yet), we need IMHO evidence of at least one person other than the submitter who could run the test. It doesn't even have to pass, just to run and produce some meaningful audio results anywhere but on the submitter's system. I tried it last week but I couldn't run it on my platform in a reasonable time, not even with some local modifications/hacks. @singalsu should I wait until thesofproject/sof#3509 is merged before trying again?
|
https://sof-ci.01.org/softestpr/PR410/build251/devicetest/ experienced a device failure on BSW_CYN_MAX98090 |
|
@singalsu I am trying to run your test case on TGL nocodec, it fails as it has no 'Switch' kcontrol there, which tplg I should use to run it? |
f3a1108 to
56f6144
Compare
|
@keyonjie There's need for thesofproject/sof#3509 to add the missing switch controls. |
marc-hb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The shell script looks good to me. Before merging I think this still needs:
- at least one other person who could run this (even if the tests don't pass)
- someone to review the Octave code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for the octave code
xiulipan
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add a check for octave in test case first to avoid accidently run fail for this case.
I think this could be useful later once we want to run this in automation but we would like to merge it earlier than that. For now I believe we still don't have any report yet of any other person besides the author who could run it manually. |
0c8c0c8 to
bf81226
Compare
bf81226 to
2005a99
Compare
xiulipan
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, let's try to do some integration with CI framework.
keyonjie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the case, it looks professional with good coverage on the volume level.
For the pipeline coverage, it only change volume/switch for the capture one, is it worth to add these to playback pipeline also?
test-case/check-volume-levels.sh
Outdated
| } | ||
|
|
||
| pause () { | ||
| dlogi "Pausing" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The wording "pause" is somewhat confusion, we are not aim to pause any playback/capture stream, maybe 'sleep_1s'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test script really pauses execution so I prefer this. Just sleep is a reserved word and don't want to hard code with the name the length to 1s. It could be adjusted later to more than 1s for better accuracy or less than 1s for lower test time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nap() ? :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, either 'nap' / 'nop' or 'idle' sound better to me, or even exec_pause(), as we have test cases naming xxx_pause_release_xxx, I thought we are pausing the playback/capture pipeline at my first glance to the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nap sounds good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed
tools/check_volume_levels.m
Outdated
| fprintf(1, 'PASS\n'); | ||
| else | ||
| fprintf(1, 'FAIL\n'); | ||
| exit(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall we remove those 2 'exit(1)' as they are making my octave hang when running it with gui mode, logging errors should be enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This script is not for GUI mode but for batch processing. For interactive tests with GUI I've commented out those lines. The GUI doesn't hang but it quits with exit().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not aware of simple ways in script to check if we are in Octave GUI. If such exist we could make a custom exit function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This script is not for GUI mode but for batch processing.
It would be great to find a solution that supports both but waiting for that should IMHO not block this "automation" PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The shell script thinks a failed test passed if I omit the exit(1).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, got you now @singalsu
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The shell script thinks a failed test passed if I omit the exit(1).
Thanks @singalsu for "testing the test code" and making sure it can report failures. I found this to be incredibly rare in this project.
After only 2 minutes googling (sorry) I found "error()", did you try it? https://octave.org/doc/v4.0.1/Raising-Errors.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I'm using error() a lot to stop script execution but I haven't used to return code to shell. I'll see if it works. It doesn't quit the GUI like exit does. If it it works, it's more convenient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, yes it works for the purpose! I'll switch to error().
marc-hb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't work for me sometimes,
Considering this test is not enabled in automation yet, working "sometimes" for at least one person besides the submitter is IMHO enough "validation". Merging it will make fixing it easier.
test-case/check-volume-levels.sh
Outdated
| } | ||
|
|
||
| pause () { | ||
| dlogi "Pausing" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nap() ? :-)
|
jf-icl-rvp-hda-4 boot failed in https://sof-ci.01.org/softestpr/PR410/build274/devicetest/ |
keyonjie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, we can add incremental fixes if minor issues existed.
This patch adds a shell script to check that SOF volume component related system applies correctly channels gains and mute switches. The script determines the volume gains from measured sine wave levels and compares to used amixer control values. The test can be executed with a nocodec topology where SSP ports are connected to play -> capture loopback. The loopback avoids need for noise sensitive acoustical test or more complex electrical test. An error is issued if the gains deviate more than used +/- 0.5 dB tolerance. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
2005a99 to
575bd7b
Compare
|
I did the proposed and agreed updates. In addition I added a verbose flag to level check function to prevent additional reports of incorrect level printed while the script tries if swapped channels and swapped controls would pass. I always test the changes with manual add of error to controls or measurements side to see I get the pass and fail correctly. |
marc-hb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, we can add incremental fixes if minor issues existed.
+1 considering this doesn't run in CI yet.
| exit 2 | ||
| fi | ||
|
|
||
| test -n "$(command -v octave)" || { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simpler and logging the location
type octave || {
...
}There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know that, it's very compact but not very intuitive. If you are OK to re-review I can change this.
This patch adds a shell script that measures volume levels
to compute gains when executed with a nocodec topology where
SSP ports are connected to play -> capture loopback.
The measured gains are compared against test procedure and
error is issued if the gains deviate more than tolerance.
Signed-off-by: Seppo Ingalsuo seppo.ingalsuo@linux.intel.com