Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 223534 - problems with the default setup of pulseaudio
Summary: problems with the default setup of pulseaudio
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Pierre Ossman
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FC7Target
TreeView+ depends on / blocked
Reported: 2007-01-19 21:24 UTC by Matthias Clasen
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-07 18:51:17 UTC

Attachments (Terms of Use)
patch to remove the group check (deleted)
2007-02-05 17:46 UTC, Matthias Clasen
no flags Details | Diff

Description Matthias Clasen 2007-01-19 21:24:55 UTC
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 05:09:46 UTC
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 18:13:02 UTC
Ahh... nice catch. I'll make sure that gets fixed upstream.

Comment 3 Pierre Ossman 2007-01-22 15:53:36 UTC
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 16:13:28 UTC
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 19:54:23 UTC
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 22:45:19 UTC
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 17:43:02 UTC
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 17:46:35 UTC
Created attachment 147378 [details]
patch to remove the group check

Comment 9 Pierre Ossman 2007-02-05 19:23:50 UTC
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 19:57:51 UTC
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 20:24:51 UTC
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 20:52:22 UTC
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 16:29:52 UTC
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.