[pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions

Colin Guthrie gmane at colin.guthr.ie
Wed Nov 9 03:28:01 PST 2011


'Twas brillig, and Martin Steigerwald at 09/11/11 10:28 did gyre and gimble:
> Easy enough:
> 
> dmix is set by standard as of ALSA 1.0.9rc2 [1]

dmix is good system but we've moved on from there. If you are using a
pure alsa setup I'd certainly recommend it, but it does strange things
to sample rates etc.

> but getfacl shows that only one of my users is added to the ACL list for 
> device files in /dev/snd. Whyever...

It's likely (at present due to the information in console-kit. See
ck-list-sessions. Only one user is ACTIVE than that user will get ACL
access to audio (and numerous other devices too) via udev-acl. In the
future, this will be done instead by systemd-logind as console-kit is
deprecated.

> So its going to be the good old way around: I added both users to group 
> audio. I removed them from there for the perfect pulseaudio setup.
> 
> Now I get simultaneous audio on both sessions without a glitch. And 
> frankly I don´t care whether thats by design or not. I even don´t care 
> about the recording issue for these two users, cause they are both mine.

That's fine. If this system works for you and you can happily use the
devices you own and run the apps you want, then it's all good.

I think it's still a fundamentally flawed system and we cannot design
for this use case where security and access is "good enough" or with
unnecessary layers and admin overheads.

> A mailing list reader suggested a VM for the second user, but all I just 
> want is two KDE sessions with audio simultaneously and now I just got want 
> I wanted. Why use a VM when its not needed?

I think that's massively overkill.

> I still hope that Pulseaudio can give me this by a simple configuration 
> option one time. I stand by it that this is a perfectly valid setup and do 
> not want to dictacted to organize my stuff differently by software or 
> design.

I think this is the problem many systems face. We try to design both the
audio and all plumbing layers in Linux to deal with a wide variety of
situations in a robust and secure manner. That means that some setups
will not work, that's the trade off. People don't want to compromise
their configuration for good design and that's fine. It's Free Software
after all, it's your right. But you also have to consider that the path
you are taking is your own and thus the problems you encounter will have
to be solved by yourself and a lot of the time when you ask people for
support, you'll be given the "it's not supported" response. That's just
the way it goes. If you are happy with that then, the best of luck to you :)

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/



More information about the pulseaudio-discuss mailing list