Description of problem: On an elderly notebook, with FC11, seemingly since introduction of the new gnome-volume-control, sound output stopped working. Symptom: No sound output on frontspeakers nor earphone. Neither system sounds nor music/video playback. Version-Release number of selected component (if applicable): pulseaudio-0.9.15-11.fc11.i586 gnome-media-2.26.0-2.fc11.i586 How reproducible: Always Steps to Reproduce: Use any arbitrary standards sound application (e.g. rhythmbox). Actual results: No sound. Expected results: Sound
Created attachment 342162 [details] output of alsa-info.sh
Further observations: * when manually running "alsactl init" audio output starts. * without running "alsactl init", increasing "PCM output volume" in alsamixer helps to let the system produce audio output. * running "alsactl init" issues these warnings: Unknown hardware "ICH" "Realtek ALC650F" "AC97a:414x4723" "" "" Hardware is initializzed using a guess method
is there a way you can reproduce the "no sound" case? It's odd that "alsactl init" should fix it, because that should give you the default volumes you would have got out of the box. I'm not quite 100% sure what's going on here. thanks!
(In reply to comment #3) > is there a way you can reproduce the "no sound" case? Well, "no sound" is what is happening "by default", after each reboot, without manual interaction. That is, the way I am producing the effect is 1. reboot 2. login 3. launch rhythmbox and try to play a sound file. So far, the only ways I found to obtain "sound output" on front speakers/earphones (They seem to be physically wired together) is to either * run "alsactl init" or * to launch "alsamixer -c0" and to increase the "PCM" volume. Checking the alsamixer settings before and after "alsactl init" report the settings to have changed. > It's odd that "alsactl > init" should fix it, because that should give you the default volumes you > would have got out of the box. AFAIS, this is exactly what is not happening. I would guess on a boot up sequence ordering issue, which causes some "early initialization" to pickup different values than "late initialization" or similar.
I'm wondering if removing /etc/asound.state and rebooting would fix the default mixer values? Just in case you updated from older version of Fedora having muted the PCM channel there, or muted it manually.
Further observation: This issue seems to be a "per user setup" thing, likely related to ~/.pulse* * I was observing this issue when logging-in with an account which predated FC11 (IIRC, the account had been created under FC9 and is on a partition being shared between FC10 and FC11). * I am not observing this issue when logging-in with a freshly created account. For now, "rm -rf ~/.pulse*" on the affected account seems to have resolved the problem - However, I haven't rebooted under FC10 yet, nor have I checked the impact on nfs-mounted accounts being shared between different machines and different OSes (in my case: FC10 and FC11). (In reply to comment #5) > I'm wondering if removing /etc/asound.state and rebooting would fix the default > mixer values? OK, I'll take this into account in further experiments. > Just in case you updated from older version of Fedora having > muted the PCM channel there, or muted it manually. Yes, this machine was "yum-upgraded to rawhide from FC10", because all other ways of installing F11-Preview have failed for me.
PA only saves/restores the volume of the mixer element it controls. i.e. PA won't touch any controls that you cannot control via g-v-c or pavucontrol. Controls PA doesn't touch are saved/restored in /etc/asound.state and can be saved/restored via "alsactl save" and "alsactl" restore.
lubomir: "alsactl init" ought to do the same as you'd get by removing /etc/asound.state and rebooting.
(In reply to comment #8) > lubomir: "alsactl init" ought to do the same as you'd get by removing > /etc/asound.state and rebooting. Then the manual is wrong; it does not say anything about modifying the saved state, so it implies that the new state gets lost unless the system shutdown scripts which do alsactl save are done.
oh, no, that's quite true - but I mean it should do the same thing in the sense that you'd get back to the default values for the mixer as of *right now* (whenever you run the command). indeed it doesn't modify the saved state, AFAIK.
Hmm, may I close this bug then?
I think we could...Ralf? Can you confirm that everything's fine for a clean user account?
Ok, will close then. Feel free to reopen if I am doing this prematurely... ;-)
(In reply to comment #12) > I think we could...Ralf? Can you confirm that everything's fine for a clean > user account? Well, ... yes, I "can live" with what I found. However, I still don't understand the cause of problem yet nor can I say to be satisified with the "work-around", nor to have fully tested it. There definitely is something wrong and there definitely are more issues, but ... I don't know what nor do I know if these issues are linked to this.
I'm afraid I'm a bit confused about the status and possible causes of whatever problems remain, so I'm not sure I can do much to help here...if you can provide more clear / detailed info about the status and what's still wrong, we can either re-open this bug or file a new one as appropriate.