Description of problem: No working audio on Fedora 18 x64 running as a VirtualBox guest. This is using Fedora 18 KDE - I have not tried it with Gnome. This same issue occurs across multiple systems (two). Host OS is Windows 7 on both systems. Fedora 17 running as a guest on these same machines has no sound issues. Simply running 'alsactl init' on the system following login seems to correct the issue but it does not persist a reboot, causing this command to need to be run again each time. Version-Release number of selected component (if applicable): Current How reproducible: Consistently Steps to Reproduce: 1. Install Fedora 18 (KDE) on an x64 VirtualBox guest 2. Login and test any sounds [failure observed] 3. open a command prompt and run 'alsactl init' 4. test sounds again [success] 5. reboot system - back to step 2 Actual results: Broken audio system Expected results: Out-of-the-box functioning audio Additional info: Output of alsactl init command... [user@foobar ~]$ alsactl init Found hardware: "ICH" "SigmaTel STAC9700,83,84" "AC97a:83847600" "0x8086" "0x0000" Hardware is initialized using a generic method Some more diag commands... [user@foobar ~]$ lspci | egrep -i 'audio|sound' 00:05.0 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 01) [user@foobar ~]$ dmesg | egrep -i 'audio|sound' <no output from command> Seeing many occurrences of the following messages in /var/log/messages... Jan 29 12:02:17 foobar rtkit-daemon[622]: Successfully made thread 1673 of process 1673 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11. Jan 29 12:02:19 foobar pulseaudio[1673]: [pulseaudio] alsa-util.c: Disabling timer-based scheduling because running inside a VM. Jan 29 12:02:20 foobar rtkit-daemon[622]: Successfully made thread 1727 of process 1727 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11. Jan 29 12:02:20 foobar pulseaudio[1727]: [pulseaudio] pid.c: Daemon already running. Jan 29 12:02:20 foobar rtkit-daemon[622]: Successfully made thread 1729 of process 1729 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11. Jan 29 12:02:20 foobar pulseaudio[1729]: [pulseaudio] pid.c: Daemon already running. Jan 29 12:02:22 foobar pulseaudio[1673]: [alsa-sink] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Jan 29 12:02:22 foobar pulseaudio[1673]: [alsa-sink] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_intel8x0'. Please report this issue to the ALSA developers. Jan 29 12:02:22 foobar pulseaudio[1673]: [alsa-sink] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
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.