On Wed, Jun 17, 2009 at 10:52:38AM +0200, Clemens Ladisch wrote:
Takashi Iwai wrote:
Yes, I mentioned about this in the last conf call with LSB guys.
Another candidate is alsa-lib file plugin (and null plugin). They can be used to simulate in a certain level of I/O.
I don't think that LSB guarantees the availability of these plugins either. (And they don't get the timing correct, but maybe we don't care about that.)
That's not necessarily fatal, *if* the LSB sound tests can include the plugin in question. Is the plugin interface a stable, published interface? That is, is it guaranteed to remain stable from release to release of ALSA? If so, then the test suite can provide the plugin, just for the purposes of running the test.
From the LSB perspective, I suppose, the API compatibility is the biggest issue. The functionality, either working or not on the real hardware, is a subsystem bug. And, the subtle tests would be likely needed done manually with the real hardware.
This is true, but some kind of minimal functionality testing is often useful to make sure that the *meaning* of the parameters haven't changed. For example, to take an extreme example, if a library were to accidentally change a long to "long long" in a function signature, but because of how other parameters and what happened to be in the registers on an x86 system, the program might not crash, and if were testing with a no-op output function for the program, we might not notice a problem.
So it's nice to be able to do a semantic test "does this function actually do roughly what it is spec'ed to do", and not just a simple API test. On the other hand, we also recognize that perfection can require far more resources than are available, so often we have to settle for a basic test.
- Ted