Takashi Iwai wrote:
Clemens Ladisch wrote:
There is a loopback driver, but it is not part of the LSB specification. This means that a test using this driver would not work with any alternate ALSA implementation.
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.)
I can easily imagine LSB-compliant computers that do not have any sound card (e.g., most servers). Even if the ALSA interface (i.e., libasound) is installed, some parts cannot be used in any meaningful way. What is a test supposed to do in this case? It could just exit with "pass", but this wouldn't actually _test_ much.
The test can never cover 100% all real cases. So, the primary question is: what kind of test do we need.
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.
So ALSA's LSB tests would be like the Qt4 tests, whose description is: | check run-time presence of interfaces and absence of critical errors | in simple use cases
(Hmmm, a dummy ALSA implementation that just returns -ENODEV when the application tries to open a device would be compliant, because it cannot be distinguished from the 'real' ALSA with no installed sound card. :-)
You mean the dummy sound driver?
No. I meant that the ALSA interfaces, in case they are only required for strict LSB compliance but not for actual sound output, could be implemented like this to save memory:
int snd_pcm_open(...) { return -ENODEV; }
This is purely theoretical, but my point is that this would be a conforming implementation of the ALSA interface.
Best regards, Clemens