Red Hat Bugzilla – Bug 832628
Pulseaudio unstable and inconsistent
Last modified: 2013-07-31 23:08:39 EDT
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
Subsystem: Acer Incorporated [ALI] Device 0504
Flags: bus master, fast devsel, latency 0, IRQ 47
Memory at c0700000 (64-bit, non-prefetchable) [size=16K]
Capabilities:  Power Management version 2
Capabilities:  MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities:  Express Root Complex Integrated Endpoint, MSI 00
Capabilities:  Virtual Channel
Capabilities:  Root Complex Link
Kernel driver in use: snd_hda_intel
I have three audio devices:
Intel to analog
Intel to HDMI
Bluetooth headset that I use for Skype
Only the last of the three consistently works as intended. Half the time, when I boot up, Pulse selects the HDMI output and half the time Pulse selects the analog output. The selection that Pulse makes has no correlation to what is connected or what had been connected. I can go days without connecting to HDMI yet pulse will select the output after properly selecting the analog output the prior day.
If I get the KDE log-in sound I know that pulse has made the WRONG selection. Indeed, if it boots into the HDMI setting (which means that I have no sound since I'm never connected to the HDMI on boot), then try to adjust the hardware and then find that the analog is unavailable and then quit the menu without clicking on apply - somehow the system produces the error sound when no other sound is available. Needless to say, that is spectacularly frustrating.
Most of the time when the HDMI is incorrectly selected the analog output is not even reflected in the hardware list. The only workaround that I have found is
# pulseaudio --kill
# pulseaudio -D
Lately (I think since upgrading from F16 to F17) even if the system selects the correct configuration on boot, sound stops working at some point and the system configuration displays the raw device list without any hardware options
Tried a back-ported Pulseaudio 2.0. Same problems. IIRC, this was introduced circa Fedora 9. I have had a number of different computers and Pulseaudio never worked and probably never will. While it used to be easy to remove, that has become increasingly difficult. Does anyone ever do a Google search on Pulseaudio? Seriously. This is a failed "experiment." Enough already.
BTW, have people stopped responding to bug reports?
Can you please man pulse-daemon.conf and set the loglevel to debug and redirect it to syslog.
When you experience problems grep the output from /var/log/messages and attach here - as it stands there is nothing useful in this bug report.
Also consider setting the default sink/source in either /etc/default.pa or using pacmd. It sounds like you've set the bluetooth as fallback and after restart pulse arbitrarily chooses one of you others when the bluetooth is not available
(In reply to comment #1)
> BTW, have people stopped responding to bug reports?
This is really not going to encourage people into helping you
1. I have created etc/pulse-daemon.conf and configured it as requested.
2. default.pa is located at /etc/pulse. I have "set" nothing. It is as it came. Neither man default.pa nor man pacmd provide the necessary information to set the default sink/source. the file currently includes:
### Make some devices default
For that matter, the documentation does not permit the average user to appreciate the difference between a source and a sink. Neither list-sources nor list-sinks (from within pacmd) provides me with any useful information. In point of fact I don't know what on earth a "sink" is nor how that term could possibly apply to a sound device.
As an aside, I am a quality-management consultant with a national reputation. I ended my career as the CEO of one of my clients - a faily large organization. Freedesktop.org has a tendency to make things esoteric by design. Arcane is not a virtue. A sound system is comprised of inputs and outputs - elegance in simplicity. Seriously.
> As an aside, I am a quality-management consultant with a national
> reputation. I ended my career as the CEO of one of my clients - a faily
> large organization. Freedesktop.org has a tendency to make things esoteric
> by design. Arcane is not a virtue. A sound system is comprised of inputs and
> outputs - elegance in simplicity. Seriously.
You'd be surprised how many pulseaudio bugs are not pulseaudio bugs but kernel/alsa/selinux/pam etc etc. ITs determining the cause which is the issue. Please provide syslog output (grep pulseaudio /var/log/messages) when the erro occurs. If you can recreate the issue on demand try:
rm -rf ~/.pulse;
and post the output here.
As an aside, I have no affiliation with freedesktop, nor redhat, nor pulseaudio.
If you have any grievances, direct your negativity upstream - it has no place here.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 '17'.
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 17'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 17 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 17'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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.