Bug 498699 - No sound output
No sound output
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-02 00:45 EDT by Ralf Corsepius
Modified: 2009-05-07 14:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-06 21:32:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of alsa-info.sh (21.10 KB, text/plain)
2009-05-02 00:46 EDT, Ralf Corsepius
no flags Details

  None (edit)
Description Ralf Corsepius 2009-05-02 00:45:33 EDT
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
Comment 1 Ralf Corsepius 2009-05-02 00:46:55 EDT
Created attachment 342162 [details]
output of alsa-info.sh
Comment 2 Ralf Corsepius 2009-05-02 00:54:12 EDT
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
Comment 3 Adam Williamson 2009-05-02 01:49:31 EDT
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!
Comment 4 Ralf Corsepius 2009-05-02 02:26:22 EDT
(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.
Comment 5 Lubomir Rintel 2009-05-02 03:34:02 EDT
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.
Comment 6 Ralf Corsepius 2009-05-02 03:58:49 EDT
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.
Comment 7 Lennart Poettering 2009-05-02 10:41:13 EDT
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.
Comment 8 Adam Williamson 2009-05-02 19:52:02 EDT
lubomir: "alsactl init" ought to do the same as you'd get by removing /etc/asound.state and rebooting.
Comment 9 Lubomir Rintel 2009-05-03 01:55:44 EDT
(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.
Comment 10 Adam Williamson 2009-05-04 15:47:53 EDT
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.
Comment 11 Lennart Poettering 2009-05-06 14:01:05 EDT
Hmm, may I close this bug then?
Comment 12 Adam Williamson 2009-05-06 16:50:53 EDT
I think we could...Ralf? Can you confirm that everything's fine for a clean user account?
Comment 13 Lennart Poettering 2009-05-06 21:32:38 EDT
Ok, will close then. Feel free to reopen if I am doing this prematurely... ;-)
Comment 14 Ralf Corsepius 2009-05-06 22:32:03 EDT
(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.
Comment 15 Adam Williamson 2009-05-07 14:40:35 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.