[pulseaudio-discuss] GSoC ideas

[Alexander Couzens]

On Fri, 26 Apr 2013 14:54:19 +0200
David Henningsson <david.henningsson at canonical.com> wrote:

> On 04/26/2013 12:48 PM, Tanu Kaskinen wrote:

> > Making module-tunnel-sink reliable would be very welcome.
> I'd like to see a rewrite of module-tunnel-sink to use the libpulse API 
> instead of doing the protocol stuff directly.
A rewrite could work much better for a project plan?

> I also think that wifi + TCP + low latency is a very hard thing to 
> achieve reliably. The question is if it is possible at all, and if not, 
> what the options are. Arun didn't seem very happy about improving RTP 
> support in PulseAudio.
replace low latency with reliable latency and it can work.
 
> >> - Implementing profiles for different environments. The user can
> >> define a profile for home, work, [...]. Main sink, group of sink
> >> (combine sinks).
Let say location environments. Another interesting question is,
how to define a location? Proof me wrong, but Linux does not 
have a location service which tells us in which environment we are? Like windows doing it 
for networks.

> >> - Simplified way for scripting pulseaudio and doing basic event
> >> handling. Normal (power) user should script their soundsystem.
> That said; it looks like liblua 5.1 is part of ubuntu-desktop already, 
> so that particular dependency would not cause too much trouble in 
> desktop scenarios much, but it would still bloat embedded scenarios, 
> which is bad enough.
We have already d-bus as optional dependency :). Just do a lua as module? Just try to be 
generic enought to add other scripting languages.

> Or, to look at this from another angle - what's wrong with shell 
> scripting? What things are there that you can't do with shell scripting 
> today that Lua would solve?
I don't like shell scripting. Especially because of escaping-hell. How should shell scripting work? It does not gives us a solution 
for the events. From where we get events?

> >> - authentication - add password based authentication. it can be either
> >> a password or a password to add your cookie to the authorized_cookies.
> >> Also a request + response system would be good. Implement it as popup
> >
> > We could also discuss how to add encryption support to PulseAudio.
> 
> Somebody last year tried something popup-like, but it's not easy trying 
> to get that right with all Desktop Environments.
I would look for ssh-agent-helpers and how they integrate into all Desktop Environments.
Don't think we should discuss here about what is the best or suitable encryption.

> I'm not seeing the use case for having PulseAudio handle passwords. Can 
> somebody enlighten me?
In bigger networks than home networks, a co-working space, hackerspace or at work, you want to allow certain people to access
one pulseserver, but not everybody. You can only allow it by one cookie or do it over ip-acl. But using ip-acl for 
dynamic ip address is horrible. A cookie is far to long complex.

I would like to start from bottom up. First we need a good mod-tunnel, before it make sense for me to start with most of the other tasks.
-- 
Alexander Couzens

mail: lynxis at base45.de
sip/jabber: lynxis at c-base.org
mobile: +4915123277221