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
next prev parent 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