On 22/02/2013 4:04 PM, Julien Puydt wrote:
..deleted
Last night's debugging session made something strange appear : the log
shows that gstreamer feels flooded by data during calls. In fact, one
gstreamer developper had the impression we were getting about 120
times more data than expected. He made those computations at an
advanced hour of the night though, so I'll have to double-check.
Still, does that somebody go "Ooooohhhh!" ?
Opal assumes that media sources will provide correct timing for both read.
If you are reading from any input device, that device must block for the
appropriate amount of time.
For example, if you are reading 20ms of audio data, then the input
device must block for 20ms.
If you do not block, Opal will call the read routine as fast as the
processor will allow. This sounds
like what is happening.
Hardware devices such as sound cards or camera's will automatically
provide the correct timing.
If you are reading from a non-physical device, then you will need to add
software timing. See the
PAdaptiveDelay class for an example of how Opal solves this problem.
On write, the timing will be provided by the incoming RTP data or the
jitter buffer, depending on
which type of media you are using.
Craig
--
-----------------------------------------------------------------------
Craig Southeren Post Increment – VoIP Consulting and Software
cra...@postincrement.com.au www.postincrement.com.au
Mobile: +61 417231046 G+: craig.southe...@gmail.com
US: +1 415 800 4201 MSN: craig_southe...@hotmail.com
"Science is the poetry of reality." Richard Dawkins
_______________________________________________
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
