Description of problem: The pulseaudio daemon is started by gnome. For those of us not using gnome, several bugs prevent it from being started properly. This daemon should be started like any other Linux daemon - as a service in /etc/init.d. The attached file shows how I fixed things. Version-Release number of selected component (if applicable): All the pulseaudio packages in the F8 release. How reproducible: Perfectly. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: See attached file.
Created attachment 262541 [details] Steps needed to fix pulseaudio startup
No, this is not right. We are using pulseaudio as a session service, not as a system service.
I think my objection is valid. I don't understand the semantic distinction between session service and system service. Please reread my problem statement and tell us how to access the sound system during bootup - specifically, how to do an aplay in rc.local, for example. This has always been possible before, and is a useful function.
If it is a session service and not a system service, how are non-gnome users supposed to start it? I'm also not using gnome, just straight X with xterms, emacs, a window manager, a browser, etc. I notice that I can just run pulseaudio& but I shouldn't have to do that for sound to work properly.
This is very basic problem of pulseaudio. It completely cripples the console audio too. If you use only init 3 then you can not run mixer, lot of applications fails, when you start pulseaudio in console it gives you fail as it can not load module-x11. So even the workaround with running pulseaudio "by hand" does not work.
I have the same problem, sound works fine in gnome, doesn't work so well running fluxbox. I use fluxbox, which is a supported option in fedora. That being the case there shouldn't be important resources such as sound that are not usable to those of us that don't want to use bloated environments such as gnome or kde. Either sound should be supported in all WMs provided by fedora, or the WMs should be removed from the fedora distro. I hope that the former solution is adopted.
(In reply to comment #1) > Created an attachment (id=262541) [edit] > Steps needed to fix pulseaudio startup > I tried the instructions in comment #1 and pulseaudio still doesn't work. The permissions in /dev/snd are now correct, I don't have files owned by kismet, I have user pulse with home dir in /usr/run/pulse. When I try to play audio though I get: W: protocol-native.c: Denied access to client with invalid authorization data. I'm not running in Gnome. Things work fine there. I'm running in a fluxbox session.
> I have user pulse with home dir in /usr/run/pulse. Sorry, I mean /var/run/pulse.
I have similar problems trying to use Fedora 8 with the mpd server. The system starts at run level 3 and exists only to run mpd and play music on my stereo. It doesn't even have a monitor attached to it. Using the modifications in comment #1, I still can't get sound, usually erroring with Connection "refused".
I have found a way to get pulseaudio to run in a GDM managed fluxbox session (my typical setup). 1) Follow the instructions in comment #1 up to and NOT including step 4. 2) Log into your x session. 3) open a shell and type "xhost +" 4) open a shell as root and start pulseaudio with "/usr/bin/pulseaudio -D --system --log-target=syslog" 5) test that audio now works using "/usr/bin/aplay /usr/share/sounds/startup3.wav" or a similar method. (or do paman to see that "Server name", etc. no longer have n/a values). I found that I can not get pulseaudio to work in X unless it loads the module-x11-publish. If I try to run without that module I get the error: W: protocol-native.c: Denied access to client with invalid authorization data. When I allow that module to be loaded, if I don't do "xhost +", I get the following errors: E: x11wrap.c: XOpenDisplay() failed E: module.c: Failed to load module "module-x11-publish" (argument: ""): initialization failed. E: main.c: Module load failed. E: main.c: failed to initialize daemon. The XOpenDisplay made me think that there is an access problem to the X server (why does it need this?). Doing "xhost +" allows anyone to access the X server. After doing "xhost +" pulse audio runs. I still get an error when I start xmms: Message: alsa_setup(): Cannot set mmap'ed mode: Invalid argument. falling back to direct write. But xmms does play files even with this error. There's a few problems with this procedure. 1). It requires one to log in as root to start the pulseaudio service, after the user has claimed the X display (the user must do xhost + first). 2). xhost + is unsafe. I tried xhost +pulse, but xhost wouldn't allow it even though I have a user named pulse in /etc/passwd. 3). This breaks /etc/rc.local setup as specified in comment #1. A better way would be do to the access control in the X startup somewhere, but I don't know which file and which command would be the best way to go with it.
I looked further at how Gnome starts pulseaudio. It does not use the --system flag (hence the explanation that pulseaudio is intended to be a session service not a system service). In that case I've found that pulseaudio can be run as a session service in a GDM managed fluxbox session by simply issuing the command /usr/bin/pulseaudio --log-target=syslog without having to resort to any of the steps in comment #1 or any of my suggestions in comment #11. I now start pulseaudio when I run fluxbox by putting the following in ~/.fluxbox/startup: # Fedora 8 audio setup /usr/bin/pulseaudio -D --log-target=syslog The thesis of this bug that pulseaudio startup is improper still stands in my opinion for reasons pointed out in earlier comments, so this comment doesn't help resolve this bug. Should I open another bug "audio doesn't work for fluxbox" to have maintainers implement a solution for the fluxbox specific problem?
Yes, this is a fluxbox-specific problem. pulseaudio is supposed to be started with the session. GNOME and KDE handle this fine, but fluxbox is failing to do that. That makes this a fluxbox bug. Reassigning and changing bug summary.
No, it's not fluxbox specific! The point is that audio should work regardless of the window manager or even on a console login without X running at all.
That's nice, but saying "everything should magically just work" doesn't fix anyone's problem. There *is* work going on to better integrate PulseAudio and session startup in F9, so maybe in the future it will magically Just Work. But for F8, if you have alsa-plugins-pulseaudio installed, the session manager needs to start pulseaudio for sound to work properly. GNOME and KDE handle this just fine. The only reason it doesn't work in fluxbox is because it doesn't start pulseaudio. It's up to the fluxbox maintainers to decide how they want to handle it, so that makes this - for F8 - a fluxbox problem.
I disagree that this is a fluxbox problem. It is something that can be fixed in fluxbox but it shouldn't. Entailing pulseaudio on users for F8 is one thing but saying it is not a pulseaudio bug is wrong. Say I implement pulseaudio2 because I like my stuff better. I submit it for review and it gets into fedora. You imply then that all window managers would have to cope with that fact by changing their way of startup. Now follow this further: If I decide to make it incompatible with pulseaudio what happens then? It is a choice for maintainers to roll the magic dice and decide which to support? Imho stuff like audio even if it is session related should never ever need specialized stuff in the window managers initialization. The right way to fix this would be to introduce a system wide location via e.g /etc/sysconfig and make all window manager startup scripts run that. This way the user can decide which stuff he/she wants and configure it at the right central place instead of workarounds in each component. This way future enhancements/changes magically just work.
I'm not saying that everything should magically work. I'm pointing out that numerous commenters have mentioned that they have problems with Xfce, sawfish (which is what I use), or the console. The point is that there seems to be a fundamental disconnect over whether pulseaudio should be a system service or a session service. Clearly changing fluxbox to start pulseaudio properly will solve/hide the problem for fluxbox users. I'd never heard of pulseaudio prior to F8, so I don't know whether the problem is how pulseaudio is started or how it is integrated into the system. What I do know is that if I log onto the console and run "play ..../some-audio-file.wav", I get errors about not being able to connect to pulseaudio. Therefore, whatever sound APIs are being called by these applications are trying to connect to pulseaudio. Unless Fedora is saying that audio is only supported if you are logged into X (which would be an indefensible position), then the problem being reported here is not a fluxbox-specific problem. I'm not saying anything in this comment that others haven't already said, and people have actually proposed concrete solutions. This is definitely not saying that everything should magically work.
This bug was really opened as very fundamental one and what it's triing to say at the first place is that introduction of pulseaudio should be nice improvement of X/WM/GNOME/KDE sound capabilities, but it should not break sound support for applications that do not know, or even do not want to know about pulseaudio. That's the point. Or you want to fill bugzilla for every particular application that suffers this problem in F8 e.g. in init 3? IMHO starting pulseaudio at system start is not a good solution. My opinion is that pulseaudio should be something that adds value to existing sound support in apps when it is running, but sound should work without pulseaudio as it worked before it was introduced.
Irrelevant. This is not the time or place to discuss whether you like how pulseaudio works. That decision was already made and PulseAudio was put into the distribution *two months* before F8 was released. Everyone had plenty of time for comments and fixes back then. If you want to change how PulseAudio works in F9, that's great, but it's too late to change the defaults for F8 now. PulseAudio is required to make sound work properly in F8 when alsa-plugins-pulseaudio is installed. Sound doesn't work in fluxbox because it fails to start pulseaudio. That's a bug. So there's two solutions for fluxbox users: 1) Ask the maintainers to make fluxbox start up pulseaudio, or 2) yum erase alsa-plugins-pulseaudio and everything will work like before.
Well I agree with you that it is a bug but it is a pulseaudio one and not a fluxbox bug. If you fail to read the comments of the users in this bug (which compared to other bugs are really well written and state the case quiet objectively) then at least listen to the maintainer...
As the author of the original objection to the new audio system design, I have two additional comments: 1) I omitted one additional fix to make it all work. 2) I object to the reassignment as a bug to fluxbox (whatever that is). First, a sixth step is needed to allow users to use the sound system. To the 5 steps in my original list add this: 6) Edit /etc/group to add all prospective sound users (ie, all the real people in /etc/passwd) to the pulse groups pulse:x:496:root,dad,srd,mandy pulse-rt:x:495:root,dad,srd,mandy pulse-access:x:494:root,dad,srd,mandy I don't know why there are these three new groups, or whether all three must be edited (there being no documentation), but this works for me. Second, a few of the subsequent comments indicate a real lack of understanding of the basic principles of UNIX/Linux system architecture - let each unit do one job and do it well. The pulseaudio system might well be able to do sound really well, but the idea of wrapping this task into some ginormous do-everything blob, like gnome, is simply wrong-headed. While many of the new sexy sound-makers exist solely in an X environment, the underlying sound machinery surely does not. The ability to drive the speakers is basic and must not be tied to X, or to any particular user. Arguments about session service vs. system service miss the point. Sound MUST be a system service and be there whether or not X is running. X applications that emit sound should use the appropriate interfaces to the underlying sound daemon. There are lots of examples of sound-without-X: 1) The bootup time of Fedora exceeds my attention span. I like to be awakened by an audible signal when it's ready to log in. 2) With ntp providing super-accurate time, it's only natural to create a virtual grandfather clock to mark the hour - done with a simple cron job. (Still looking for Westminster Chimes.) 3) I always follow a long task such as make or wodim with a beep script that alerts me when it's done. So, please fix Fedora 8 so that sound works as it always has. And also works with all those wonderful new features that pulseaudio adds to the mix. Fortunately, it isn't hard to make pulseaudio be a system daemon. My complaint is that discovering the enumerated 6 fixes should never have been necessary; they should have been the default in Fedora 8.
Look, I agree with all of the arguments presented here, but it's too late to change the defaults for F8 because it's *already been released*. There's a simple workaround: If you want to fix Fedora 8 so "sound works as it always has" then remove /etc/alsa/pulse-default.conf or the alsa-plugins-pulseaudio package. If you want to help get the defaults changed, Fedora 9 Alpha is only 6 weeks away. I've filed bug 411151 (PulseAudio should not be the default ALSA device unless it is running) to track this for rawhide. A plan for F9 should be discussed with the PA maintainer and/or FESCo. fedora-devel-list is a good place too. The fluxbox maintainers don't want to add a workaround for F8, so I'm closing this particular report. Sorry for any confusion. *** This bug has been marked as a duplicate of 411151 ***
Well I did not say that I am not going to fix this. I just refuse to take it as a fluxbox bug. Besides that. While you seem to think that most inquiries are reasonable: This behavior is a key default major super magic feature but a bug in the F8 pulseaudio packages which could easily be changed by a simple upgrade of the alsa-plugins-pulseaudio package and fixing a bug by releasing an upgrade for F8 imho is a valid way to resolve this issue even after release. If you want I am willing to take a closer look and make a patch against the package. If we nevertheless agree to not fix this then there is no other chance for me to put the workaround in all of my packages which are quiet a view that are effected by this.
Changing alsa-plugins-pulseaudio breaks pulseaudio for people using KDE/GNOME, which is the *vast majority* of F8 users. I agree that the current setup is partially broken but there's no simple fix possible for F8. It's possible the fix for rawhide can be backported to F8 - if you want to work on that rather than adding a hack/workaround for fluxbox, that's fine.
Ok then lets agree on the following: Use #411151 to track a possible fix for rawhide, backport it to f8 when ready and possible and I will add a workaround to {fluxbox,windowmaker,...} till the fix is backported. That should resolve most issues on the user side of things.
I have made the changes suggested in postings #1 and #21, and the result is that sound works "properly" in both init 3 and init 5 under gnome and KDE. What's so hard about putting these changes in a fix? It doesn't require any software rewrites.
Stuart, even thou I share the objection to PA here, described changes are not correct. E.g. setting permitions to 0666 by udev should not be done - this is a job for ConsoleKit to set permitions based on logins/sessions. Also removing module-x11-publish is not correct in general. Same for running pulseaudio in rc.d. Those steps are workarounds for several persons, but can not be used widely. Btw: the problem with access to sound devices can be related to bug #370821. It's name can be missleading but basicaly it says, that due to some changes/bug in kernel sys structure, lot of sound card permitions are not set correctly by consolekit because hal does not detect them.
fluxbox-1.0.0-2.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update fluxbox'
fluxbox-1.0.0-2.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update fluxbox'
fluxbox-1.0.0-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
fluxbox-1.0.0-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.