I have not tried it, but have you considered using sudo's -H parameter?

Just for the record, even if my solution works, I don't agree with puleaudio way of doing things.

Reading writing files in one's home directory just to play some audio is not a good way of doing it.

(In reply to comment #2)
> Just for the record, even if my solution works, I don't agree with puleaudio
> way of doing things.
> 
> Reading writing files in one's home directory just to play some audio is not a
> good way of doing it.

If by "reading writing" you meant just "writing", then I agree. If you meant "reading or writing" then I don't agree. libpulse needs to read the user's configuration before it can connect to the server. If the configuration is not accessible, libpulse could default to trying if a system-wide pulseaudio instance is available and use that, but I don't see what real use case this would serve.

(In reply to comment #0)
> chmod 700 /home/username and then come up with any method playing audio while
> pulseaudio owns the hardware device and then you can close this bug. 

Does "sudo -H" work? If it works, I guess this bug can be closed?

(In reply to comment #3)
> (In reply to comment #2)
> > Just for the record, even if my solution works, I don't agree with puleaudio
> > way of doing things.
> > 
> > Reading writing files in one's home directory just to play some audio is not a
> > good way of doing it.
> 
> If by "reading writing" you meant just "writing", then I agree. If you meant
> "reading or writing" then I don't agree.
Nobody cares what you think, because it's wrong. 
 libpulse needs to read the user's
> configuration before it can connect to the server. If the configuration is not
> accessible, libpulse could default to trying if a system-wide pulseaudio
> instance is available and use that, but I don't see what real use case this
> would serve.
Nobody cares what you can and cannot see, because you are apparently blind. 
> 
> (In reply to comment #0)
> > chmod 700 /home/username and then come up with any method playing audio while
> > pulseaudio owns the hardware device and then you can close this bug. 
> 
> Does "sudo -H" work? If it works, I guess this bug can be closed?
Your guess is completely wrong. I must say I absolutely hate this kind of attitude I get when I report a bug. The description of the bug makes it very clear what I as a user expect to happen. You changed the problem by saying 'use the -H option' (which might not even work, because nobody tested it!). Can someone please explain to me why lots of "open-source" developers have the tendency to believe in their own reality in which no bugs exist? 

I am not going to setup PulseAudio again, just because someone has a "guess". You created a problem, I reported the problem, now you fix the mess you created and you test it or you just leave the bug open and ignore it. That's how it works. If it works, I will say thank you and you have another PulseAudio user, if you say it works and it doesn't, I will just make fun of you and give your project even less credibility (it's already quite close to zero). If you choose to ignore the problem, then over time, PulseAudio will just get increasingly more bugs and people will flock together to some other audio solution or operating system because PulseAudio is unmaintained. Note that closing this issue, because it has been 'solved' in your very fantasy rich universe is not one of the options. 

The user problem is to allow some application running under a different username in a graphical session (which is why sudo doesn't work by itself) to send audio to the speakers. How it does this is of no concern to me. That's your problem. PulseAudio is supposed to add features to ALSA (again, this works fine in ALSA), not remove them.

Until this issue has been resolved, I will just consider PulseAudio a design failure, however great its other features (which I have never seen working, btw(!)) may be. 

I am glad that lameventanas@gmail.com at least still shows some hope for PulseAudio to ever work, but Tanu Kaskinen lack of judgement and immediately dismissing solutions based on how things currently work is worrying. Bad judgement is one of the best ways to kill a project.

I can already guess how your ending message in this bug will be:

"Your response is insulting and blablablablablah and stupid excuse here and stupid excuse there and that's why we will close this bug and delete your account. "

It's a sad, sad world in which people cannot cope with the criticism they receive. Please remember: you are the one who came up with some lazy response instead of fixing this broken software and replying with 

"Yes, we made a small design mistake there, but I just patched it and in the next point release, which you can already install by installing the following tar.gz file. 

Thanks for reporting it.
"

Please notice the difference before you hit the "ban this user"-button.

Thinking this a bit more, using "sudo -H" quite likely won't work either. The default model is that while one user has a session active, nobody else has access to the audio hardware, so having $HOME properly set doesn't help much. Using the system-wide mode is currently probably the easiest way of making this particular use case work, but it has its downsides.

I'm not aware of any simple solutions that wouldn't also have severe drawbacks, so a fix for this bug is not likely to happen soon (I barely have enough time for patch review, so I don't do much coding myself nowadays). If someone is willing to work on this, I have some ideas for a not-so-simple solution (basically a hybrid model where there's a system-wide pulseaudio instance talking to the hardware and taking care of access control, and per-user instances that connect to the system-wide instance).

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/412.