[pulseaudio-discuss] pulseaudio timing out accepting connections

[Brian J. Murrell]

On Wed, 2008-12-10 at 11:29 -0500, Sean McNamara wrote:
> Hi again Brian,

Hi,

> Well, you can't find this out for sure without getting pulseadudio to
> stop looping like it is. But you can just restart PulseAudio with
> `killall -9 pulseaudio; pulseaudio --start`. Then restart any apps
> that are (were) playing audio.

Will do.

> 
> Install the 'pavucontrol' package, then start "PulseAudio Volume
> Control".

Yeah, I have that installed and am using it already.  It of course
doesn't work with this stuck pulseaudio server.

> Then browse to the 'Output Devices' tab.

OK.  I guess I was asking if there is a way to do this without
restarting the server, which I will go ahead and do if you don't need
anything more from it.

> If your PulseAudio
> configuration is also stock, you should notice:
> 
> 1. All of your enumerated ALSA devices (except the bluetooth) are
> listed in some form or another, thanks to module-hal-detect.

In fact, IIRC, it does not enumerate my nVidia HDA device and I had to
add:

load-module module-alsa-sink device=front:CARD=NVidia,DEV=0

to my default.pa.  But this is probably a separate issue.

> What information are you using to make this conclusion? pavucontrol?

Yes, as above.

> That's not so bad - is it really too much of a pain to restart
> Rhythmbox and PA as described above? ;)

Oh.  Well, usually there are umpteen ESD clients connected too.  But
yes, if it were just rhythmbox, indeed, not so painful at all.

> Rhythmbox is using gstreamer, and GNOME configures it (through GConf)
> to use pulsesink, which uses the native PulseAudio protocol. Good.
> This usually works 100% -- it's one of those really well-debugged
> PulseAudio use cases. Strange that you're having this problem with
> that.

Yeah, I would have thought it be a common and well debugged use case.

> Well, any apps that say they are using ALSA to play sound are
> (probably) going through the ALSA<->Pulse plugin layer if they are
> opening the "default" device.

Right, but I can't determine that until I restart the server.

> I personally have used an MCP51 HD Audio controller

That's the one that doesn't show up without the default.pa addition.
But that is a secondary (i.e. VIOP headset) audio controller.  My main
output is the SoundBlaster.

> Yeah, this is ALSA card 2. So the raw device hw:2 would be your
> logitech camera's sound chip. Although it would appear that this card
> probably only has capture, not playback.

Yes, indeed.  I don't recall if it shows up as a device in pulseaudio or
not.  I could confirm when I restart the server.

> Restart PulseAudio with `killall -9 pulseaudio; pulseaudio --start`.
> Then restart any apps that are (were) playing audio.

Right, but for "ESD client" I don't necessarily know what they are.

> That's up to the client whether they want to retry. Some apps will
> retry continuously in a loop forever; some will retry a finite number
> of times and error; some will error as soon as it fails at all.

Hrm.  This seems strange to me.  I'd have thought all apps would be
going, ultimately, through some pulseaudio (supplied) client library.
Wouldn't that sort of behaviour be up to the pulseaudio developers via
that library?  Anyway, this is a digression.

> If the pulseaudio server is flat-out *killed*, then:
> 
> 1. The UNIX socket used for native PulseAudio communication is closed.

Right.

> 2. The TCP socket used for native PulseAudio is closed, if you had it
> open with module-native-protocol-tcp.

Right.

> 3. Any apps trying to open either of these sockets will get
> "Connection Refused" immediately, just like trying to ssh or ftp to a
> box that isn't running a respective sshd or ftpd.

Exactly.

> If the pulseaudio server is still running, then the sockets are open;
> but if PA is caught in some kind of loop or blocking, it won't be
> reading from the socket; therefore the socket's receive queue will
> fill up, and both the client and server will hang.

Agreed.  But if the server is killed while clients are in that state,
ideally, they should get an error and try to reconnect to the new server
that starts up.

> Yes, see above. But I interpreted your original message as saying that
> the pulseaudio process is running, not killed.

It is running right now.  I'm trying to determine what a pain it's going
to be after I restart the server.

> If you want more real-time troubleshooting, I'm allquixotic on
> FreeNode IRC: chat.freenode.net/8001, #pulseaudio.

Ahhh.  Just reached out to you.  :-)

b.