Bug 905643

Edit: Not sure if the "Component" on this should be alsa-lib or pulseaudio (or some other). Please feel free to modify this as appropriate. Thanks!

Looks like I missed this other bug for the same issue when submitting mine. (#896164 - https://bugzilla.redhat.com/show_bug.cgi?id=896164). Which should be marked as the duplicate?

https://bugzilla.redhat.com/show_bug.cgi?id=893809

I have the same issue on the same setup.  The workaround fixes the problem for me too.

*** Bug 896164 has been marked as a duplicate of this bug. ***

(In reply to comment #3)
> https://bugzilla.redhat.com/show_bug.cgi?id=893809

This bug is not relevant.

I tried the KVM/F18/AC97 setup in virtual manager, but I don't see this issue. 

The mixer state store/restore/initialize is done in two ways:

systemd (for build-in soundcards):

  /lib/systemd/system/alsa-store.service
  /lib/systemd/system/alsa-restore.service

udev (for hotplug soundcards):

  /lib/udev/rules.d/90-alsa-restore.rules

Note that the restore rules (if no previous state file is found) should initialize the soundcards in exactly similar way as 'alsactl init' does.

What is state of alsa-restore.service after boot?

  systemctl status alsa-restore.service

Do you shutdown or force the halt the virtual machine? If you force the halt, the mixer settings is not saved.

Thanks for the reply. I currently have a functioning workaround in place - a basic one-line script (named alsa_init.sh) that I am running during startup via KDE Autostart. The contents of the script are simply: /usr/sbin/alsactl init

Let me disable this workaround and test that for you here...

[jeremy@localhost ~]$ systemctl status alsa-restore.service
alsa-restore.service - Restore Sound Card State
          Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
          Active: inactive (dead) since Wed 2013-03-20 07:31:30 PDT; 11min ago
         Process: 567 ExecStart=/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore (code=exited, status=0/SUCCESS)

And it looks like the output is pretty much the same with my workaround script in place and the sound working. Here it is, just for reference...

alsa-restore.service - Restore Sound Card State
          Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
          Active: inactive (dead) since Wed 2013-03-20 08:12:20 PDT; 2min 4s ago
         Process: 567 ExecStart=/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore (code=exited, status=0/SUCCESS)

It seems that alsa-restore.service was activated.

Could you disable your script (workaround) again and run the command from the configuration file after reboot?

/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore

Is mixer settings correct after this step?

Ok - I disabled my workaround script from Autostart and restarted. I confirmed that at this point I have no working sound again.

At this point, running the above command (both as myself and as root) came back without error and produced working sound from this point on.

I have not been touching kmix or alsamixer settings at all with any of this. I had some very strange results early on trying to resolve this issue through those and eventually gave up on them once I discovered that one simple command could resolve it, even if only temporarily.

I have 32-bit Fedora 18 without virtualization and I have the same symptoms. I can't hear anything, although Pulseaudio Volume Control shows activity in the volume bars.

But if I issue command "alsactl init" or "/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore", then I can hear normally!

My device is Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) (PCI ID 8086:24c5) with driver snd_intel8x0

$ systemctl status alsa-restore.service
alsa-restore.service - Restore Sound Card State
	  Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
	  Active: inactive (dead) since Mon 2013-04-15 21:41:07 EEST; 18min ago
	 Process: 519 ExecStart=/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore (code=exited, status=0/SUCCESS)

My versions:

kernel-3.8.6-203.fc18.i686
alsa-utils-1.0.26-1.fc18.i686

With Fedora 17 KDE Live CD audio works OK.

Please, attach output from 'alsa-info.sh --no-upload' when no sound and after 'alsactl init'.

Created attachment 736284 [details]
Output of alsa-info.sh before alsactl init

Created attachment 736285 [details]
Output of alsa-info.sh after alsactl init

A quick comparison shows that the Master volume is zero and off (muted). Other controls are initialized, so the volume restore command was called.

Please, attach also the /var/lib/alsa/asound.state file.

Created attachment 736290 [details]
/var/lib/alsa/asound.state (after alsactl init)

The Master is muted there, too. Appearently, another task (maybe PulseAudio?) mutes the master volume before the alsactl store command.

Please, could you try this:

- rename /usr/bin/pulseaudio to /usr/bin/pulseaudio1
- kill pulseaudio (killall -9 pulseaudio)
- make sure that the sound works (alsactl init)
- reboot
- is Master unmuted (amixer get Master) now?

To restore the pulseaudio functionality, just rename pulseaudio1 back to pulseaudio (first step) and reboot.

I did what you requested, but after reboot I get error from amixer:

# amixer
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

amixer: Mixer attach default error: Connection refused

Sorry, the direct ALSA device access is required: 'amixer -c 0 get Master' .

# amixer -c 0 get Master
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 17 [55%] [-21.00dB] [on]
  Front Right: Playback 17 [55%] [-21.00dB] [on]

It looks ok, you may try 'speaker-test -D plughw:0' to get some sound now..

It appears that PuseAudio does something bad on shutdown....

Yes, I get noise... and 440 Hz sine wave if I use option "-t sine".

I installed two desktop machines with different hardware recently. This machine was installed from LXDE Live CD and the other was installed from the DVD which was transferred to a USB stick. There are no problems with audio on the other machine.

In addition to these machines I have upgraded four laptops with fedup from Fedora 17 to Fedora 18, and they have no audio problems.

Hello,

i can confirm this Bug on Fedora 18 with Virtualbox 4.2.12 on a Win7 Box. 

sudo alsactrl init works for me as workaround, too.

I too am getting no sound on Virtualbox 4.2.12 on Win7
I am using the 32 bit build of Fedora 18, installed with Live CD, all updates subsequently applied
Sound is restored if I run alsactrl init, but no sound after reboot.

"/sbin/alsactl -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main restore" did not seem to work

Before renaming PulseAudio, amixer ger master showed sound muted, though test from Sound GUI did produce sound with the init workaround
After renaming PulseAudio and rebooting, I could get sound with Speaker-test

How do you stop speaker-test?  If I abort with Ctrl-z, then I get error device or resource Busy if I try running it again

I really would like to see the audio working from bootup without manual intervention.

Fedora 9 32bit produces sound with no issues on VirtualBox

I am not sure if this may be related, but bug reporting tool indicates process /usr/bin/gnome-shell was killed by signal 11 (SIGSEGV)
Gnome shell version gnome-shell-3.6.3.1-1.fc18

gnome shell does run subsequently on its own though, as determined by system monitor.

Heres something to consider:
Uninstalling Alsa to PulseAudio backend (alsa-plugins-pulseaudio with /usr/bin/pulseaudio still renamed, then I can get audio from apps such as a video through Firefox.
speaker-test no longer needs to have a device specified, and I can re-run it if I kill it with ctrl-z

No sound though when desktop boots up like I get with Fedora 9.

However if I restore /usr/bin/pulseaudio, then I no longer have audio at all again.

I think I am getting somewhere:
With /usr/bin/pulseaudio restored, I would get sound if I select LFE in the sound mixer.   I get sound from Firefox video and speaker-test doesn't require specifying a device.
ALSA plugin still uninstalled
Once Alsa plugin is installed, no sound.
Uninstall plugin again, no sound until I reboot

I upgraded from Fedora 18 to Fedora 19 and I still have the problem. The "alsactl init" work-around works. Now I have kernel-3.11.2-201,fc19.i686 and pulseaudio-3.0-10.fc19.i686.

I don't use VirtualBox.

post the output of

pactl list


do your computer have the subwoofer or mono speaker which use master mono playback volume/switch?

as Intel8x0 only support stereo

you may need this patch

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=9e4229cfe03d441a01a0f1bd02972936048ae85d

Fyi - 

I performed a fresh install of Fedora 19 in the same VirtualBox environment that exhibited these issues originally (in 18) and the behavior did not return. This appears to be resolved (for me, at least) with a clean install of 19.

I posted comment 30 too early. After I booted the machine, I can't reproduce the problem any more! As written in comment 32, the problem indeed seems to be resolved!

I don't know why it did not work earlier today, but now it works. Perhaps it required one "alsactl init" and then a shutdown which saves the proper state??? Anyway, it works now!

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.