Sticking this message I sent to Daniel to the list, as it'd be good for other folks to know too.
---------- Forwarded message ---------- From: Keith Kyzivat <[EMAIL PROTECTED]> Date: Jul 9, 2007 1:11 PM Subject: Re: FW: [sipxtapi-dev] Recording - again... To: Daniel Sigurgeirsson <[EMAIL PROTECTED]> I'm not entirely familiar with the higher level recordChannelAudio feature, but I have been testing it specifically with regards to the full call record feature that Jaro created a patch for some time back, and I merged into sipXtapi - r9772 - though, that I later learned was slightly broken - r9799<http://scm.sipfoundry.org/viewsvn/sipX/branches/sipXtapi/sipXmediaLib/src/mp/MpCallFlowGraph.cpp?r1=9785&r2=9799>fixes that -- that would cause call recording not to happen at all. AFAIK other than mic and now call recording, the other recording options will not do anything (the recorders won't be connected to the flowgraph) until you define some macros when compiling sipXmediaLib.. These macros are checked for definition in MpCallFlowGraph.cpp... I may be missing some, but here's a list of some of them. Personally, I think it's pretty ugly, and probably should be rewritten. List of macros that are related to recording in MpCallFlowgraph: INSERT_RECORDERS (Doesn't apply to mic recorder and call recorder) DISABLE_LOCAL_AUDIO (as name implies, deals with more things than just recorder) HIGH_SAMPLERATE_AUDIO DOING_ECHO_CANCELATION I am also still seeing a bug with call recording that I'm trying to chase down -- in the call recording, the mic gets recorded, but the bridge output doesn't get recorded, despite both of them being properly connected. Further debugging lead to the callrec mixer being disabled.. not sure why, as it does get enabled with the other callrec devices, and they seem to be active. I don't have much of any more time this week to work on this, but to aid you in finding where this is happening, here's some tools I was using to debug: in handleMessage(MpFlowgraphMsg& fgMsg) in MpResource.cpp I stuck a resourceInfo(this, -1) before calls to handleEnable and handleDisable, to see when resources were being enabled, and what their states were in. In order to see the output of this though, wherever your test runs, you'll want to call enableConsoleOutput(1) in order to see the debug output that gets written. I stuck breakpoints in CpPhoneMediaInterface::playBuffer(...), MpCallFlowGraph::playBuffer(...), MpCallFlowGraph::handlePlayFile, and a handful of other places. Update to r9811 where I have just checked in some changes to enable call recording in the testRecordPlayback test (CpPhoneMediaInterfaceTest). You'll find that recording the mic works fine (though, it captures the mic input even when it isn't supposed to be actively recording), and there is no output from the bridge. *sigh*.. There are also commented out calls to enableConsoleOutput in the revised test. So, that should help some. On 7/9/07, Daniel Sigurgeirsson < [EMAIL PROTECTED]> wrote:
Hi Keith, Alexander informed me that you had found a bug in the recording which might explain the behaviour I've been experiencing. Could this bug result in call recording to fail sometimes and sometimes not? As I said, recording works in my test environment, but not on client site. I did make some changes to the CpPhoneMediaInterface::recordChannelAudio function, so instead of just recording to a single file, it specified a bunch of files and recorded all options (call, mic, speaker etc.) But only a handful of files were actually created (some preprocessor definitions prevented some recorders to be added at compile time), and none of those files created did include sound. Is there a way for me to verify that the incoming audio is there in the first place, using Ethereal or some other means? Or wiring up the mixers and splitters in some other way? I would be very happy to do as much as I can to figure out what the cause of this behaviour is, be it a bug in sipxtapi, in my code, or just something different altogether. Regards, Daníel ------------------------------ > Date: Sun, 8 Jul 2007 15:45:22 +0400 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: [sipxtapi-dev] Recording - again... > > On 7/8/07, Daniel Sigurgeirsson < [EMAIL PROTECTED]> wrote: > > Thanks Alexander, have you got any idea of what the problem is? Does it have > > anything to do with configuration on the computer or is it just a problem > > with the code? > > We think it is problem with the code. Though I have not looked into this > problem at all - had a talk with Keith only. He said that mixer or one > of splitters > are disabled for some reason, or smth similar. When I talked to him t was > not yet clear. He said that he was able to record sound, going from Mic, but > sound which had to be played to Speaker was not recorded (only silence). > I hope he'll fix this in a few days - I'm quite busy with other > things and have no > chance to look into this. > > -- > Regards, > Alexander Chemeris. > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 ------------------------------ Live Earth is coming. Learn more about the hottest summer event - only on MSN. Check it out!<http://liveearth.msn.com?source=msntaglineliveearthwlm>
-- Keith Kyzivat SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 -- Keith Kyzivat SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
