Description of problem: After a login into a clean installation there is no audio device configured, only "Internal audio analog stereo" is present. Due to 'pactl list | grep device-manager' the module is loaded. If I kill pulseaudio with 'pulseaudio --kill', load it again with 'start-pulseaudio-kde' and restart systemsettings there are three devices listed (the used backend is xine): 1. VIA 8237 2. Default 3. PulseAudio But only the first one is working when I play the test sound. Version-Release number of selected component (if applicable): phonon-4.3.80-2.fc13.x86_64 phonon-backend-gstreamer-4.3.80-2.fc13.x86_64 phonon-backend-xine-4.3.80-2.fc13.x86_64 alsa-plugins-pulseaudio-1.0.21-2.fc12.x86_64 kde-settings-pulseaudio-4.4-6.1.noarch pulseaudio-0.9.21-3.fc13.x86_64 pulseaudio-libs-0.9.21-3.fc13.x86_64 pulseaudio-libs-glib2-0.9.21-3.fc13.x86_64 pulseaudio-module-x11-0.9.21-3.fc13.x86_64 pulseaudio-utils-0.9.21-3.fc13.x86_64 How reproducible: ever Steps to Reproduce: 1. login into a clean user account in a recent rawhide installation 2. systemsettings -> Multimedia 3. pulseaudio --kill && start-pulseaudio-kde 4. systemsettings -> Multimedia Actual results: No proper audio device is configured Expected results: working audio device Additional info: If I switch from xine to gstreamer backend the devices are cleaned up and only the "Internal audio analog stereo" device is present again. When I restart pulseaudio the "VIA8237" and "Default" devices are back but none are playing the test sound. # lspci -vv 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) Subsystem: Micro-Star International Co., Ltd. Device b010 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin C routed to IRQ 22 Region 0: I/O ports at ed00 [size=256] Capabilities: <access denied> Kernel driver in use: VIA 82xx Audio Kernel modules: snd-via82xx
Created attachment 383237 [details] /var/log/messages right after login Most interesting lines from /var/log/messages: Jan 12 14:00:56 localhost rtkit-daemon[2366]: Sucessfully made thread 2358 of process 2358 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Jan 12 14:00:56 localhost rtkit-daemon[2366]: Failed to open '//2358/limits': Permission denied Jan 12 14:00:56 localhost rtkit-daemon[2366]: Failed to open '//2358/limits': Permission denied Jan 12 14:00:56 localhost rtkit-daemon[2366]: Failed to open '//2358/limits': Permission denied Jan 12 14:00:56 localhost rtkit-daemon[2366]: Failed to open '//2358/limits': Permission denied Jan 12 14:00:57 localhost rtkit-daemon[2366]: Sucessfully made thread 2465 of process 2465 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Jan 12 14:00:57 localhost pulseaudio[2465]: pid.c: Daemon already running. Jan 12 14:00:57 localhost rtkit-daemon[2366]: Sucessfully made thread 2471 of process 2471 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Jan 12 14:00:57 localhost pulseaudio[2471]: pid.c: Daemon already running. Jan 12 14:00:57 localhost rtkit-daemon[2366]: Sucessfully made thread 2476 of process 2476 (/usr/bin/pulseaudio) owned by '500' high priority at nice level -11. Jan 12 14:00:57 localhost pulseaudio[2476]: pid.c: Daemon already running.
please (re)test against kdemultimedia-4.3.90-2 (or newer).
fyi, you're seeing the kmix/pa integration work/patches we're borrowing from mandriva/colin_guthrie here.
ok, nevermind me, kmix isn't the issue here, reassigning to kdebase-runtime (phonon kcm) for now.
This isn't a KDE 4.4 issue at all (it's a Phonon issue and we already have Phonon 4.3.80 everywhere), so I'm taking this off the KDE 4.4 tracker. To me, this looks a lot like a PulseAudio bug, should we reassign it there? (But module-device-manager is probably not Lennart Poettering's highest priority.)
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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. Thank you for reporting this bug and we are sorry it could not be fixed.