[pulseaudio-discuss] Ideas for GSoC 2013
michelebussolotto at gmail.com
Thu Apr 18 02:52:16 PDT 2013
Thanks for the quick reply.
Your worries are reasonable, so i try to explain better what my ideas and
my competence are.
I was thinking about working to improve the adaptive resampling module
(especially clock drifting handling module) studying the actual relation
with external code (as it has indicated in "rough" ideas for this GSoC) and
investigating the most known weaknesses.
I've experience in C and signal processing although not directly in
Pulseaudio (obviously in these day I'm studying in deep that). I would like
to participate to this edition for GSoC because I have always been
interested in Open Source software and this could be a good opportunity for
starting to collaborate on this project.
Thanks for any advice,
e-mail: michelebussolotto at gmail.com
2013/4/17 Tanu Kaskinen <tanuk at iki.fi>
> On Tue, 2013-04-16 at 16:17 +0200, Michele Bussolotto wrote:
> > Dear Sirs,
> > I am Michele Bussolotto, an M.Sc. student in Electronic Engineer. I would
> > like to partecipate to this edition of Google Summer of Code and I will
> > very glad if you could give me an opinion about a project idea.
> > In particular, I would like to pay attention to problems in audio
> > transmissions between two devices, like an IP transmission using for
> > example module-rtp-send and module-rtp-recv. I am wondering if exist any
> > mechanism to avoid underrun/overrun due to clock drift, to maintain
> > synchronism between two remote devices, and if could be interesting to
> > improve the performance about.
> Regarding clock drift handling, module-rtp-recv does that by applying
> adaptive resampling, see rtpoll_work_cb() in module-rtp-recv.c.
> Fixing the network streaming bugs that we have (especially in the tunnel
> module) would be great, of course. In order to fix them you need to be
> able to reproduce them, so do you suffer from some particular bugs?
> When considering this as a GSoC project, one thing that worries me is
> that the amount of work that it takes to fix bugs is hard to estimate,
> if you don't know what exactly is wrong in the current code. Having a
> very vague schedule makes it hard for the mentor to assess whether the
> student should be passed or not, which may cause the mentor to pick some
> other project. I don't want to outright reject this project idea,
> however, because the network streaming problems have been there for a
> long time and cause lots of complaints, but nobody has so far had the
> motivation to actually investigate and fix the problems, so getting
> someone to work on the problems would be great.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss