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

Damien Sandras schrieb:

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:

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.

I will have to check more carefully tomorrow evening. The first test Ekiga master without modification with Opal head (23107, one more than you indicated) failed, due to not being able to open the audio device in Ekiga under Win7. I will try with the stable stuff tomorrow.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]