Improve the alsa_record_playback_automated test for hearing protection

[Po-Hsu Lin]

As you may hear the high pitching beep sound during our daily stand-up meeting, it was came from the alsa_record_playback_automated and suspend/record_playback_after_suspend test.

I think it will be great to improve this test case for our QA colleagues.
It's not a pleasant thing if you need to sit in the lab and hear that beep sound for many times, which is designed for the machine itself, not human.

Or we can remove it from the manual test plan, as we have already ask testers to check the audio input / output capability, and leave it as-is for automated test plans like SRU.

[Daniel Manrique (roadmr)]

The frequency can be changed to something less painful. The one we're using was chosen because it seemed to be pretty reliable, but lower frequencies will be friendlier to the ears.

You could run the audio_test with -f and experiment with values to see what works. The one we're using is 5035Hz. I would suggest choosing a value and trying it several times to ensure detection is reliable with that value, once you find one you like, can add the -f parameter to the job definitions or even change it in the script itself (DEFAULT_TEST_FREQUENCY parameter).

[Pierre Equoy (pieq)]

I'm not sure if this test is useful in a manually controlled environment (i.e. when test is done by a QA engineer), as there are already manual tests in place to ensure both microphone input and headphone outputs work correctly.

There, I would +1 Sam's suggestion to remove these tests from the test plans used by QA engineers or by Cert engineers (but we would keep them for SRU test plans).

[Jerry Kao (jerry.kao)]

I am not sure the purpose of this test. If it is for functionality of internal microphone and speaker, it should already be covered by other test cases (ie alsa_record_playback_internal, playback_auto)
I agree to remove it if there is no other specific test purpose.

[Pierre Equoy (pieq)]

I pushed a fix for the OEM providers (it will be available next time we do a release).

I also did a merge proposal for the Certification provider, it is available here:

https://code.launchpad.net/~pierre-equoy/plainbox-provider-canonical-certification/+git/plainbox-provider-canonical-certification/+merge/292606