https://bugzilla.novell.com/show_bug.cgi?id=886058
https://bugzilla.novell.com/show_bug.cgi?id=886058#c13
--- Comment #13 from Takashi Iwai
(In reply to comment #10)
(In reply to comment #9)
(In reply to comment #8)
As I mentioned, PA accesses the sound device exclusively.
So? There must be a way to make the mpd connect to other PA
So? Such a thing is a special setup we won't take it as default.
Is it? I don't know. If there is sufficiently reasonable way to make it connect to PA properly automatically (like just modifying the default config and maybe fiddle with some permissions unless it's unsafe), we should do it.
It really depends on how to use it. There are several scenarios. IMO, running mpd as a normal user would be the best choice from the device management POV. Allowing the network access is always a security risk, and it's not what the upstream sets. We don't want to change it just because of MPD (especially if there is another way). (snip)
I don't yet know how the communication with pulseaudio works exactly but given that the run/ files are created in run/user/<uid>/... and PA seems to be spawned on demand this doesn't seem to be the to the default behavior, so I think we are left with two possibilities:
1. the network module. Since it should be able to be limited to loopback it think it should be a viable default config.
No, not as default, unless the upstream changes the policy. If you want to take it as default, please convince the PA upstream first.
2. eliminating problems with system mode PA and making it default. I guess this could help with multiuser systems as well?
Very unlikyl. Per user usage is chosen intentionally. For multi-user systems, you want to rather restrict the access from other users while you're using the desktop. The audio access is private, basically. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.