Bug 832628 - Pulseaudio unstable and inconsistent
Pulseaudio unstable and inconsistent
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
17
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-15 23:32 EDT by dch
Modified: 2013-07-31 23:08 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 23:08:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dch 2012-06-15 23:32:41 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: [50] Power Management version 2
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [130] 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
Comment 1 dch 2012-06-19 23:21:02 EDT
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?
Comment 2 Brendan Jones 2012-06-20 02:17:17 EDT
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
Comment 3 dch 2012-06-20 12:30:34 EDT
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
#set-default-sink output
#set-default-source input

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.
Comment 4 Brendan Jones 2012-06-20 17:36:52 EDT


> 
> 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;
pulseaudio --kill
pulseaudio -vvvv

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.
Comment 5 Fedora End Of Life 2013-07-03 19:58:05 EDT
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.
Comment 6 Fedora End Of Life 2013-07-31 23:08:39 EDT
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.

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