[alsa-devel] LSB inclusion of ALSA

[Robert Schweikert]

Clemens Ladisch wrote:
> 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.)
>   
If we need special libraries for testing that's fine. These do not have
to be part of the LSB.
>   
>>> 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
>   
Well, hopefully not quite that rudimentary but definitely in line with
this train of thought. Just like the ALSA project cannot test all
possible configurations, neither can the LSB. From a driver - hardware
perspective the LSB probably can test less than those more deeply
involved in the project.

One of the key parts of any effort is that the tests are accepted by the
project and maintained in some way. If we just create LSB tests that are
separate from the project things will diverge and become stale.
>   
>>> (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.
>   
But this would fail the test where we load the dummy driver and test
another return value (see previous post for more details).
>
> Best regards,
> Clemens
>   

-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
Software Engineer Consultant                          LINUX
rschweikert at novell.com 
781-464-8147

Novell
Making IT Work As One