After installing the pulseaudio package, running pulseaudio fails with a warning about the user not being in the pulse-rt group. Thats not really a workable solution for the default sound daemon, unless we can figure out a way to add all current and future users to that group automatically. After adding the group manually, pulseaudio still fails, complaining that it can't read $HOME/.pulse/daemon.conf
So, the warning about $HOME/.pulse/daemon.conf turns out to be due to pulseaudio not running under my user id. If I do a chmod a+rx $HOME the warning goes away. The problem is probably this code if ((f = fopen(fn, mode)) || errno != ENOENT) { if (result) *result = pa_xstrdup(fn); pa_xfree(lfn); return f; } in pa_open_config_file(). fopen probably fails with EACCESS here, not ENOENT, thus we don't try to read the global file.
Ahh... nice catch. I'll make sure that gets fixed upstream.
This was actually already fixed upstream. Just waiting for an excuse to make a new release. ;) We'll try to squash all the bugs you can find right now and then roll out a new version.
My ability to find more bugs is hampered by the hal autodetect module not finding any sound devices...
Pierre, any opinion on getting rid of the group stuff ? I don't think we want a default sound daemon that requires users to be in a special group to use it or talk to it.
With the bug solved, it will start just fine when you're not in that group (you just won't get realtime scheduling). I can see if I get some time to put a patch into the current package.
Here is my take on the whole realtime issue: 1) If pulseaudio works fine without realtime scheduling, why bother with the extra complication ? But I hear from monty that realtime scheduling _is_ a requirement for acceptable user experience. 2) If realtime scheduling is required for acceptable user experience, then we cannot make pa the default sound daemon without giving everybody realtime scheduling. Why bother with the unnecessary group complication then ?
Created attachment 147378 [details] patch to remove the group check
Then monty and I disagree. Realtime isn't required for normal desktop use. It is needed for things that require low latency (e.g. pro audio stuff and some games). Not sure having it on for everyone is a good idea. There is a reason it requires root privileges after all.
Please test the 0.9.5-3 RPMS here: http://homes.drzeus.cx/~drzeus/pulseaudio/ They should allow the server to start when there are access problems to the user conf.
Will test sometime, but I am still waiting for a fixed hal to make the sound device detection work again.
I think there was a fix for this merged just before 2.6.20. So you could try compiling that with the fedora .config.
the 0.9.5-3 test rpms you pointed me to work fine with the kernel and hal thats in todays rawhide.