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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
