Да, после недавнего переезда на 2.6.24-std-def (вместе с прочим сизифом) дома на
snd-emu10k1 тоже заметил, что две загрузки из трёх привели к нулям в микшере. 
Третья, однако -- к норме (хотя это мог быть kmix, если уже успела запуститься
рядом kde-шная сессия).

там наверное race какой-то - попытка восстановить значение миксеров раньше, чем
проинициализирован звуковой адаптер в драйвере.

IMHO стоит или делать какие-то задержки при восстановлении уровней, или же
действительно перенести эту функциональность в sound-scripts.

Какая версия udev установлена?  В udev-118-alt1 убрано лишнее правило, которое
могло приводить к подобным эффектам при наличии файла /etc/asound.state (в этом
случае настройки, сохранённые в /etc/asound.state, перекрывали загружаемые из
/var/lib/hotplug/asound*.state).

Гипотезу с race можно проверить, выполнив после загрузки

  for f in /sys/class/sound/controlC*/uevent; do echo -n add >"$f"; done

(войти с консоли, проверить состояние alsamixer до и после выполнения команды).
Эта команда приведёт к повторной обработке событий для звуковых устройств.

Можно также исследовать поведение при перезагрузке модулей (предварительно
настроив микшер и выполнив service sound restart, чтобы в
/var/lib/hotplug/asound*.state записались правильные настройки).

udev-118-alt1

Как только доберусь физически до машины - поэкспериментирую.

# rpm -qa|fgrep udev-|sort
udev-118-alt1
udev-initramfs-118-alt1
udev-rules-118-alt1

Честно говоря, для себя я эту проблему решил копированием в /etc/init.d/sound
цикла с вызовом alsactl из функции stop() в start() с заменой команды save на
restore. udev со товарищи производят на меня впечатление настолько ужасное, что
описать его приличными словами я не берусь, тем более заниматься его отладкой.
Дело это бессмысленное, как борьба со СПИДом в Африке.

udev-108-alt1

На kernel-image-std-def-2.6.24-alt6 настройки звука восстанавливались, а на
kernel-image-std-def-2.6.24-alt8 -- нет.

С udev-118-alt1 так же:

