suspend/audio_after_suspend fails very easily

[Daniel Manrique]

A system whose audio subsystem doesn't come back from suspension is considered to be pretty faulty. Thus, in principle, the suspend/audio_after_suspend test should be quite critical.

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_playback_after_suspend more reliable.

[Daniel Manrique (roadmr)]

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.

[Jeff Lane  (bladernr)]

From a different point of view, while not finding a hardware related problem it IS finding a software one. IMO, this is highlighting a bug either in what Ubuntu does during a suspend and resume on these certain systems (or hibernate, because I presume this would also affect hibernate/resume) or how the mixer saves state during sleep states.

One would certainly not expect this sort of behaviour when waking from sleep states. A comparable analogy would be having a system set to use English locale that suddenly changes to German locale after a suspend. That too would be very undesirable.

So I'd actually say that the test is doing exactly what it's supposed to do, only it's catching that software bug rather than an underlying hardware bug.

That being said, this test shouldn't actually cause subsequent audio tests to register as failures either. It should rightly fail on its own, but not affect record_playback_after_suspend or anything else.

[Jeff Lane  (bladernr)]

Then again... if the Mic and Speakers are muted after suspend, record_playback_after_suspend will likewise fail because you can't record sound with a muted Mic, and can't play back audio over muted speakers... :/

[Brendan Donegan (brendan-donegan)]

If this only happens on some systems then it *is* a hardware bug. I would close this and raise individual bugs for each system which exhibits this. We can't call it a blocker but it should be fixed.

[Brendan Donegan (brendan-donegan)]

@Daniel,

I've set this to invalid, which I think is the right thing to do if this issue doesn't affect all systems. Can you confirm that or not?

[Daniel Manrique (roadmr)]

I wouldn't think it's a hardware bug; see bug 994685 which has a similar result and is most definitely sofware-based (so much so, that it appeared on an as-yet-undetermined mainline kernel and *then* was fixed on kernel 3.4-rc1).

However I agree that it should be handled on a per-system basis, since it's also not widespread enough to be considered an overreaching kernel bug.

Thanks for the triaging! :)