public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Daniel Drake <dsd@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Interesting install experience
Date: Thu, 14 Jul 2005 20:33:23 +0100	[thread overview]
Message-ID: <42D6BE03.2060505@gentoo.org> (raw)
In-Reply-To: <yu9br552oqk.fsf@nyu.edu>

Allan Gottlieb wrote:
> *Very* interesting.  Please let us know when the documentation is
>  available.  I have build everything into the kernel (including alsa)
>  and so far it is working well, but I haven't stressed audio.  What
>  problems should I be looking for and do you advise rebuilding the
>  kernel with alsa as modules even if we don't experience trouble with
>  everything built in?  (I should have said all but nvidia built in).

It's fine to build ALSA into the kernel if you are happy to configure it,
which usually isn't too much hassle anyway.

The reasoning behind compiling ALSA as modules is that it then gives you the
option of using 'alsaconf'.

alsaconf is a great little utility, which, providing you have built the
modules, will configure pretty much any sound card for you, set up the system
for autoloading the relevant modules and saving/restoring volume, and unmuting
the channels.

I came across it when i was attempting to get an ISA sound card going in an
old computer. It just didn't work when built into the kernel or loading the
module manually. I discovered alsaconf, which did some weird probing, and 20
secs later informed me of 4 cryptic parameters that were needed to pass to the
module in order to find the sound card, as well as doing everything else I
described above.

Recently at work, I built *all* alsa drivers as modules, and proceeded to test
30-40 sound cards that we had lying around. ALSA supported every one of them
that wasn't so broken that it stopped the PC booting, and alsaconf made it
dead easy even with the older PCI cards and the ISA ones too.

So, the advantage of building ALSA modules is that you can use alsaconf, which
in most cases makes initial configuration a little bit simpler, and in some
cases is a complete lifesaver.

You might be interested in our recently revamped ALSA guide:
http://www.gentoo.org/doc/en/alsa-guide.xml

And also, if you are interested in the upcoming kernel config doc, then you
can add yourself to the CC list on http://bugs.gentoo.org/94955

Daniel
-- 
gentoo-user@gentoo.org mailing list



  reply	other threads:[~2005-07-14 19:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-14 15:27 [gentoo-user] Interesting install experience Jim Hatfield
2005-07-14 15:47 ` Hans-Werner Hilse
2005-07-14 15:58 ` Daniel Drake
2005-07-14 19:04   ` Allan Gottlieb
2005-07-14 19:33     ` Daniel Drake [this message]
2005-07-15  3:26       ` Allan Gottlieb

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=42D6BE03.2060505@gentoo.org \
    --to=dsd@gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /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