Bug 223534 - problems with the default setup of pulseaudio
problems with the default setup of pulseaudio
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pierre Ossman
Fedora Extras Quality Assurance
Depends On:
Blocks: FC7Target
  Show dependency treegraph
Reported: 2007-01-19 16:24 EST by Matthias Clasen
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-07 13:51:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to remove the group check (548 bytes, patch)
2007-02-05 12:46 EST, Matthias Clasen
no flags Details | Diff

  None (edit)
Description Matthias Clasen 2007-01-19 16:24:55 EST
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
Comment 1 Matthias Clasen 2007-01-20 00:09:46 EST
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);
                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.

Comment 2 Pierre Ossman 2007-01-21 13:13:02 EST
Ahh... nice catch. I'll make sure that gets fixed upstream.
Comment 3 Pierre Ossman 2007-01-22 10:53:36 EST
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
Comment 4 Matthias Clasen 2007-01-22 11:13:28 EST
My ability to find more bugs is hampered by the hal autodetect module not
finding any sound devices...
Comment 5 Matthias Clasen 2007-02-02 14:54:23 EST
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.
Comment 6 Pierre Ossman 2007-02-02 17:45:19 EST
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.
Comment 7 Matthias Clasen 2007-02-05 12:43:02 EST
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 ?

Comment 8 Matthias Clasen 2007-02-05 12:46:35 EST
Created attachment 147378 [details]
patch to remove the group check
Comment 9 Pierre Ossman 2007-02-05 14:23:50 EST
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.
Comment 10 Pierre Ossman 2007-02-05 14:57:51 EST
Please test the 0.9.5-3 RPMS here:


They should allow the server to start when there are access problems to the user
Comment 11 Matthias Clasen 2007-02-05 15:24:51 EST
Will test sometime, but I am still waiting for a fixed hal to make the sound
device detection work  again.
Comment 12 Pierre Ossman 2007-02-05 15:52:22 EST
I think there was a fix for this merged just before 2.6.20. So you could try
compiling that with the fedora .config.
Comment 13 Matthias Clasen 2007-02-07 11:29:52 EST
the 0.9.5-3 test rpms you pointed me to work fine with the kernel and hal thats in 
todays rawhide.

Note You need to log in before you can comment on or make changes to this bug.