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

Martin Steigerwald Martin at lichtvoll.de
Wed Nov 9 02:43:31 PST 2011


Am Mittwoch, 9. November 2011 schrieb Ben Bucksch:
> On 09.11.2011 10:50, Martin Steigerwald wrote:
> > Am Montag, 7. November 2011 schrieb Maarten Bosmans:
> >>> When I start to playback sound from
> >>> the session of the first user and then switch to the second user
> >>> pulseaudio stops to play back sound from the first user.
> >> 
> >> Correct. This is by design.
> > 
> > I have removed Pulseaudio from my main machine now again.
> > ...
> > I can have Amarok playback music, while I work on my company´s
> > user session and that was all I wanted and what Pulseaudio won´t give
> > me easily.
> 
> Tip, for you and others:
> If you want to separate stuff for security reasons, you can use a VM
> with kvm -soundhw es1370. kvm supports pulse and will redirect all the
> sound of the VM to your pulse server. Just set, under the kvm-starting
> user, ~/.pulse/client.conf with default-server = ..., and enable the
> pulse networking on the server, and you'll hear the Windows-Login-Sound
> from your pulse. The VM guest doesn't need to know about pulse. I find
> that awesome.

Thanks for the hint.

Its mainly for data separation, not for security. I trust my laptop setup 
enough to have two users running on it. And when its off the data is 
encrypted.

I do use virtualization, like for example for the Cisco Anywhere VPN 
client thats messing with network configuration beyond sanity.

> For the pulse people:
> Please don't tell people that the problems they run into are by design.
> You'll have people running away, or even have quite negative feelings
> about pulse. Rather, fix the limitations, please.

I am all for innovation. But only as far as it does not take features away 
that I got used to and really like.

I see the point in per session setup, and I even think its suitable for 
many users. But as it is now, it doesn´t support my use case.

I would even do not have any problem when there would still be two session 
based pulseaudio daemons just using dmixing for audio output and grabbing 
input for recording explicitely. Only then there would need to be some 
mechanism to decide which user gets recording. It could by on a case base, 
so that Pulseaudio grabs input sinks only on demand. And it should not be 
possible to record the dmixed audio output by any user. Each user may only 
record his own audio output.

Maybe thats a workable idea?

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


More information about the pulseaudio-discuss mailing list