Re: Glitch-Free PulseAudio in Rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20.05.08 05:47, Kevin Kofler (kevin.kofler@xxxxxxxxx) wrote:

> 
> Lennart Poettering <mzerqung <at> 0pointer.de> writes:
> > Also, if you claim that I neglect longstanding important bugs, then
> > please be more specific and tell me exactly the bug numbers.
> 
> There's this one:
> https://bugzilla.redhat.com/show_bug.cgi?id=438284
> "Sometimes, PulseAudio fails to start"
> It might actually be a symptom of several completely different bugs. What I'm 
> seeing in KDE is that sometimes, for no apparent reason, no PA is running, 
> starting it with pulseaudio -D just starts it. But that only happens sometimes. 
> I know this is not very useful as a bug report, I'll have to check the logs 
> more carefully to see if I can figure out what happens: maybe PA starts up and 
> then kills itself due to CPU overload? I'll let you know once I figure out 
> more.

I was pretty sure I fixed that issue, as I wrote in the bug report.

/me reads the sources. 

Ah, ok, it's like this:

I actually did fix this issue, but not completely. PA does check the
exename of an existing PID file to check if it is actually pa that
owns the PID if it is still running. However, I added this fix only when
killing an existing daemon (i.e. -k), not when starting a new
one. It's trivial to fix.

Hmm, this bug seems to be triggered only by KDE. Apparently in KDE PA
is not configured for module-x11-xsmp? (could anyone who actually runs
KDE check this?) if that module is not loaded libX11 will forcibly
terminate us as soon as the X11 connection goes away. This will cause
the PID file to not be removed properly on shutdown.

> Then there's this weird issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=361891

What's weird about this issue is primarily the setup (i.e. running
arts on top of pa). If you stack sound servers like this it is a call
for trouble. Just don't do it. Sound servers should live near the
hardware, not on top of each other. I mean, it would be great if this
worked fine, but please understand that bug reports where the first
thing I think when reading it is "Oh my, why do they want to do weird
things like that?" are not the kind of bug reports that become a top
priority for me to fix. And the fact that it's a bug in conjunction
with obsolete, bit-rotten C++ software doesn't help it either.

If you trigger one of those CPU overload issues, than this is most
likely due to the software entering some kind of busy loop. If you
want to fix this, you need to find out why we enter this busy
loop. Apparently the operation that should normally sleep for IO
doesn't sleep for IO in this case. Usually this means that an IO
condition that was signalled earlier was not handled as it should and
thus not reset. Unfortunately bugs like this don't leave any useful
coredumps, error messages or back traces and so can only be fixed by
spending some time in gdb to figure out what happens.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux