I simply uncommented the line "#load-module module-alsa-sink" in
/etc/pulse/default.pa and resarted pulseaudio to completely freeze my X. Mouse
was still working but I wasn't able to focus on any window, let alone type into
one or log out. After a reboot I noticed that with that setting my whole X
sessions starts up, but the screen remains blank.

According to syslog the module failed to load:

Jun 26 12:54:57 feivel pulseaudio[3128]: [pulseaudio] module.c: Failed to load module "module-alsa-sink" (argument: ""): initialization failed.

But that IMO hardly qualifies as a reason for the display to disappear. It'd also be
interesting to know why the module failed, but there doesn't seem to be
anything in the logs.

I tried using this module in an attempt to figure out why my sound doesn't work
correctly, or in other words, not at all when using the defaults.

Finally I'm not sure about the severity, but you can (and I did) lose data because of the loss of the X session.

Michael

Hi Michael,

This looks bad, but I cannot reproduce it.

Yes, this is expected, because that module needs the card details to
load. Is this message shown only once, or repeatedly? Does the log say
afterwards:

[pulseaudio] main.c: Module load failed.
[pulseaudio] main.c: Failed to initialize daemon.

?

Indeed.

What DE/WM are you using? Were there sounds being played at the moment?

This error is weird, because the module load failure should just cause
pulseaudio to exit. Perhaps something caused PA to respawn repeatedly?

For this, try using pavucontrol. There you can see if your card is
actually being picked up.

This does look bad so I'm not downgrading it yet.

Wouldn't it be better than to have the line look like this?

#load-module module-alsa-sink <card-details>

Only once.

Yes, it did.

gnome-shell, everything up-to-date sid, no sounds being displayed.

Does it do that if it's, like, killed at the beginning of a session?

I tried that before to no avail as there appeared to be something wrong with pulseaudio in general. Since then I found the problem, a misconfigured default sink in client.conf. I don't remember editing this file at all, but maybe that was an old config from back when.

Michael

Probably... but I don'y think we should carry a patch for that.

When pulseaudio is working, does sound play? IIRC, gnome starts some
sounds on startup.

Yes. By default, pulseaudio is autospawned whenever a connection is
attempted. You can disable this behavior in client.conf.

Did the gdm/xsession/any other log have something useful to say?
Currently I'm quite stumped as to where the bug may be.

Good that you have sound now, then.

Now it does, when the problem occured it didn't.

I'm not sure we're talking about the same thing here. Yes, of course it does
restart on error and similarily of course I had an error, but I only have one
error message in the logs. Besides, can it respawn so fast that it blocks the
rest of the system?

Same here.

What happens on your system if you enable that config line without the right
parameter? Honestly I haven't checked since finding my problem, but it may also
have to do with a non-existing default sink. Anyway, I shall try again and
report back.

Michael

Yes, I figured something like that was happening.

If a client tries to repeatedly connect then yes, it could respawn
pulseaudio pretty fast. But this seems unlikely, given that the log
does not show multiple messages. What happens if you have the wrong
line and disable autospawn?

On my system pa fails to start but everything else works normally.

Please do so, also trying with a disabled autospawn.

Then it works.

Bad idea, the misconfigured default-sink was not reason for my problems as just
"enabling" the alsa sink module created the same problem again. My screen
stayed black again. At the very same moment I had, like, seven pulseaudio
processes running at the same time, albeit no log entry at all this time.
However, I did manager to lose all my desktop configuration this time. I guess
the next time I try I better use a test user. :)

Michael

Ok, so it seems the problem is indeed autospawn related. I think
something within your session startup sequence cannot handle
pulseaudio dying. Do oy

Hmm, there seems to be some sort of race at pa startup, with multiple
pa daemons getting autospawned. But are there any more logs in syslog
(after the crash)? Because it seems strange to me that pa won't log
anymore if the config is the problem.

If you can reproduce this again, can you open a VT or ssh into your
system or otherwise poke into the pulseaudio daemons? Please install
the dbg packages and then try to get a backtrace of each of the
pulseaudio daemons (`gdb -p $pid`). Also please post the output of `ps
aux | grep pulseaudio` (before running gdb).

:( I'm sorry to hear that.


Saludos,
Felipe Sateler

I'm downgrading the severity seems this seems to (a) not happen to
other people, and (b) looks like it could be a bug in some client
rather than pulse.