On Fri, 2013-04-26 at 22:05 +0200, Thomas Martitz wrote: > Am 26.04.2013 14:54, schrieb David Henningsson: > >>> > >>> 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. > > > How could you possibly be unhappy about "improving RTP support"? Right > now it's basically unusable (for me, anyway) due to this problem/bug: > https://bugs.freedesktop.org/show_bug.cgi?id=44777 I'd be delighted to have better RTP support. But I think it is somewhat misguided to try to maintain a mature RTP stack within PulseAudio. Full post is at: http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-March/016667.html Summary of that: it makes much more sense to reuse something mature like GStreamer's RTP elements for a large number of reasons such as active maintenance and easy support for compressed output. -- Arun
