[alsa-devel] LSB inclusion of ALSA

Clemens Ladisch clemens at ladisch.de
Wed Jun 17 10:52:38 CEST 2009


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


More information about the Alsa-devel mailing list