Timing of file writes during recording

6 views
Skip to first unread message

Daniel Brandur Sigurgeirsson

unread,
Nov 14, 2010, 5:27:56 PM11/14/10
to sipx...@googlegroups.com
Hi,

occasionally, when I receive the Disconnected Line event, and I stop a recording that is still in progress (this could happen if the user on the other end of the line hangs up without properly terminating the recording session), I get a strange error. I'm using a library to load a .wav file using the mmioXXX Win32 functions, and when the mmioDescend( ) function gets called to access the "fmt" chunk, it fails. However, when I later examine the file that apparently could not be loaded, it seems fine. So it seems that issuing a save command is asynchronous. I'm currently experimenting with catching this error, and if it is thrown I simply let the current thread sleep for 200 milliseconds and then try again.

Just to clarify, this seems to be the order of the events:

- I receive a Disconnected Line event
- I test if there is still a recording in progress
- If it is, I stop it (using sipxCallAudioRecordFileStop)
- I load the file, and it fails. However, this only happens occasionally, and I haven't been able to reproduce it consistently.
- Currently I'm trying to handle this by catching this error, waiting 200 msec, and then try the file-read again.

Any ideas? Do you find any flaws in my current experiment?

Regards,
Daníel

Jaroslav Libak

unread,
Nov 15, 2010, 4:44:12 PM11/15/10
to sipx...@googlegroups.com
Hello

sipxCallAudioRecordFileStop is asynchronous call, request is posted into
XCpAbstractCall thread and from there
SipXMediaInterfaceImpl::stopRecording -> MpCallFlowGraph::closeRecorders
is called synchronously. So when sipxCallAudioRecordFileStop returns
recording is not really stopped yet. You shouldn't use sleeps in this
case. XSipConnection::~XSipConnection fires CALLSTATE_DESTROYED event,
which is the last event that can be fired from a call before its memory
is freed. This means if you wait with loading the recording file for
CALLSTATE_DESTROYED, it should always succeed since stopRecording was
definitely processed and finished before that.

Jaro

Daniel Brandur Sigurgeirsson schrieb:

> Dan�el
> --
> You received this message because you are subscribed to the Google
> Groups "sipxtapi" group.
> To post to this group, send email to sipx...@googlegroups.com.
> To unsubscribe from this group, send email to
> sipxtapi+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sipxtapi?hl=en.

Reply all
Reply to author
Forward
0 new messages