[pulseaudio-discuss] GSoC ideas

[Alexander Couzens]

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.
- Implementing profiles for different environments. The user can define a profile for home, work, [...]. Main sink, group of sink (combine sinks)
- Classify streams to route them based on properties. Music streams should be routed to the
   (remote) music sink, but system sounds should not.
- 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.
- 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 - '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. 

What would be suitable for a good application?

Thanks,
Alex

about me:
I'm a student of Physics at Technische Universitaet in Berlin. I've
already contributed to some open source projects and got skills in C, C++, qt, python.
Especially I'm doing many things with OpenWrt, wifi and linux on embedded devices.
http://github.com/lynxis
http://dev.c-base.org/~lynxis/