Hi Pulseaudio could work much better as systemwide-instance I configured all using http://www.fedorawiki.de/index.php/PulseAudio#Systemweiter_Dienst I also installed the "pulsed"-Skript My problem is that its impossible to get the daemon running with "mpd" from livna-repo directly after booting the machine. Both services "pulsed" and "mpd" will start, but there is no sound I must login in KDE, restart "pulsed", after that restart "mpd" and to start playing again "mpc play". Most times after logout the sound is away again I could solve this partly by comment all lines in "/etc/kde/env/pulseaudio.sh" If i log out and sound is still alive (sometimes possible) and restart x-server sound goes also away - wtf has xorg to do with sound= With the original setup there is no way to get mpd play without staying logged in in the gui and even if you switch to a tty sound is paused. Sorry, but is see NO sense in an audio-daemon which is not shipped with a own service-script and can not run directly before login. I know that "mpd" is not shipped with fedora (mp3 and so on) but that should be no reason to make it impossible to use a homeserver for playing music independent of user-logins and use the machine also as workstation sometimes.
Here an additional bugreport at livna some time ago Anyone who get the packages wokring together out of the box can make me really happy while every morning hearing music without additional steps :-) http://bugzilla.livna.org/show_bug.cgi?id=1992
The system-wide mode is only useful on very few, very specfic setups. Machines where no local user exists. Since those machines require manual setup anyway I am very reluctant to include an init script for this by default. In Fedora we run PA per-user. And that's how it should be.
Why should a systemwide-instance only be useful on very specific settings? In the year 2008 i can not be the only person who takes a cable and put the computer on a hifi, loads a big playlist and let it run Sorry but "Soundserver" means for me a service that is ALWAYS there Why should any user which logs in every time in the gui and start programs playing sound have a problem with the system-wide daemon - He will not see or smell him :-) There could be an additional package which installs a working ini-script and makles settings that this will be possible in future like "pulseaudio-systemwide.rpm" _______________ I would have no problem if i get running the system-wide daemon with manually work STABLE and in a way that it will start BEFORE login and MPD will also start before login. Before i log in on the gui it will start but the is no sound - never. So please make this useful and deliver any tool to make settings for systemwide-instance. I dont know what other parts (kde etc.) will make here a part of problems which results in a lost sound after log out from the gui and even if you restart X on login-prompt. But there should be a simple setting to make pulseaudio systemwide, let it run independent from any user-login and prevent ALL other packages to start or kill a pulseaudio-instance instead of using this one. _________________ On my notebook i got pulseaudio never running and the bugreport was marked as "not a bug", i hope you see that i really begin to hate the package https://bugzilla.redhat.com/show_bug.cgi?id=426703
But if you have "a big playlist" then you also have a user. In which case the sound server should be run as user. PA is designed to be per-user. Advanced features like SHM data transfer are only enabled in per-user mode (due to security reasons with the boundary between normal users and system users). Also, it carries a lot of state, policy and personal configuration. That state is per-user, which would mean if we wanted to support this in per-system mode we'd have to split the policy/state part into seperate processes that are then run on the user side. However, since in audio things should be low-latency you really don't want that extra context switch in there. Hence again, PA is designed to be run by the user that wants to play music. That's how we support it in Fedora.
> But if you have "a big playlist" then you also have a user. In which case the > sound server should be run as user. Where will you have this user? The users are "mpd" and "pulse" Have you ever taken a look at mpd? The service runs without user-interaction and has a network port for remote-control. But this stops if you have to reboot the machine with ssh. Where should i have hear a physical user? The fucking computer is running 365 days a year palying music and sometimes a physical user will login - Independet of the use case, music runs anytime This is a case that i have developed in visual basic nearly ten years ago for windows and now since pulseaudio this should be a problem?`The really problem under linux with sound is the locking for /dev/dsp and pulseaudio should be a solution for that
To make it clear I would have no problem with per user But switching to tty, logging of one user etc. should not kill sound, if this would be possible and mpd could have a own instance which will not killed all will be ok. At this time this is not possible and THAT is the problem How this will work behind does not really matter
*** Bug 476931 has been marked as a duplicate of this bug. ***
Please make sure you include the start-x11 and event.d fixes here: https://bugzilla.redhat.com/show_bug.cgi?id=476931 the event.d script does not have to be enabled by default, but it would be a nice inclusion to make it straightforward for use cases like this dude. I myself run a systemwide text-to-speech notification system that must run even when there is no session, and I want it to route through pulseaudio. with the current per-session model, it is simply impossible to use pulseaudio to route the TTS to wherever I am.
*** Bug 499926 has been marked as a duplicate of this bug. ***
*** Bug 499928 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
OK, I guess I should just be honest here. I have no plans to support system-wide mode by default in Fedora any better, so I am now closing this as WONTFIX. For an explanation why I don't want to support system-wide mode I may refer you to http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode
Lennart, Don't just blanket wontfix this. People are contributing valuable stuff here. NOBODY HERE IS DEMANDING THAT PULSEAUDIO START UP AS SYSTEM MODE BY DEFAULT. Shipping an initscript turned off for all levels is NOT GOING TO COMPROMISE Fedora. System mode has many issues that you appropriately raised in the link, but none of those apply if Fedora does not ship the init script added to run levels by default, or the fixes I shared with you here, which HAVE NO EFFECT if pulseaudio is not running as a system-wide instance. But if you do not include the fixes here, then for us systemmode users, EVERY TIME PA IS UPGRADED WE HAVE TO REDEPLOY OUR FIXES MANUALLY -- in other words, we wake up one day after upgrades, and we have no sound. So, bottom line, please be a good sport and add our fixes. They don't affect the software as it is shipped today, but they certainly solve several grave bugs in OUR setups -- so it is a net WIN for everyone involved.
(tldr: the objections you raised against the fixes proposed her, do not follow to the points raised here -- at least for my use case which I provided fixes for. please reconsider.)
Let me rephrase my argument. For the following use cases, pulseaudio as shipped does not work: - permanent voice notifications - headless background music players - multiseat systems Because the first one to get the audio device grabs it and *that's that*. For these use cases, it would be prudent to ship an init script or event.d file that is DISABLED BY DEFAULT. Also, for these use cases, it would be prudent to NOT START the pulseaudio daemon upon login, but rather let it connect to the systemwide instance (which would be on the side of the USER to set up, again not a default). As you can see, the proposed fixes do NOT affect the behavior of the software as shipped, and the init scripts would be documented to use-as-is-under-your-own-risk with a link to the page that you showed. We are not asking you to support this -- we are only asking you to NOT MAKE THE ABOVE USE CASES IMPOSSIBLE, which is not the same. Do I make sense?
I also have to say clear: Why is the official position "use is per-user and shut up"? There are usecases which needs SYSTEMWIDE and to make it clear: * I love linux / fedora * I will never use windows again BUT then years ago i had run a selfwritten music-player in background on windows which started directly after booting the system and its really poor to force a new sounddaemon which is not able to do the same, well i understand the different architecture, but finally this does not matter and you must accept the question "is it the wrong arichtecture?" Nobody speaks from default, but please make it possible > Security: > there are no size limits on state data, which enables > users to flood /var unless you employ quotas on the pulse user does nobody interest which is running his machine as personal workstation 24 hours a day connected with his hifi > Security: all users that have access to the server can sniff > into each others audio streams, listen to their mikes, and so on. does nobody interest on a home-workstation Most time i can live with my won pa-init-script after login on the gui and start the whole stuff again, but most time the machine could run in init3 and after reboot from notebook i have to walk to the homeserver, login, start the whole stuff and type "init 3" after music is running - the really solution looks not like that :-(
I am sorry, but I guess we have to agree to disagree here.
We have offered to do the work for you, so you don't have to put additional effort. We have consistently proven that our requests do not affect the package's functionality as it is shipped. None of your objections apply to the fixes proposed here, nor do they fix the problem for the use cases of the people that have contributed here. Even so, you refused. It therefore is clear to me and everyone involved here that you are not operating from a position of reasoning from evidence in a justifiable manner, but from a position of arbitrary whim based on your commit access to the package. You may be a brilliant coder, Lennart, and you may have commit access to PA and to the Fedora repositories... but I was not expecting this arbitrary and petty behavior from you. "Thanks" for Dreppering the bug, man.
I have never seen a patch here from any of you. A patch can be a very convincing argument here.
Excellent. You shall get patches soon.
I am attaching a patch against start-pulseaudio-x11 which performs simple detection of whether a system-wide daemon is running or it has been setup in client.conf in addition to the environment variable. This lets your package coexist fine with systems that are running the pulseaudio daemon as systemwide instance without fighting for the sound devices. Now all that's left to do is include the init script that somebody wrote and that he should attach here. The initscript, of course, should NOT BE ADDED to the run levels upon installation, and its chkconfig information should NOT DEFAULT to be turned on (i.e. chkconfig: - 99 01 or something in the header) unless the admin does so manually.
Created attachment 349887 [details] makes pulseaudio-start-x11 skip what it does if the system is running a system-wide instance or is hard-configured to write to a default server somewhere else
OK now everybody else who wants an initscript to be included with pulseaudio, WRITE THAT INITSCRIPT and post it here (i cannot contribute mine because i am not using an initscript but rather an event.d file). I will personally verify it myself and check that it works properly. With that initscript in place, it should be possible to service pulseaudio start or something, and have it run as system-wide instance, and the only other change that would be needed is editing client.conf so it says: default-server = /var/run/pulse/native after that, adding users to the pulse-access group should give them access to the pulseaudio server running as a systemwide instance.
Apart from looking a bit ridiculous to me (why do you modify the startup script for the nonstandard setup, when you could just disable pulse startup via standard means if undesired -- unchecking it in session configuration, gconf?), that patch seems rather broken to me: +# Exit if the client.conf file has set a default server (remote desktop session or system-wide daemon) +if [ -f /etc/pulse/client.conf ] ; then + if grep -q "^ *default-server *=" /etc/pulse/client.conf ; then + exit 0 + fi +fi 1.) You're duplicating a client.conf parser here, which is bad; hard to get right anyways (for instance the regexp is wrong now -- what if there was for a tab instead of a space preceding the "default-server" or the equals sign) 2.) You're duplicating the configuration file lookup. Bad. I believe you didn't get it quite right either, there's ~/.pulse/client.conf, not just /etc/pulse/client.conf
Created attachment 349890 [details] initscript Attached my initscript, don't know from what source this time, this fedoraforum.de Maybe some finetuning needed but its a good start and works after gui-login
Lubomir, let me address your objections: The first objection is why I don't modify the pulse configuration by unchecking a checkmark in session configuration / gconf. The answer to this is: *you are welcome to come down here and do that hundreds of times for each user in the terminal servers I maintain*, for free, of course. The script needs to exit 0 FOR EVERY USER, if the Pulse server has been manually set up. A "solution" that requires manual intervention per-user is not a solution -- it's an insult. Of course, I could also delete the /etc/xdg/autostart/pulse.desktop file (which I did) too -- and then the next time I upgrade the pulseaudio package, BOOM, disaster. No, thanks. The second objection is that we're duplicating a config parser. If you have a magical solution that does not involve grep, by all means, we're eager to hear you out. In the meantime, the regexp easy to fix: put the space inside brackets, and put a tab in there. If any of you feel this is critical, I can update the patch. But other than that, there is no other objection you can possibly raise to this, except the spurious "duplicating a config parser here" complaint, for which you have provided no alternative. And, after all, this very same config key in client.conf has the exact same meaning of the PULSE_SERVER env variable, so if you're already checking for the var, you must check for the config key as well anyway. The third objection about duplicating the configuration file lookup is obviously irrelevant, since we are not looking at per-user configuration to determine whether to start up pulseaudio -- we are looking only at system-wide administrator-provided configuration. The user can have a fortune in his .pulse.conf -- it matters nothing from the point of view of the system daemon -- if the daemon has been set up properly by those users who want a system daemon, then a user's configuration is not relevant to determining whether to start up a user daemon or not.
initscript: the initscript needs to be edited to conform to chckconfig start -- take a look at one of the oher initscripts in your machine, look at the header, and reuse THAT. this header is a debian one, it won't work well with fedora. s/Starte/Starting/...// Same goes for Beende. You should really take one of the initscripts for other services, such as smb, and rewrite your initscript based on that.
finally, the chkconfig comment in the initscript has to say: chkconfig: - 91 09 the dash is important -- it signals to chkconfig that it should not add the service to any run level by default.
(In reply to comment #26) > Lubomir, let me address your objections: > > The first objection is why I don't modify the pulse configuration by unchecking > a checkmark in session configuration / gconf. The answer to this is: *you are > welcome to come down here and do that hundreds of times for each user in the > terminal servers I maintain*, for free, of course. The script needs to exit 0 > FOR EVERY USER, if the Pulse server has been manually set up. A "solution" > that requires manual intervention per-user is not a solution -- it's an insult. It does not. Please look at the "sabayon" tool, or use "gconftool-2" with configuration source set to system-wide defaults (now this is a bit of an insult, but well deserved! :)
Lubomir, There is no gconf key to inhibit the start of the PulseAudio daemon upon user logon. Quoting Sabayon here is, therefore, moronic to say the least. Even if it was possible to use sabayon to do that, it would be moronic to use sabayon for this because the system PulseAudio has already been configured, is up and running, and the clients have already been directed to the system-wide daemon through text configuration files, so having to effect two distinct changes -- one in a text file and one in a gconf database -- to get one setting working properly is REDUNDANT to the point of stupidity. Furthermore, your Sabayon suggestion assumes that the entire planet revolves around GNOME -- let me remind you that it doesn't. Finally, the correct behavior here is to skip startup of the daemon upon user logon if the system has been configured with a system daemon. This can be accomplished -- see the patch -- without the use of Sabayon or gconf tools, so there is no reason why you should even suggest it. You clearly have no idea what you're talking about. If you have nothing valuable to contribute, just stay at the margin of the discussion instead of introducing garbage and noise. I'm serious about that, Lubomir -- if you have no idea what you're talking about, step aside and let us, the people who actually know how the components of the free desktop interact, wrangle the bug.
Lubomir, http://imagebin.ca/view/4xZwANj.html Do you see a checkmark to inhibit PA startup here? No? In addition to that, do you have code to inhibit PA startup on KDE desktops without requiring Sabayon? No? Then shhhhhhh.
Patch attached here as promised http://www.pulseaudio.org/attachment/ticket/606/ Against pulseaudio trunk. Now, will you reconsider?
I also gave instructions on how to install pulseaudio systemwide by using upstart here: http://rudd-o.com/en/linux-and-free-software/how-to-make-pulseaudio-run-once-at-boot-for-all-your-users
Tomas, why did you reopen this?
Because there was no clear statement why it is notabug in pulseaudio that it does not allow supporting running the daemon system-wide. Also I see in the upstream ticket, that you would accept a patch albeit a different one.
:-). Thanks, Tomas. Can we put the patch I made in *Fedora releases* at least, and see if other distributions carry it later on? That would fix my and many others' bugs with PA, while Lennart patiently waits for a charitable soul to know enough C and also have enough goodwill to port my patch into the daemon as he requested. Lennart already admitted that my patch does solve the bug in systemwide use cases, so there is no technical reason why it should not be accepted in Fedora, even though he doesn't want to accept it in the upstream code that he very rightly has a right to veto in. See? Win-win.
Last time I checked I was still the maintainer of PA in Fedora. And as such I decided to only ships patches that are upstream. The way to go here is to get the patch into PA upstream and then we can backport that into Fedora. I mean really, this whole issue should be discussed upstream in http://www.pulseaudio.org/ticket/606 And I made pretty clear how a simple patch I'd accept would look like. t's not rocket science.
Oh, and I will now close this bug again, this time as UPSTREAM, since further discussion should happen upstream on ticket 606. There's no need to keep that open on two bug trackers.