[pulseaudio-discuss] Hpw to start the pa server

Wed Apr 14 08:53:19 PDT 2010

'Twas brillig, and Gene Heskett at 14/04/10 16:38 did gyre and gimble:
> On Wednesday 14 April 2010, Colin Guthrie wrote:
>> 'Twas brillig, and Gene Heskett at 13/04/10 01:38 did gyre and gimble:
>>> On Monday 12 April 2010, Colin Guthrie wrote:
>>>> 'Twas brillig, and Gene Heskett at 12/04/10 20:29 did gyre and gimble:
>>>>> draksound, re-enabled, was on before by other means, and enabled user
>>>>> switching.  No sound yet.
>>>>> pacmd.ls.out attached.
>>>>
>>>> Hmm, what is strange here is that it shows no streams at all - e.g. no
>>>> sink inputs. To back this up, all the sinks are in a suspended state.
>>>>
>>>> The volumes are all incredibly high - well over the 100% mark. How were
>>>> these volumes set? Most tools only allow volumes up to 150%.
>>>
>>> I _think_ it was paprefs that allowed me to go as high as 400%.
>>
>> Ahh no, I think it was likely paman... it's evil :p Generally speaking
>> paman and padevchooser are obsolete... I should probably not ship them
>> really but some people do like them despite their evilness :p
> 
> paman runs here, padevchooser doesn't output anything, shows a .4%
> memory usage, and responds to a ctrl+c to quit.

It's an applet that sits in the system tray and shows popups and a
submenu and stores it's settings in a strange way that conflict with
normal usage. Don't use it :p

>> Can you do the following for me:
>>
>> 1) Enable PA in draksound and reboot.
>> 2) Login.
>> 3) ps aux | grep pulseaudio
> [gene at coyote gene]$ ps aux | grep pulseaudio
> root     17772  0.0  0.0 206580  2264 ?        S<sl Apr12   0:00 /usr/bin/pulseaudio --start --log-target=syslog
> gene     22513  0.0  0.1 221408  4904 ?        S<sl Apr13   0:13 /usr/bin/pulseaudio --start --log-target=syslog
> gene     28277  0.0  0.0   7372   948 pts/6    R+   10:28   0:00 grep --color pulseaudio

OK, the version running as root is probably cocking things up here. Can
you find out why it was started and kill it if possible? You'll want to
do this before logging in as your own user.

>> 4) paplay /usr/share/sounds/ia_ora-startup.wav
> Silence, does take a while to get the prompt back

I suspect the silence is due to the fact that you are now running your
own PA daemon, but the root users own PA daemon is also running, hogging
the sound card and not letting your user access it at the same time.
Running PA as root is a generally bad idea so try to avoid it at all costs.

>> 5) (in a separate terminal, leave running and retry until it starts
>> properly): pulseaudio -k; pulseaudio -vvvvv
> All I can get, tried 30-40 times, is
> [gene at coyote gene]$ pulseaudio -k; pulseaudio -vvvvv
> I: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted

> E: pid.c: Daemon already running.
> E: main.c: pa_pid_file_create() failed.
> 
> However, executing the above line, does report a connection lost for the 
> line below if its been run. Expected...

Hmm, OK, it seems to autospawn far too quickly for you (machine quicker
than mine :D).

> 
>> 6) paplay /usr/share/sounds/ia_ora-startup.wav
> 
> [gene at coyote gene]$ time paplay /usr/share/sounds/ia_ora-startup.wav
> 0.03user 0.00system 0:07.75elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+869minor)pagefaults 0swaps
> 
>> 7) cat ~/.pulse/client.conf
> 
> [gene at coyote gene]$ cat ./pulse/client.conf
> cat: ./pulse/client.conf: No such file or directory

You've got a typo. I said "cat ~/.pulse/client.conf" type exactly that.

>> 8) cat /etc/pulse/client.conf
> [gene at coyote gene]$ cat /etc/pulse/client.conf

Cool. That's what I expect it to be. Ticked off the list :)

>> 9) xprop -root | grep PULSE
> [gene at coyote gene]$  xprop -root | grep PULSE
> [gene at coyote gene]$

Thanks. With a normal clean startup process this should contain
something but running pulseaudio -k or padevchooser can mess it up.
Being empty is good tho' and should still work fine.

>> 10) env | grep PULSE
> [gene at coyote gene]$ env | grep PULSE
> [gene at coyote gene]$

As above. I didn't expect anything to be here, but worth double checking.

> However,
> [root at coyote Daily]# env |grep pulse
> CANBERRA_DRIVER=pulse
> [root at coyote Daily]#

Yeah that's fine (this is actually one of the reasons that PA is
autospawned so quickly above :D)

>> Just to keep things simple, I'd load up paprefs and untick the box to
>> create a combined output (it's the last tab IIRC). Then the above sink
>> wont load which keeps our setup cleaner.
> 
> Already did, that is the condition for all of the above.
> 
> And I just tried the "pulseaudio -k;pulseaudio -vvvvv" about 50 more times.
> Same instantly respawned result every time.  Where do I disable the 
> auto-respawn?

OK, the best bet here is to:
cp /etc/pulse/client.conf ~/.pulse/client.conf

then edit the latter file and change so "autospawn = no"

This will allow easier debug :)

> I just fired up mcc, went to the screen for audio and ran everything there,
> getting the expected results except for the last one:
> [gene at coyote ~]$ /sbin/fuser -v /dev/dsp
> [gene at coyote ~]$
> but at this point I have NDI what that means.

That's fine, /dev/dsp is a legacy device node and not much should have
it open anyway. 99% of apps use either alsa or pulse directly.

> Also, doing that while paplay is running is equally uninformative.
> But it seems to me we aren't using, or do not have, a tool that will
> trace the paths being used.

OK, so ultimately I think the next round of debug relates to that root
process.

In my previous list of numbered steps can you add:

 -1) Ensure no root PA daemon is started prior to testing. e.g. do a
fresh reboot, login and then do ps aux | grep pulseaudio. If there is a
root process running, just stop right there and let me know. THis is the
problem and *something* is running on your machine as root that is
trying to produce sound... this is a bad thing and needs to be solved.

 0) If you just have your own user's PA running, then run the steps
again. You can skip #8 tho' :)

 1) as before
 2)    "
 ...)

All the best

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]