[pulseaudio-discuss] Pulseaudio per-user instance unusable

[Joel A Fernandes]

Hi Colin, Sean,

Switching to pulseaudio 0.9.22 fixes all the issues. Thanks!

Regards,
Joel


On Fri, Jul 8, 2011 at 4:51 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Joel A Fernandes at 08/07/11 03:51 did gyre and gimble:
>> Hi!
>>
>> I will be as descriptive as possible about a certain issue pulseaudio
>> I have had keeping audio devices "busy" and discuss what I have tried
>> and what I see.
>>
>> I'm using a 2.6.32 kernel (have also used a 2.6.39 kernel) with
>> PulseAudio 0.9.15 (Angstrom distribution) on a BeagleBoard (tried C5
>> and -xM).
>
> As per Sean's comment, both the kernel and PA version are pretty old
> now. I'd advice using newer versions if at all possible.
>
> While I can offer general advice, I can't really give code-level support
> for such an old version of PA.
>
>> The problems appear to be two-fold.
>> - Firstly, the utilities: pactl, pacmd etc are unable to connect to
>> the pulse server most of the times (so its kind of intermittent)
>> - Second, aplay cannot use pulseaudio as it throws errors as mentioned
>> below, and, cannot not-use pulseaudio as it keeps the sound devices
>> busy :) So we're stuck!
>>
>> I have tried running pulseaudio in both system and user modes.
>>
>> * When started up as a per-user instance ,which is started up by
>> start-pulseaudio-x11 like so:
>>  /usr/bin/pulseaudio --start "$@"
>>
>> 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.
>
> Try more v's ;)
>
>> 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.
>
> If you mean various select() calls to wait for fd devices then this is
> intended, although I'd have thought that suspend-on-idle should also
> kick in at some point....
>
> It seems that if default.pa has suspend-on-idle specified but it's not
> being loaded, then something more sinister is happening. I'd need to see
> log output from pulseaudio -vvvvv to say more.
>
>
>> 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/
>
>
>> * 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'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.
>  2. Always check that other client configurations are not changing
> where you connect to (e.g. a client.conf, or PULSE_SERVER env var or
> PULSE_SERVER X11 property on the root window).
>  3. Debug connection problems with "PULSE_LOG=99 pactl stat"
>
>
> Point 2 in particular is an issue if you are SSH'ing in to this box
> remotely. If you have X11 forwarding enabled (which is typical) then the
> X11 properties will be telling your login on the remote box to try and
> connect back to the machine you SSH'ed in from.
>
> ("xprop -root | grep PULSE_" is your friend here)
>
> Either disable X11 forwarding or run "pax11publish -r" before SSHing.
>
> HTHs
>
> Col
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mageia Contributor [http://www.mageia.org/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
>