justin-psi2 at affinix.com
Fri Nov 21 21:07:51 PST 2008
On Monday 10 November 2008 21:25:51 Justin Karneges wrote:
> On Thursday 06 November 2008 14:00:53 Justin Karneges wrote:
> > I still need to rewire the implementation and example application before
> > I commit these changes. I'll post again when it is done.
> Done. [...]
Regarding that, I've started refactoring the implementation this week. I even
did some profiling. The profiling was pure curiosity, and I discovered that
waking the glib thread every 20ms for Speex packets was too resource
intensive. Also, it seems that audio resampling and Speex encoding are not
cheap operations. See this bug entry:
I was doing tests using the file mode of PsiMedia. My test file is 30fps
480x272 Theora, 44.1KHz Vorbis (which then gets transcoded to Theora
(redundantly) and 16KHz Speex, for transmission). The 20ms wake combined
with the high cost of audio transcoding resulted in the app tripping over
itself. It would slowly creep to 100% cpu at which point performance would
then start degrading. When I smoothed out the glib waking so that it didn't
occur more frequently than, say, 40ms, then I got acceptable performance.
However, even in that case, the cpu usage of my 1.8GHz AMD would hover
I don't think there's a whole lot more I can do. The rest is mostly a matter
of further GStreamer optimization (such as the above bug entry), and of
course avoiding codec configurations where transcoding costs become
overbearing. 80% cpu is a lot, but the above scenario is not realistic for a
voip session. I'll try to get some benchmarks for live transmission, since
in real life you won't be doing vorbis->speex on the fly.
Other note of interest: It seems that if I wake the Qt thread instead of the
glib thread for processing GStreamer events, then the 20ms Speex wake
produces acceptable results. I don't know if this means the Qt event loop is
more optimized than the glib event loop, or if maybe Qt does its own
smoothing of the events (or maybe even something else is going on...). In
any case, I'll go with waking the Qt thread as this cuts out the middle man
and ultimately reduces latency anyway. Instead of RTP packets travelling
GStreamer -> glib -> Qt, it just goes GStreamer -> Qt.
Another note: I still haven't written any Farsight-specific code. I think for
the first iteration, I'm going to leave Farsight out. This will mean fixed
codecs and no RTCP. A later development cycle will bring in Farsight to tie
up the loose ends.
I think I have about a week left of refactoring and then we can start having
users test the demo app with seriousness.
More information about the Delta