Re: [Ekiga-devel-list] Another try at gstreamer in ekiga

[Craig Southeren <craigs postincrement com>]

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
 craigs postincrement com au                   www.postincrement.com.au

 Mobile: +61 417231046                    G+: craig southeren gmail com
 US: +1 415 800 4201                   MSN: craig_southeren hotmail com

"Science is the poetry of reality." Richard Dawkins