[SOLVED] pulseaudio daemon fails but starts all the same

akurashy · 2009-09-02 00:56:20

I don't really know what to think of this since it really just confuses me. You see, when you initialize the system it inits all daemons OK except pulseaudio. When it enters KDE session and load everything it plays. But! It's not always like that, sometime it fails and it really means it and even restarting pulseaudio doesn't work at all.

One observation which I don't know if you pulseaudio users have noticed is that my HDA Intel changed to Internal Audio after an update. Since that update everything been failing and not being able to listen my songs in xmms2 is frustrating

I've checked almost all logs (daemon logs, message logs, system logs) but it doesn't display any error, it just says "daemon failed to start up" when I start it manually

sudo pulseaudio -D --system --disable-shm 0 --disallow-module-loading 0 --disallow-exit 0 --use-pid-file 1 --check

Another issue is sudo /etc/rc.d/pulseaudio restart/stop/start

you restart, both fails
stop, fail
start, fail !!!

Well, I'm considering dropping pulseaudio if I don't find something to fix it, which is also another question, which solution to go with? making flash/java and all applications work, go full OSS4?

Last edited by akurashy (2009-09-05 00:14:47)

ngoonee · 2009-09-02 01:19:49

Any reason why you're using pulseaudio as a system daemon instead of per-user?

akurashy · 2009-09-02 01:35:57

ngoonee wrote:

Any reason why you're using pulseaudio as a system daemon instead of per-user?

hmm, well I just used an example from the init (/etc/rc.d/pulseaudio) to start manually to check any errors but no luck

your suggestion is to go per-user better?

ngoonee · 2009-09-02 02:34:12

Well, its your system. You'll need to know what you're doing with it. Normally having pulse fail to startup has to do with some of the modules they're loading (most likely the alsa module which needs control of the hardware card).

Pulse with KDE is quite the pain in the proverbial butt, though. Having never used KDE I can't comment on why, but I've seen enough complaints to the ML. Perhaps try without X first to make sure pulse is working? Or just use alsa.

akurashy · 2009-09-02 03:14:52

okay....

i'll give it a shot although its a bit weird since everything loads before entering a GUI right now so it might be the "same" as without gui, maybe?

I checked user.log and got a hint to start off with:

Sep 1 17:34:48 haru pulseaudio[5766]: main.c: Module load failed.
Sep 1 17:34:48 haru pulseaudio[5766]: main.c: Failed to initialize daemon.
Sep 1 17:35:29 haru pulseaudio[5794]: module.c: Module "module-stream-restore" should be loaded once at most. Refusing to load.

i'll take a look soon(tomorrow), just posted this in case someone had the same experience.

ngoonee · 2009-09-02 04:30:51

Loaded more than once means its already been loaded. So either pulse auto-started before the daemon or you're trying to start pulse multiple ways.

If you have the time, try commenting out various sections of /etc/pulse/default.pa (or system.pa if system-wide instance). Start with module-stream-restore and check your logs again.

ugkbunb · 2009-09-02 17:23:04

My 02 cents.... Just try out OSSv4 for awhile... I am sure you won't be disappointed. I had so many issues with PulseAudio from the issue your describing, to only one application being able to play sound, to choppy / staticy sound.... All this was fixed by removing pulseaudio and trying out OSSv4. Kernel level mixing just works... all applications are able play sound at the same time... I never have the issue of garbled / choppy sound and it always starts up / works on boot.

Just make sure if you are using the gstreamer0.10-good-plugins that you compile/install the version from the AUR that includes OSSv4 support... it is atm outdated but it is easy to update the PKGBUILD to get it to compile with the newest version.

ALSA I hated because I could never get it play multiple sound sources at the same time... it was just a headache all around... and from what I understand pulseaudio is just a glorified ALSA/OSS/insert X wrapper that is suppose to allow for multiple programs to be able access the sound card at the same time.

akurashy · 2009-09-02 22:54:40

Found the problem in system.pa which was module-stream-restore trying to load twice, one to load, and one to restore the sound table which crippled the system.

The daemon still "fails" to load, but works all the same.

@ugkbunb well, I guess I have to prepare myself mentally to go read arch's wiki on OSS and revert all the changes I made of using pulseaudio. It's really a pity, I like pulseaudio but if this is how it's going to be I have no choice but to either, 1) use the svn snapshot (but too much hassle on this one) 2) prepare to OSS4 and get the packages needed and get it over with after testing sound stability and make sure it doesn't cripple itself like pulseaudio)

ALSA is a pain, never could get it to work with other applications, (like flash and java which, well not my choice but the web uses them heavily)

I guess my weekend goes to this

akurashy · 2009-09-04 23:34:17

Sorry for double posting, just something any pulseaudio user should be aware of in system mode after ngoonee planted the seed of doubt I started searching around

The documentation in PulseAudio does not recommend to go system mode citing:

Security: Much like the X server as soon as you are authenticated you have complete control of the sound server, no further per-object access checks are done.
When in system mode, module loading after startup is disabled for security reasons, which means: no hotplug handling in system mode
When in system mode, shared memory data transport is disabled for security reasons, which means: much higher memory usage and CPU load in system mode
The module-xxx-restore modules maintain state that is inheritely user specific, but when run in system mode is shared between users.
Security: there are no size limits on state data, which enables users to flood /var unless you employ quotas on the pulse user
Security: all users that have access to the server can sniff into each others audio streams, listen to their mikes, and so on.
When in system mode you also lose a lot of further functionality, like the bridging to jack, to rygel (upnp), to X11, to ckit, and so on

http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode

I doubt I'll have any problems, after switching to per-user I haven't had any since I started running it without system mode.

But my Gentoo/... distro is shipping an init script for PA!
Ignore that. It's stupid. They shouldn't be doing this.

Arch Linux

#1 2009-09-02 00:56:20

[SOLVED] pulseaudio daemon fails but starts all the same

#2 2009-09-02 01:19:49

Re: [SOLVED] pulseaudio daemon fails but starts all the same

#3 2009-09-02 01:35:57

Re: [SOLVED] pulseaudio daemon fails but starts all the same

#4 2009-09-02 02:34:12

Re: [SOLVED] pulseaudio daemon fails but starts all the same

#5 2009-09-02 03:14:52

Re: [SOLVED] pulseaudio daemon fails but starts all the same

#6 2009-09-02 04:30:51

Re: [SOLVED] pulseaudio daemon fails but starts all the same

#7 2009-09-02 17:23:04

Re: [SOLVED] pulseaudio daemon fails but starts all the same

#8 2009-09-02 22:54:40

Re: [SOLVED] pulseaudio daemon fails but starts all the same

#9 2009-09-04 23:34:17

Re: [SOLVED] pulseaudio daemon fails but starts all the same

Board footer