[pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Michał Sawicz at 09/02/10 20:57 did gyre and gimble:
> Dnia 2010-02-09, wto o godzinie 19:31 +0000, Colin Guthrie pisze:
>> I wouldn't call this overdesign. Quite the opposite. Yes to get this
>> rather bizarre scenario working it would be complex, but to make it
>> work
>> out of the box in this way in PA itself is far from simple. I've
>> already
>> listed the 5 relevant points that would need addressing for this to
>> work
>> and there are significant design hurdles to overcome there. That is
>> what
>> I would consider overdesign - doing something very complex to support
>> a
>> pretty niche use case. 
> 
> It might drop in the same 'overdesigned' category, but maybe it would be
> possible to create a scenario where:
> 
> 1. remote user or a daemon wants to play audio
> 2. PA looks for an active user session on local PC
> 3. the remote user's PA tries to connect (over native protocol) to the
> active user session
> 4. there's a dialog on the active user's session with 'User xxxx tries
> to access your audio equipment with application yyyy, allow / deny?'
> 5. if the active user agrees, the remote user is able to play, otherwise
> it remains corked until the active user changes or allows the stream to
> play.
> 
> This would also simplify how remote tunnels are created - now you can
> either turn off authentication or hack the config file to only allow
> certain 


This is possible but not with the current structure. Until the
authentication is successful, there can be no stream and thus it cannot
be corked... but the principle is not all bad and with luck the
notification framework I'll eventually commit will help with part of
this approach should it be undertaken.

That said, I'm not sure the complications resulting from this approach
are really worth the benefits. I think we should concentrate on getting
the typical use cases working as near to perfect as possible before
devoting too much time on rather more exotic multi-user interaction
scenarios.


> Oh, and apart from VoIP calls being eavesdropped, if someone hacks in
> and has access to the hardware he can hear _everything_ that is said
> near the microphone. Big problem. Not even root should be able to do
> that.

Couldn't agree more :)

-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]