[pulseaudio-discuss] Pulseaudio per-user instance unusable

[Joel A Fernandes]

Hi Colin,

Thanks for taking a look at the problem.

>> The pulseaudio server daemonizes but not always. Sometimes I have to
>> delete the .pulse-cookie file and .pulse/ directory to have it
>> daemonize. Only once it does daemonize, pactl is able to connect to it
>> and list modules but again audio players can't have it play anything.
>
> OK, so something is holding things up at startup. Can you work out what
> that is? Perhaps running PA manually via "pulseaudio -vvvvv" will give
> some clues?
>
>> Further, -vv -log-level pulseaudio options don't seem to generate very
>>  interesting debug information that helps.

I have uploaded the debug output here:

running as user-session: pulseaudio -vvvv --daemonize=false
http://utdallas.edu/~jaf090020/logs1/pa-debug-out-user

running in system mode:  pulseaudio -vvvv --system --daemonize=false
http://utdallas.edu/~jaf090020/logs1/pa-debug-out-sys

>> strace shows that it opens the sound device and then calls pause()
>> waiting for events to occur. This causes no one else to be able to
>> open the sound devices! pulseaudio just keeps it busy though its not
>> using the devices! suspend-on-idle module doesn't get loaded, though
>> the default.pa has it set.
>
> As a general rule noone else *should* be opening the audio devices. But
> I'm not sure what you mean by "calls pause()" here. There is no such
> call in PA source code.

Here is the strace output:
http://utdallas.edu/~jaf090020/logs1/strace-out

It seems that read() is blocking on fd 3 which is a pipe

I uploaded a list of file descriptor pulseaudio has open at the time
of the "hang":
http://utdallas.edu/~jaf090020/logs1/ls-proc-fd

>> I can confirm that the shared library "suspend-on-idle module" is
>> _not_ being loaded by looking at its process memory map
>> (/proc/../maps) though the /etc/default.pa file does have the option
>> enabled! I cannot use pactl to check if the module is loaded because
>> it doesn't connect to the pulse server (as mentioned above), but
>> atleast the memory map tells me it isn't.
>
> Does your user have a ~/.pulse/default.pa? If so, this file overrides
> the one on /etc/pulse/

No it doesn't have such a file in ~/.pulse/

>> * In system mode (passing --system)
>> clients such as pactl are able to connect and list modules etc and the
>> sound devices are not kept busy.
>>
>> However audio players that use pulseaudio (by settings in
>> /etc/asound.conf), report an error such as "Unable to create stream:
>> No such entity, Unable to set hw params". The distribution doesn't
>> have an asound.conf preconfigured so this isn't a problem as such but
>> I thought I'd mention it anyway.
>
> By audio players, do you include paplay?

I have tried aplay and mplayer.

> I'd need to see more details commands and logs here (both the
> output/errors from the command itself and the PA logs when this is run).
>
>>  So pulseaudio --system doesn't work but atleast it _does not_ keep
>> sound devices open. So other applications can still use alsa to open
>> sound devices without going through pulseaudio.
>>
>> For reference, I have uploaded my /etc/default.pa and /etc/system.pa
>> config files to:
>> http://utdallas.edu/~jaf090020/system.pa
>> http://utdallas.edu/~jaf090020/default.pa
>>
>> I would appreciate any suggestions on what could be a possible cause,
>> and a viable solution to the problem.
>
> As well as the config files, Please also upload the output from running
> PA (as a normal user with -vvvvv) from the terminal.
>
>
> All I'd say is to follow some basic safety steps when running a per-user
> daemon:
>  1. Always run client apps as the same your you run PA daemon as.

pulseaudio is started after logging in as root into the gnome session.
The gnome user starting the pulseaudio user session *is* root. Do you
have thoughts about this?

Just if it helps, here is the process memory map at the time of the
unresponsiveness when run as a user instance:
http://utdallas.edu/~jaf090020/logs1/mmaps

Thanks,
Joel