Daniel Sigurgeirsson wrote: > > OK I've been working on the recording issue that's been bugging me. In > the meantime I took a short vacation that had been planned for some > time, and during that time I read "The Fabric of the Cosmos > <http://www.amazon.com/Fabric-Cosmos-Space-texture-reality/dp/0965900584/ref=sr_1_2/103-3960470-5255006?ie=UTF8&s=books&qid=1184780004&sr=8-2>", > which, among others, talks a little about quantum physics. And funnily > enough, the bug I've been trying to track down turns out to be a > Heisenbug <http://en.wikipedia.org/wiki/Heisenbug>. > > I'm working on revision 9600 with a couple of changes (Jaroslavs > recording patch plus a few minor fixes to ensure call recorder is > properly set up), and modified the ReceiveCall example so that it starts > recording as soon as a call is started (receives the CALLSTATE_CONNECTED > message). If I place a breakpoint at the line which calls > sipxCallAudioRecordFileStart, followed by a F5 when execution stops when > this breakpoint is hit, the recording will succeed. However, if no > breakpoint is present, nothing will be recorded. > > Obviously it would be best if I could get the same behaviour with the > latest revision of the code, but currently I'm just trying to figure out > the flow of data. I still don't completely understand who receives the > RTP traffic, and how is the data pushed to the recorders? Somehow I > think I need to understand this better, in order to find out where > the bottleneck is located. I think I understand that the Call flow graph > is essential for this, but I don't understand how the call flow graph > gets the data in the first place. Could someone explain this? > > One possible explanation would be that this is somehow connected to the > minimize problem being discussed in another thread (since the console > application running ReceiveCall.exe loses focus when a breakpoint is > being hit in Visual Studio). But obviously there is no guarantee for a > connection between these two problems. > > Anyway, I will continue debugging, but I will welcome any explanations > to the flow of data within sipxtapi. >
There seem to be more bugs in the audio system right now. I found one in MprDejiter::pullPacket for loop, it won't pull the last pushed frame if there is only 1 frame. It needs at least 2 frames to work. I checked whats leaving MprDecode, and there seems to be little if no pauses in sound. But frames don't arrive into speaker or call recorder, so I guess they are getting lost in MprBridge (besides the problems with minimizing window). Frames are getting lost there randomly. Jaro _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
