From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2598 invoked from network); 6 Dec 2004 13:54:19 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 6 Dec 2004 13:54:19 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CbJJj-0001XM-Cu for arch-gentoo-user@lists.gentoo.org; Mon, 06 Dec 2004 13:54:19 +0000 Received: (qmail 13061 invoked by uid 89); 6 Dec 2004 13:54:02 +0000 Mailing-List: contact gentoo-user-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-user@lists.gentoo.org X-BeenThere: gentoo-user@gentoo.org Received: (qmail 3209 invoked from network); 6 Dec 2004 13:54:02 +0000 Date: Mon, 06 Dec 2004 14:53:26 +0100 From: Holly Bostick In-reply-to: <41B45F38.4060906@brannanorwills.com> To: gentoo-user@lists.gentoo.org Message-id: <41B46456.1080608@planet.nl> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <20041206164950.10E7.NICK@rout.co.nz> <41B3DB19.40701@brannanorwills.com> <20041206171358.10EA.NICK@rout.co.nz> <41B45884.1020308@brannanorwills.com> <41B45AF0.7050504@planet.nl> <41B45F38.4060906@brannanorwills.com> Subject: Re: [gentoo-user] sound driver X-Archives-Salt: 82bead73-6850-4cf3-ae16-6e3cf8754d25 X-Archives-Hash: bc57721b48f28bdd31324186cee78948 Kathy Wills wrote: > Holly Bostick wrote: > >> Now, weirdly, I am also running a pure udev system, and I do not have >> this problem (of muted sound), but to get that, rather than using >> /etc/conf.d/local.start, I have alsasound in both boot and default >> runlevels. >> >> That's the only way it seems to work right (possibly because I >> modularize many of the various alsa components, so they aren't >> actually loaded when/if alsasound runs at the boot level). >> >> Dunno, but I must say I prefer that to using /etc/conf.d/local.start. >> >> HTH, >> >> Holly > > > Thanks, I'll have to try that to. Did you just add rc-update alsasound > default along with the alsasound boot to get it working like this? > Well, yes. There isn't actually a limit as to how many runlevels you can set using rc-update add, it would seem; I noticed that when I did an rc-update show and realized that "local" appears in two runlevels (default and nonetwork). So you can just do an rc-update add alsasound boot default and add it to both, if it's not currently enabled (if it's already in one of the runlevels you attempt to add, you will of course get a failure to add it to that runlevel). I actually did this originally by accident, I think-- I had first installed alsasound to boot like it says to do, and then later I thought something was wrong (I had messed around with modularizing the drivers or something), and didn't do an rc-update show first (or didn't see alsasound, if I did). I couldn't remember which runlevel it was "supposed" to be in, so I installed it to default, which went fine, as it was not installed to the default runlevel at that time. So there it was in both, and (except for my current snd-seq-oss problem, which I think I know how to fix), I've never had any problems with it the way you would expect if it was "wrong" to do-- no errors that I've noticed in either run; certainly no errors in the 'default' run (where you would think to see them). I do think that this works because some ALSA modules really prefer to be modules under udev, but some flatly cannot-- for example, snd-seq-oss cannot be a module (despite what the Help says), but snd-seq (on which snd-seq-oss depends), can. So some parts of a complete ALSA install cannot be put in /etc/modules.autoload.d/kernel-2.6, where udev prefers to have them (because statically compiled modues are loaded before udev is running, so it can't create devices for them). So the first run loads the forced static compiles, and the second run loads the modules. That's my theory, anyway ;-) . Holly -- gentoo-user@gentoo.org mailing list