1 |
Kathy Wills wrote: |
2 |
> Holly Bostick wrote: |
3 |
> |
4 |
>> Now, weirdly, I am also running a pure udev system, and I do not have |
5 |
>> this problem (of muted sound), but to get that, rather than using |
6 |
>> /etc/conf.d/local.start, I have alsasound in both boot and default |
7 |
>> runlevels. |
8 |
>> |
9 |
>> That's the only way it seems to work right (possibly because I |
10 |
>> modularize many of the various alsa components, so they aren't |
11 |
>> actually loaded when/if alsasound runs at the boot level). |
12 |
>> |
13 |
>> Dunno, but I must say I prefer that to using /etc/conf.d/local.start. |
14 |
>> |
15 |
>> HTH, |
16 |
>> |
17 |
>> Holly |
18 |
> |
19 |
> |
20 |
> Thanks, I'll have to try that to. Did you just add rc-update alsasound |
21 |
> default along with the alsasound boot to get it working like this? |
22 |
> |
23 |
|
24 |
Well, yes. There isn't actually a limit as to how many runlevels you can |
25 |
set using rc-update add, it would seem; I noticed that when I did an |
26 |
rc-update show and realized that "local" appears in two runlevels |
27 |
(default and nonetwork). So you can just do an rc-update add alsasound |
28 |
boot default and add it to both, if it's not currently enabled (if it's |
29 |
already in one of the runlevels you attempt to add, you will of course |
30 |
get a failure to add it to that runlevel). |
31 |
|
32 |
I actually did this originally by accident, I think-- I had first |
33 |
installed alsasound to boot like it says to do, and then later I thought |
34 |
something was wrong (I had messed around with modularizing the drivers |
35 |
or something), and didn't do an rc-update show first (or didn't see |
36 |
alsasound, if I did). I couldn't remember which runlevel it was |
37 |
"supposed" to be in, so I installed it to default, which went fine, as |
38 |
it was not installed to the default runlevel at that time. So there it |
39 |
was in both, and (except for my current snd-seq-oss problem, which I |
40 |
think I know how to fix), I've never had any problems with it the way |
41 |
you would expect if it was "wrong" to do-- no errors that I've noticed |
42 |
in either run; certainly no errors in the 'default' run (where you would |
43 |
think to see them). |
44 |
|
45 |
I do think that this works because some ALSA modules really prefer to be |
46 |
modules under udev, but some flatly cannot-- for example, snd-seq-oss |
47 |
cannot be a module (despite what the Help says), but snd-seq (on which |
48 |
snd-seq-oss depends), can. So some parts of a complete ALSA install |
49 |
cannot be put in /etc/modules.autoload.d/kernel-2.6, where udev prefers |
50 |
to have them (because statically compiled modues are loaded before udev |
51 |
is running, so it can't create devices for them). |
52 |
|
53 |
So the first run loads the forced static compiles, and the second run |
54 |
loads the modules. |
55 |
|
56 |
That's my theory, anyway ;-) . |
57 |
|
58 |
Holly |
59 |
|
60 |
-- |
61 |
gentoo-user@g.o mailing list |