Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Robert Schweikert <rschweikert@novell.com>
Subject: Re: LSB inclusion of ALSA
Date: Wed, 17 Jun 2009 10:52:38 +0200	[thread overview]
Message-ID: <4A38AED6.4060009@ladisch.de> (raw)
In-Reply-To: <s5h3a9z46ne.wl%tiwai@suse.de>

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

  reply	other threads:[~2009-06-17  8:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12 17:56 LSB inclusion of ALSA Robert Schweikert
2009-06-16 11:59 ` Clemens Ladisch
2009-06-17  8:16   ` Takashi Iwai
2009-06-17  8:52     ` Clemens Ladisch [this message]
2009-06-19 12:07       ` Robert Schweikert
2009-06-19 12:45       ` Theodore Tso
2009-06-19 13:43         ` Clemens Ladisch
2009-06-19 11:39   ` Robert Schweikert
2009-06-19 13:43     ` Clemens Ladisch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A38AED6.4060009@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=rschweikert@novell.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox