Re: [Ekiga-devel-list] Win32 Opal datasize, please help

[Damien Sandras <dsandras seconix com>]

Michael,

Le mercredi 15 juillet 2009 à 21:47 +0200, Michael Rickmann a écrit :

[...]

> Well it all condenses down to line opal-3.6.4/src/opal/patch.cxx:217 
> which is
> source.SetDataSize(sink->primaryCodec->GetOptimalDataFrameSize(true), 
> sourceFormat.GetFrameSize());
> Opal's ***"dataSize"***, which we are called with in 
> "ekiga-3.2.5/lib/engine/components/ptlib/audioinput-manager-ptlib.cpp :
> GMAudioInputManager_ptlib::get_frame_data : size" is derived from the 
> GetOptimalDataFrameSize(true) part.
> In our GMAudioInputManager_ptlib::set_buffer_size : buffer_size we are 
> confronted with Opal's ***"frameSize"*** which is derived from 
> sourceFormat.GetFrameSize() (see above). Opal makes shure that 
> ***"dataSize"*** is a multiple of ***"frameSize"***.
> As Ekiga must not know about Opal's internals in 
> GMAudioInputManager_ptlib::get_frame_data we are supposed to read
> as many buffers as needed for size  (see GetOptimalDataFrameSize(true) 
> above).
> 
> Could you make sure whether the interpretation of the new API to read as 
> many buffers to fullfill the size arggument of "PBoolean 
> OpalRawMediaStream::ReadData(BYTE * buffer, PINDEX size, PINDEX & 
> length)" is correct?

This patch should fix the problem:
http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?view=rev&revision=23106

However, I'm not sure any patch is still required in Ekiga.
In any case, I will probably remove the check for the read/expected data
in Ekiga.

But first, could you test the above patch without any modification in
Ekiga and tell me if it works better ?

Thank you,

PS: the above patch is for TRUNK, not STABLE, but it should be
backported easily.
-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras ekiga net