[pulseaudio-discuss] Weird bug with Pulseaudio connections.
smcnam at gmail.com
Tue Apr 12 08:40:15 PDT 2011
On Tue, Apr 12, 2011 at 11:08 AM, Robbie Smith <zoqaeski at gmail.com> wrote:
> Hello everyone
> I haven't posted to this list before, not being much of a developer, but
> I've been having some really odd bugs pop up almost at random with
> Pulseaudio. Usually they disappear days or weeks later with just as much
> warning as when they occur, and I'm never sure whether I've solved them
> or whether my computer is just ... odd.
> Anyway, the main nature of the bugs is that Pulseaudio seems to have
> difficulty connecting to either ALSA, my sound card, or something else.
> I can't quite explain what's going on; I've tried reading
> through /var/log/errors.log and noticed that it is "failing to set
> hardware parameters with a connection timeout". I'm not quite familiar
> with how Pulseaudio works, but from the odd arcane messages I get, I'm
> guessing that somewhere, somehow, it's trying to talk to my soundcard
> and my soundcard is responding with "Computer says no."
> The weird bit is that the "bug", if that's what it is, gets triggered by
> almost anything. Commonly, opening pavucontrol will kill sound for a few
> seconds to a few minutes: sound only resumes once I've killed
> pavucontrol, and a dialog/error box will pop up alerting me to a
> connection timeout. Given that pavucontrol is a really useful way of
> manipulating the volume of individual programs this can be quite
> Before I describe what methods I've attempted to solve the problems,
> I'll just briefly list my OS. I'm currently running Arch Linux, with (as
> of tonight) the latest (stable) kernel 126.96.36.199 according to my update
> logs. Pulseaudio itself is version 0.9.22. My desktop "environment" is
> Openbox, and I'm calling it within consolekit and polkit and whatever
> else it needs.
> The command being called from ~/.xinitrc is
> exec /usr/bin/ck-launch-session /usr/bin/openbox-session
> start-pulseaudio-x11 is also being called in this file, a few
> lines up.
> As for setting up my system, I think I've tried just about every guide
> there is, and there's a lot of conflicting information out there,
> especially on user and group permissions. Sometimes following a guide
> for the sake of it fixes the bug; that being said, I've already had the
> settings it recommends so I have no idea what's going on.
> I've experimented with setting sinks, with setting sound outputs,
> everything. But time and again this weird bug shows up, pulseaudio fails
> to load, or the pavucontrol applet brings the sound to a halt, or
> something. And without warning it'll start working again, usually within
> hours of me asking on a forum somewhere about the bug.
> As far as I know I've installed everything that might be needed. I used
> to like Pulseaudio, the whole control-volume-of-individual-streams is
> great. But it just doesn't work (between some of the time to most of the
> time). And yet it's one of those features, which once you get used to
> it, is really hard to live without.
> How can I fix this once and for all? If there's any configuration
> details or similar that you might need to be able to confirm or identify
> the bug or whatever conditions are causing this, let me know what you
> need to know and I'll try to assist in any way I can.
Posting your output of alsa-info.sh <
> would be good for starters.
Also, a bit of an intuitive guess, but maybe when pulseaudio releases
the soundcard (you have module-suspend-on-idle loaded, right?) another
app is coming in and hogging the soundcard meanwhile. Since you
haven't posted anything from pulseaudio logs, I can't be sure if this
is the problem, though.
If indeed something is taking the ALSA sound device while pulseaudio
relinquishes it, you could try disabling module-suspend-on-idle in
/etc/pulse/default.pa. Just comment out the load-module line for it.
If it doesn't fix your issue, re-enable the module because it saves
power (especially relevant on a laptop).
Last stab in the dark (I think I've made enough of them in this post
already): Arch Linux is not known for being well-tested and
integrating packages into the distro. The problems you're experiencing
may be an artifact of "following guides" out there on the internet,
without really knowing what the guides are guiding you to do (and
sometimes/often the guides are incorrect or obsolete). For that
matter, you should take *my* advice with a grain of salt, too. But if
you want something that just works, kick the tires on the latest
stable of one of the premiere distros (Ubuntu, Fedora, OpenSUSE) and
see if you can reproduce the problem. If not, the error is most likely
something you did (or something ArchLinux fails to do), or a distro
patch has been included in the kernel, ALSA, or pulseaudio that fixes
your issue but your distro hasn't picked it up.
You won't be able to fix your issue "once and for all" unless you can
isolate the individual patch to the kernel/ALSA/Pulse that fixes your
issue, but using a distro where you don't hit this problem is a good
start, and I'm betting you won't see this problem manifest in at least
one of the big three.
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
More information about the pulseaudio-discuss