[pulseaudio-discuss] pulseaudio timing out accepting connections

[Sean McNamara]

Hi again Brian,

On Wed, Dec 10, 2008 at 10:17 AM, Brian J. Murrell
<brian at interlinx.bc.ca> wrote:
> On Wed, 2008-12-10 at 10:01 -0500, Sean McNamara wrote:
>>
>> Are you running PA in realtime mode? Does top say that its priority is "RT"?
>
> Nope.  It says it's "20".

OK. I just learned that rtpoll can operate without the process being
of the 'RT' priority; in fact, it just handles realtime signal
handling on a per-LWP basis (per thread, so only the alsa-sink thread
gets RT signals).

>
>> Yeah, it sounds like PA is stuck in a tight loop trying to access
>> ALSA. I've never encountered this before, and I've used Intrepid a
>> bit. I'm thinking either you have a custom compiled version of a
>> library that PA depends on;
>
> Nope.  Everything here is stock.
>
>> or, you have some strange hardware.
>
> # cat /proc/asound/cards
>  0 [Live           ]: EMU10K1 - SBLive! Value [CT4832]
>                      SBLive! Value [CT4832] (rev.7, serial:0x80271102) at 0x9c00, irq 17
>  1 [NVidia         ]: HDA-Intel - HDA NVidia
>                      HDA NVidia at 0xfe024000 irq 22
>  2 [U0x46d0x8c5    ]: USB-Audio - USB Device 0x46d:0x8c5
>                      USB Device 0x46d:0x8c5 at usb-0000:00:0b.1-2, high speed
>  3 [Bt878          ]: Bt87x - Brooktree Bt878
>                      Brooktree Bt878 at 0xfdafe000, irq 16
>
> AFAIK, pulse is just using the EMU10K1, which is my main speakers.

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.

Install the 'pavucontrol' package, then start "PulseAudio Volume
Control". Not sure which menu it's in; you can also launch it
indirectly through PulseAudio Device Chooser (padevchooser). Last
resort: run it from the console as a user.

Then browse to the 'Output Devices' tab. 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.
2. Your default PA sink will have the "Default" item checked in the
drop-down combo box (available by clicking the button with the arrow).
There's only one default at a time, and you can change it easily :)
3. Make sure the device you want is selected. If you can reproducibly
cause PA to hang on one device but not the others, that's a defect.
Well, it's a defect already that this happened :)

>
> Strangely pulse does not detect the other devices.

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

>
>> Can you tell me what kinds of applications are currently active as
>> sinks on your PA?
>
> Just Rhythmbox at the moment.

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

>
>> What protocol are they connecting through?
>
> Whatever gnome is providing.  I have the sound properties in Gnome set
> to use Pulseaudio.

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.

>
>> Any
>> ALSA<->Pulse apps?
>
> Not sure.  How could I determine that for you?

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.

>
>> Just as data points. Also, post an lspci
>
> 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
> 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
> 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
> 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
> 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
> 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
> 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
> 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
> 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
> 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
> 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
> 00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce 6150] (rev a2)
> 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
> 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
> 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
> 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
> 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
> 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
> 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
> 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
> 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
> 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
> 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
> 04:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
> 04:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> 04:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> 04:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
> 04:09.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)

I personally have used an MCP51 HD Audio controller with Ubuntu
Intrepid, and I was satisfied with the result. Never had any hangs
like that.

>
>> (and also
>> an lsusb if you have a USB soundcard).
>
> No USB soundcards.  Oh.  I guess the mic on the webcam counts.
>
> Bus 002 Device 003: ID 046d:08c5 Logitech, Inc. QuickCam Pro 5000
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 013: ID 03f0:1411 Hewlett-Packard PSC 750
> Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

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.

>
>> Nope, there's no guarantee of that.
>
> ~sigh~  So in order to get everyone happy again, I have to restart my
> entire desktop session?

No,

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

>
>> Clients have control over the
>> terms under which they try to connect to PA.
>
> But if a pulseaudio server goes away (is killed) shouldn't a client see
> that and try to reconnect?

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.

If the pulseaudio server is flat-out *killed*, then:

1. The UNIX socket used for native PulseAudio communication is closed.
2. The TCP socket used for native PulseAudio is closed, if you had it
open with module-native-protocol-tcp.
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.

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. To protect against
this, the socket I/O has a timeout, which is what you're hitting in
your client: the client expects PulseAudio to drain the receive queue
at the other end of the socket, but it's not, because it's somehow too
busy to do that.

>
>> If they're trying to
>> communicate and they're timing out,
>
> Wouldn't they get something more positive, along the lines of an
> ECONNREFUSED from a pulseaudio server that has been killed?

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

>
>> if
>> they connect and get an error, they may also give up and refuse to
>> proceed. With some apps you may have to restart them. Others might
>> just keep a full buffer of audio and unload it as soon as they can get
>> back into PA.
>
> OK.


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

-Sean

>
> b.
>
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>