On 04/26/2013 12:48 PM, Tanu Kaskinen wrote: > 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. I'd like to see a rewrite of module-tunnel-sink to use the libpulse API instead of doing the protocol stuff directly. 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. >> - 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). Profiles, in PulseAudio today, is a concept related to the number of channels a sink/source currently has. If we continue to call this "profiles", it's guaranteed to be confusion. >> - 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. Eh? I've never heard of adding Lua scripting before, and I'm very much against adding yet another dependency to PulseAudio without a very very VERY good reason. 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. 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? >> - 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. Somebody last year tried something popup-like, but it's not easy trying to get that right with all Desktop Environments. I'm not seeing the use case for having PulseAudio handle passwords. Can somebody enlighten me? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
