suspend/audio_after_suspend fails very easily
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Checkbox |
Invalid
|
High
|
Unassigned |
Bug Description
A system whose audio subsystem doesn't come back from suspension is considered to be pretty faulty. Thus, in principle, the suspend/
In practice, I've found a few systems whose mixer settings get muted and/or changed after a resume (Dell Inspiron 1545). Since this test simply compares the output of amixer before and after the suspend cycle, any changes to the mixer settings themselves, irrespective of whether audio actually works or not, will make this test fail.
The Inspiron 1545 works fine after suspend, as long as one remembers to unmute the audio. So I'm not sure that the test should fail under this circumstance.
Maybe the audio_*_suspend tests should attempt to force a particular mixer setting and then check that it was honored both before and after suspension. This would also make the subsequent record_
Changed in checkbox: | |
status: | New → Confirmed |
Changed in checkbox: | |
milestone: | none → 0.13 |
Thanks for the confirmation, I'll set this to High since it's quite a big deal that such a small test can make a core component's tests be marked as failed.