[pulseaudio-discuss] GSoC ideas

[Tanu Kaskinen]

On Fri, 2013-04-26 at 05:05 +0200, Alexander Couzens wrote:
> Hello,
> 
> I would like to work on pulseaudio as gsoc student this year.
> Can you give me some feedback about my ideas, please?
> 
> I'm working with pulse for a while and this is how I'm using it:
> -1-
> We have an announcements system at c-base my local hackerspace.
> It's a multi speaker setup based on OpenWrt and Ubuntu.
> - sender is a Ubuntu x86 system. it plays hourly time announcement +
> samples
> - receivers are mips32 based routers, arm systems, x86
> This system announce every hour. Got a tts + jsonrpc interface to play
> soundfiles.
> The receiver disappear from time to time. (module-tunnel-sink lacks a
> reconnect feature).
> Also in future this setup should support playing sounds on a random
> group of speakers.
> 
> -2-
> I'm using it at home
> - remote home system: speakers connected to 1 pulseaudio server +
> laptop as sender
>  |- receiver announce themself via avahi/bonjour
>  |- sender: laptop use them as sink
> Pulseaudio should recognize your environment (how? or let the user
> choose which environment-profile apply). 
> Different locations, different audio setup. At work you want to move
> only mplayer/vlc/.. stream to 
> the remote sink. At home, maybe you want to move all streams over to a
> good amplifier.
> Playing video doesn't work reliable. Playing soundfiles works better,
> but not perfect.
> 
> My ideas for a gsoc application:
> - Fix network sinks. Try to move a stream to network sink and back
> moments later it will run into problems.
>     e.g. mplayer just stop playing and hang. My job would be
> additional testing and fixing upcoming bugs in pulseaudio.

Making module-tunnel-sink reliable would be very welcome. Estimating the
amount of work is hard, though, when you don't know what exactly are the
root causes for the bugs, which makes writing the project plan hard too.

> - Implementing profiles for different environments. The user can
> define a profile for home, work, [...]. Main sink, group of sink
> (combine sinks)

I can imagine that there are many users who would benefit from this. We
plan to have major changes to how routing (and other) policy is handled,
and it's not clear to me yet what the end result will look like. Our
general goal is to make things Just Work with minimal (preferably zero)
user configuration, but I'd imagine that it wouldn't be a problem to
have the possibility to have support also for user-configurable sets of
static policy rules (which is what profiles are). I don't know Murphy[1]
well enough yet to be sure, but it might be better to implement such
profiles in Murphy.

I'm a bit hesitant about making this a GSoC project. We could have a
"profile module" based on the current routing system, but I'm not sure
that the module would be long-lived.

[1] https://01.org/murphy/

> - Classify streams to route them based on properties. Music streams
> should be routed to the
>    (remote) music sink, but system sounds should not.

Different routing based on the media.role property is already
implemented by module-stream-restore and works out-of-the box.

> - Missing gui for profiles and/or properties. New qtgui? or extend
> pavucontrol.
> - Simplified way for scripting pulseaudio and doing basic event
> handling. Normal (power) user should script their soundsystem.

I believe there's general agreement that we want Lua scripting in
PulseAudio. I think this would be a very good GSoC project.

> - 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

Authentication without encryption is very questionable security-wise.
Perhaps it's still useful, though? I would presume that in many cases
it's sufficient that it's not trivial for any random person to gain
access to the server and mess with things. The current cookie-based
authentication isn't any more secure anyway, so a password-based
authentication would just be a more convenient way to achieve roughly
the same level of security.

We could also discuss how to add encryption support to PulseAudio.

>  - 'Do you like to grant access to ...'. Extend the native protocol
> for this.
> - mod-tunnel should support multicast dynamic, but configurable. Mcast
> support of cheap APs(most DSL/Cable Routers) are limited to 1
> mbit/s(wifi broadcast rate, which also affects multicast) and most of
> them doesn't support IGMP.

module-tunnel-sink creates a local proxy for a remote sink. I don't
think it's a "tunnel" any more if you use multicast. If you need
multicast, we already have module-rtp-send, or if RTP isn't what you
want, a new module could be created. I'm generally very unenthusiastic
about multicast, though. I'm ignorant about the subject; I'm not aware
of any important use cases for multicast, so to me its purpose seems to
be just to make things difficult. Please educate me, why is multicast
important for any PulseAudio user?

> What would be suitable for a good application?

There were ideas for several summers :) I like the scripting support
idea the most, but feel free to pick anything that interests you.

-- 
Tanu

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.