On Wed, 2013-05-15 at 13:05 +0300, Tanu Kaskinen wrote:
> On Wed, 2013-05-15 at 10:13 +0530, Arun Raghavan wrote:
> > Hello,
> > This one is really intrusive (at least to m-z-publish), but deals with a
> > long-standing bug which is also a 4.0 blocker[1] where PulseAudio sometimes
> > takes 20s for daemon startup to complete.
>
> There's no evidence that module-zeroconf-publish has anything to do with
> 58758.
I can reproduce intermittent ~20s startup delays that are clearly in
module-zeroconf-publish, which is why I introduced this as a fix for it.
It's easy enough to reproduce, just run this in a few times and see when
m-z-publish gets loaded. avahi-daemon needs to not be running.
pulseaudio -vvvv 2>&1 | grep zeroconf
> If the 20s delay is caused by some D-Bus message timing out, have you
> investigated what message is timing out and why? I don't think it's
It's a ping message to the Avahi daemon (which is not running), and the
timeout takes this long. The relevant code is:
http://git.0pointer.de/?p=avahi.git;a=blob;f=avahi-client/client.c#l564
> expected behaviour, so fixing this in PulseAudio is working around a bug
> elsewhere. I support any patches that remove blocking IO from the main
The default timeout is 25s. So a long block is not unexpected. However,
I don't see the timeout take this long every time. I'm trying to find
out why this is.
> thread, though, so I'm fine with having the fix anyway, but pushing it
> to master at this point doesn't seem justified (not a regression, and
> the bug impact seems very limited).
This bug's been open downstream for 6 months now, and is biting a number
of users, so I'd like to address fixing it (which is also why I'd marked
it as a 4.0 blocker in the first place).
-- Arun