(In reply to comment #6)
> На kernel-image-std-def-2.6.24-alt6 настройки звука восстанавливались, а на
> kernel-image-std-def-2.6.24-alt8 -- нет.

Врятли это зависит от версии ядра.. скорее всего действительно race.

Иван, проверь пожалуйста у себя по совету Сергея.

(In reply to comment #3)
> Какая версия udev установлена?  В udev-118-alt1
Она самая.

> убрано лишнее правило, которое могло приводить к подобным эффектам
> при наличии файла /etc/asound.state
Есть такой, состояние в нём по жизни было рабочим (есть бэкап).

> (в этом случае настройки, сохранённые в /etc/asound.state, перекрывали 
> загружаемые из /var/lib/hotplug/asound*.state).
И такие есть:
-rw-r--r-- 1 root root 64778 Mar  4  2007 /etc/asound.state
-rw-r--r-- 1 root root 16549 May  9 02:31 /var/lib/hotplug/asound0.state
-rw-r--r-- 1 root root  8071 Feb 17  2007 /var/lib/hotplug/asound1.state
(второй -- набортная, довольно давно отключена в BIOS)

home:~> grep -A2 'Master Playback Volume' /etc/asound.state
/var/lib/hotplug/asound0.state                              
/etc/asound.state:              name 'Master Playback Volume'
/etc/asound.state-              value.0 22
/etc/asound.state-              value.1 22
--
/etc/asound.state:              name 'Master Playback Volume'
/etc/asound.state-              value.0 0
/etc/asound.state-              value.1 0
--
/var/lib/hotplug/asound0.state:         name 'Master Playback Volume'
/var/lib/hotplug/asound0.state-         value.0 29
/var/lib/hotplug/asound0.state-         value.1 29

> Гипотезу с race можно проверить, выполнив после загрузки
>   for f in /sys/class/sound/controlC*/uevent; do echo -n add >"$f"; done
> (войти с консоли, проверить состояние alsamixer до и после выполнения 
> команды).
> Эта команда приведёт к повторной обработке событий для звуковых устройств.
Не выставило; проверял из WindowMaker, тут в сессии запущен wmix, который не
пытается восстанавливать уровни сам.

> Можно также исследовать поведение при перезагрузке модулей (предварительно
> настроив микшер и выполнив service sound restart, чтобы в
> /var/lib/hotplug/asound*.state записались правильные настройки).
Записал:
/var/lib/hotplug/asound0.state:         name 'Master Playback Volume'
/var/lib/hotplug/asound0.state-         value.0 23
/var/lib/hotplug/asound0.state-         value.1 23

# lsmod | grep ^snd | awk '{ print $1; }' | xargs rmmod
# lsmod | grep ^snd                                    
# 

# modprobe snd_emu10k1                
# modprobe snd_mixer_oss
# modprobe snd_pcm_oss  
В alsamixer на Master и PCM -- нули/muted.  Отодвинул /etc/asound.state,
rmmod/modprobe -- то же.

После загрузки в таком виде (с не-нулями перед ней) в asound0.state нули:
/var/lib/hotplug/asound0.state:         name 'Master Playback Volume'
/var/lib/hotplug/asound0.state-         value.0 0
/var/lib/hotplug/asound0.state-         value.1 0

и Master/PCM -- muted/0.

А кто туда эти нули-то насовал?

Ещё раз проверил, чтоб уж наверняка:
- alsamixer (master/pcm в 77);
- service sound restart (value.[01] 24 в /var/lib/hotplug/asound0.state);
- reboot

Микшер в нулях, хотя сохранены правильные значения:
/var/lib/hotplug/asound0.state:         name 'Master Playback Volume'
/var/lib/hotplug/asound0.state-         value.0 24
/var/lib/hotplug/asound0.state-         value.1 24

(In reply to comment #8)
> Врятли это зависит от версии ядра.. скорее всего действительно race.

Да, я сейчас и сам это обнаружил. 2 раза и на 2.6.24-std-def-alt6 такое
случилось (но много раз -- ok). При этом до установки 2.6.24-std-def-alt8 я
такого ни разу не замечал.

(In reply to comment #8)
> Иван, проверь пожалуйста у себя по совету Сергея.
> 

(In reply to comment #3)
> Гипотезу с race можно проверить, выполнив после загрузки
> 
>   for f in /sys/class/sound/controlC*/uevent; do echo -n add >"$f"; done
> 
> (войти с консоли, проверить состояние alsamixer до и после выполнения команды).

Да: до этого всё плохо, после этойкоманды всё восстановилось как надо.

А какие версии libalsa, alsa-utils используются?

Ещё стоит провести следующий тест (после настройки состояния микшера):

  service sound restart
  udevcontrol --stop_exec_queue
  rmmod snd-... (выгрузить драйвер звуковой карты)
  modprobe snd-... (загрузить его снова)
  alsactl -F -f /var/lib/hotplug/asound0.state restore 0; echo $?

Если вывод от alsactl не пустой, или статус не 0, попробуйте повторить ту же
команду ещё раз:

  alsactl -F -f /var/lib/hotplug/asound0.state restore 0; echo $?

Интересует вывод alsactl, если он не пустой, и возвращённый им $?, а также
получающееся после этого состояние микшера (но между modprobe и alsactl его
смотреть нельзя, и вообще желательно, чтобы не было запущено ничего, что может
трогать звук; для уменьшения вероятности посторонних воздействий можно выполнить
modprobe и alsactl одной командой).

Затем можно разблокировать udevd (udevcontrol --start_exec_queue).

(In reply to comment #14)
> А какие версии libalsa, alsa-utils используются?
libalsa-1.0.14a-alt2.1
alsa-utils-1.0.14-alt3

(In reply to comment #14)
> Ещё стоит провести следующий тест (после настройки состояния микшера):

Я это проделал раза три, вывод alsactl всегда был пустым и код воврата -- 0.
После этого состояние микшера было со включённым звуком (такое же, как было).

> 
>   service sound restart
>   udevcontrol --stop_exec_queue
>   rmmod snd-... (выгрузить драйвер звуковой карты)
>   modprobe snd-... (загрузить его снова)
>   alsactl -F -f /var/lib/hotplug/asound0.state restore 0; echo $?
> 
> Если вывод от alsactl не пустой, или статус не 0, попробуйте повторить ту же
> команду ещё раз:
> 
>   alsactl -F -f /var/lib/hotplug/asound0.state restore 0; echo $?
> 
> Интересует вывод alsactl, если он не пустой, и возвращённый им $?, а также
> получающееся после этого состояние микшера (но между modprobe и alsactl его
> смотреть нельзя, и вообще желательно, чтобы не было запущено ничего, что может
> трогать звук; для уменьшения вероятности посторонних воздействий можно выполнить
> modprobe и alsactl одной командой).
> 
> Затем можно разблокировать udevd (udevcontrol --start_exec_queue).

home:~> rpm -q libalsa alsa-utils 
libalsa-1.0.16-alt1
alsa-utils-1.0.16-alt1

> Ещё стоит провести следующий тест (после настройки состояния микшера):
Master/PCM по нулям/muted

> service sound restart
> udevcontrol --stop_exec_queue
(muted)

> rmmod snd-...
root@home ~ # lsmod | grep ^snd | awk '{ print $1; }' | xargs rmmod
root@home ~ # lsmod | grep snd
root@home ~ # 

> modprobe snd-...
root@home ~ # modprobe snd-emu10k1

> alsactl -F -f /var/lib/hotplug/asound0.state restore 0; echo $?
root@home ~ # alsactl -F -f /var/lib/hotplug/asound0.state restore 0; echo $?
0
PCM/Master по-прежнему 0/muted

> но между modprobe и alsactl его смотреть нельзя
Тьфу ты :)  сейчас тогда ещё раз бутну для чистоты эксперимента.
Ещё все микшеры, в т.ч. неинтрузивные вроде wmix/wmusic, надо погрохать.

root@home ~ # killall wmix wmusic
root@home ~ # service sound restart
Saving mixer values for card(0):                                        [ DONE ]
root@home ~ # udevcontrol --stop_exec_queue
root@home ~ # lsmod | grep ^snd | awk '{ print $1; }' | xargs rmmod
root@home ~ # modprobe snd-emu10k1                                 
root@home ~ # alsactl -F -f /var/lib/hotplug/asound0.state restore 0; echo $?
0
root@home ~ # alsamixer 
[0/muted]

root@home ~ # killall wmix wmusic
root@home ~ # service sound restart
Saving mixer values for card(0):                                        [ DONE ]
root@home ~ # udevcontrol --stop_exec_queue
root@home ~ # lsmod | grep ^snd | awk '{ print $1; }' | xargs rmmod
root@home ~ # modprobe snd-emu10k1; alsactl -F -f /var/lib/hotplug/asound0.state
restore 0; echo $?
0
root@home ~ # alsamixer 
Опять PCM/Master выключены.

Подумал -- мож это flash plugin врезается (браузер запускал до проведения
операций)...

Загрузился в runlevel 3, повторил, результат тот же:

root@home ~ # killall wmix wmusic
wmix: no process killed
wmusic: no process killed
root@home ~ # service sound restart
Saving mixer values for card(0): [ DONE ]
root@home ~ # udevcontrol --stop_exec_queue
root@home ~ # lsmod | grep ^snd | awk '{ print $1; }' | xargs rmmod
root@home ~ # modprobe snd-emu10k1; alsactl -F -f /var/lib/hotplug/asound0.state
restore 0; echo $?
0
root@home ~ # alsamixer
нули :(
(Bass/Treble стоят по 50, но как понимаю -- это инициализация драйвером)

home:~> cat /proc/asound/cards 
 0 [Live           ]: EMU10K1 - SB Live 5.1
                      SB Live 5.1 (rev.7, serial:0x80641102) at 0xa800, irq 9

В /var/lib/hotplug/ присутствуют asound[01].state, при этом 0 толще и содержит
знакомые названия контролов, 1 больше года не трогался (как отключил набортный
звук, видимо).

Получается, у нас alsactl сломанный, что ли?

(In reply to comment #20)
> Подумал -- мож это flash plugin врезается (браузер запускал до проведения
> операций)...
> 
> Загрузился в runlevel 3, повторил, результат тот же:
> 
> root@home ~ # killall wmix wmusic
> wmix: no process killed
> wmusic: no process killed
> root@home ~ # service sound restart
> Saving mixer values for card(0): [ DONE ]
> root@home ~ # udevcontrol --stop_exec_queue
> root@home ~ # lsmod | grep ^snd | awk '{ print $1; }' | xargs rmmod
> root@home ~ # modprobe snd-emu10k1; alsactl -F -f /var/lib/hotplug/asound0.state
> restore 0; echo $?
> 0
> root@home ~ # alsamixer
> нули :(
> (Bass/Treble стоят по 50, но как понимаю -- это инициализация драйвером)
> 
> home:~> cat /proc/asound/cards 
>  0 [Live           ]: EMU10K1 - SB Live 5.1
>                       SB Live 5.1 (rev.7, serial:0x80641102) at 0xa800, irq 9
> 
> В /var/lib/hotplug/ присутствуют asound[01].state, при этом 0 толще и содержит
> знакомые названия контролов, 1 больше года не трогался (как отключил набортный
> звук, видимо).
> 
> Получается, у нас alsactl сломанный, что ли?

alsactl рабочий, я же писал выше, что его вызов с командой save, будучи помещен
обратно в /etc/init.d/sound, нормально отрабатывает в 100%.

А вот в различных state.asound файлах у меня творилась полная каша, хотя это
видимо был результат двукратной смены звуковой карты. Похоже, что команда
alsactl save не переписывает файл (как можно было бы предположить), а добавляет
в него текущие установки звуковой карты. Но старые при этом не удаляет. То есть
если карточку сменить - установки старой карты так там и останутся.

Впрочем, это не имеет отношения к проблеме. Я когда с этим разобрался -
аккуратно удалил все старые sound.state файлы руками. Удаву это никак не
помогло, у меня он по-прежнему не срабатывает в 100%.

(In reply to comment #16)
> > Ещё стоит провести следующий тест (после настройки состояния микшера):
> 
> Я это проделал раза три, вывод alsactl всегда был пустым и код воврата -- 0.
> После этого состояние микшера было со включённым звуком (такое же, как было).

Попробовал то же самое вообще без единого загруженного snd модуля: всё всё равно
происходит так же хорошо.

Обновил libalsa, alsa-utils -- понаблюдаю с ними.

пробуйте sound-scripts-0.51-alt1. брать в гите, если кто не осилит гит, соберу 
в дедал

(In reply to comment #22)

> Обновил libalsa, alsa-utils -- понаблюдаю с ними.

С ними (libalsa-1.0.16-alt1, alsa-utils-1.0.16-alt1) то же: где-то на пятой
перезагрузке опять звук не восстановился. 

(Новые sound-scripts ещё не пробовал.)

Я попробовал.
При установке ругнулся так, но уровни громкости стали сохраняться.

[diman@dimanko RPMS.hasher]$ sudo rpm -Uvh sound-scripts-0.51-alt1.noarch.rpm 
Preparing...                
#################################################################################
sound-scripts               
#################################################################################
Saving mixer values for VIA 8237 with ALC850: Error
org.freedesktop.DBus.Error.UnknownMethod: Method "SaveMixer" with signature ""
on interface "org.freedesktop.Hal.Device.Alsa" doesn't exist

[FAILED]
Restore mixer values for VIA 8237 with ALC850: Error
org.freedesktop.DBus.Error.UnknownMethod: Method "RestoreMixer" with signature
"" on interface "org.freedesktop.Hal.Device.Alsa" doesn't exist

[FAILED]
Stopping HAL service: [ DONE ]
Starting HAL service: [ DONE ]

(In reply to comment #23)
> пробуйте sound-scripts-0.51-alt1. брать в гите, если кто не осилит гит, соберу 
> в дедал

sound-scripts-0.51-alt1

Теперь, конечно, я не получаю mute после загрузки, но уровни не
восстанавливаются те, что были: теперь я всегда после загрузки получаю большую
громкость master (что-то в районе 70%), неполную громкость pcm (хотя я ставил
100%), замьюченный pc speaker (хотя у меня я его включаю и делаю около 60%) и т.д.

apparently nobody works on it => reassign :(

(In reply to comment #27)
> apparently nobody works on it => reassign :(
> 

Тоже напомню, что не работает. Или срабатывает раз из трех. Свежий Сизиф, три устройства, для которых происходит сохранение: SBLive, интегрированная звуковыха и ТВ-тюнер на bt878.

шлите патчи

Минимальную задачу для себя: сделать так, чтобы после включения звук был настроен, как мне нравится -- я решил так (при этом сохранение изменённого состояния всё равно пока не работает):

# rm /var/lib/hal/asound/.state (какой-то мусор)

Посмотреть, что будет:
# HAL_PROP_ALSA_CARD=0 /usr/share/hal/scripts/linux/hal-system-alsa-mixer-restore-linux

Теперь настраиваю все уровни звука и переключатели, как мне надо, и:
# HAL_PROP_ALSA_CARD=0 /usr/share/hal/scripts/linux/hal-system-alsa-mixer-save-linux

Ну и, кажется, всё; оно сохранилось.

(Проверяю, что записалось что-то разумное: 
# less /var/lib/hal/asound/0.state
# HAL_PROP_ALSA_CARD=0 /usr/share/hal/scripts/linux/hal-system-alsa-mixer-restore-linux
.)

Это с sound-scripts 20070530:0.51-alt1.

(In reply to comment #30)
> Минимальную задачу для себя: сделать так, чтобы после включения звук был
> настроен, как мне нравится -- я решил так (при этом сохранение изменённого
> состояния всё равно пока не работает):

Так по-прежнему и не восстанавливает?

(В ответ на комментарий №32)
> Так по-прежнему и не восстанавливает?

У меня в настоящий момент _кажется_ все работает. Но надо продолжать наблюдение.

Продолжать наблюдение - это само собой :)