Robert Reif wrote:
The only way to test the actual capture and playback code paths is to run in interactive mode. It would be nice to have someone listen to what is played but it is not absolutely necessary to determine if the function calls fail or return bad data.
The main goal of interactive tests is to have someone actually listen to the test tones and verify that they are being played correctly: with no stutter and at the correct pitch and volume. This cannot be automated.
However it's true that more tests are being performed in interactive mode and that some don't require anyone to listen. So maybe we could have the tests play silence (and not touch the volume) when they are run in non-interactive mode.
The capture test can be considered non-interactive already since it does not matter if someone listens to them or not: the capture test records sound but there is no proof that the sound was recorded properly (it's exactly like electronic voting, you vote but you don't know what the machine did). The only way to check that would be to play the sound back and have a human check that what is being played corresponds to what was supposed to be recorded. Of course that supposes actually hooking up a microphone or some other sound source to the soundcard...
So the only potential issue is the timeout one...