All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.