| Author |
|
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 20 2009 at 3:05pm | IP Logged
|
|
|
We’ve been testing the newer LS 6.0.0.16 with our product. We are using the StartPhoneLineRecording() function to gain access to PHONE_LINE_RECORD_DATA->pSampleBuffer data. We use this in combination with the third party applications PortAudio (PA) and VirtualAudioCable (VAC) to send these packets through PA to a virtual audio device (VAC) which our recording software mixes with video (screen-capture) into a single avi file.
NOTE: VAC appears/registers with the OS as a soundboard/card.
Before the upgrade, this recording method worked (production tested with LS 6.0.0.7). Now for some reason the recordings are silent.
Questions
1. How closely related is this callback functionality to the ability to record to a file via the StartPhoneLineRecording() function?
I’ve tried using this ability to write to a wav file and the resulting files appear to be silent.
NOTE: audio is being routed through LSME w/o any ill effects so I wonder why there appears to be a break here.
2. Is it possible that some change in the LSME has caused a failure here, or have I simply messed up somewhere?
Orig Callback/Recording Code
Code:
Status = StartPhoneLineRecording(pCPhoneBase->m_hSipEngine,
0, // int PhoneLine
FALSE, // RecordToFile
FALSE, // RecordFileRaw
FALSE, // RecordTransmitAudio
FALSE, // RecordReceivedAudio
0, // int RecordDelayMs
NULL, // char *pPhoneLineRecordDir
(PHONE_LINE_RECORD_CALLBACK_PROC)PhoneLineRecordCallback, //Callback Function
NULL); // void *pUserData
|
|
|
And
+ Ability to write recordings to wav file
Code:
Char *tmp = “C:\\RecordDir”;
Status = StartPhoneLineRecording(pCPhoneBase->m_hSipEngine,
0, // int PhoneLine
TRUE, // RecordToFile
FALSE, // RecordFileRaw
FALSE, // RecordTransmitAudio
FALSE, // RecordReceivedAudio
0, // int RecordDelayMs
tmp, // char *pPhoneLineRecordDir
(PHONE_LINE_RECORD_CALLBACK_PROC)PhoneLineRecordCallback, //Callback Function
NULL); // void *pUserData
|
|
|
Callback Function
Code:
Void PhoneLineRecordCallback(PHONE_LINE_RECORD_DATA *pPLRD)
{
PaError paE = Pa_WriteStream(
RecordStream, //Record stream setup with PA Init
pPLRD ->pSampleBuffer,
(pPLRD ->BufferLength/2) );
If (paE != paNoError)
Log the error
}
|
|
|
PA’s OpenStream Init
Code:
. . .
PaError Err = Pa_OpenStream(
&RecordStream,
NULL, // Input Params
&outputParameters, // Output Params
8000, // Sample Rate
160, // frames per buffer
paNoFlag, // don’t clip out of range samples (we won’t output them)
NULL, // callback function
NULL); // user data
. . .
|
|
|
I log two errors from paE, though I’ve checked before and most of the packets do appear to pass through w/o problems. Only two seem to cause an Underflow error.
I have two resulting wav files one is 621kb and the other 216kb, so at least the files are being written to. However I can’t hear anything when trying to play them back.
Any suggestions?
Thanks,
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 11:09am | IP Logged
|
|
|
Hi Fitz,
Thanks for waiting for this response.
Question 1:
How closely related is this callback functionality to the ability to record to a file via the StartPhoneLineRecording() function?
Answer:
I think I understand your question. As long as phone line recording is enabled for a phone line, call recording will function. Recording is not affected by the choice of “record to a file” or “receiving raw audio sample blocks” via the callback mechanism. The same record logic is used for both “record to file” and “sample block” behaviors.
Question 2:
Is it possible that some change in the LSME has caused a failure here, or have I simply messed up somewhere?
Answer:
Yes, the media engine’s StartPhoneLineRecording() API procedure has been updated from previous versions. Other customers have requested that we add record delay control and also the ability to enable recording of transmit and/or received audio as determined by the VOIP application.
v6.0.0.16 of the media engine contains 3 new parameters in the StartPhoneLineRecording() API procedure.
For your application, you can set the record delay to zero (as in your example code snippets you posted).
IMPORTANT:
To get previous media engine default behavior, you must set the RecordTransmitAudio and the RecordReceivedAudio parameters to TRUE (non zero). In your code snippets you posted, you are setting these parameter values to FALSE which will force the media engine to not record any Rx and/or Tx phone line audio.
We should be able to reconcile this issue today. Please repost if I have missed something.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 11:24am | IP Logged
|
|
|
Excellent, that was a simple change. I supposed I didn't quite gather that from the documentation.
To make certain I understand correctly, the 4 BOOL values:
1. RecordToFile
2. RecordFileRaw
3. RecordTransmitAudio
4. RecordReceivedAudio
1 and 2 are strictly related to file recording. Where as 3 & 4 effect both file recording as well as record_callback_proc?
I suppose this brings us back to a request we had made a while back to enable us to detect which direction the audio was going in order to allow us to record in stereo.
i.e. if the packet is outgoing, record to left channel, if packet is incoming record to right channel (or maybe even a pan percentage or something).
I'll have to review PA classes to see what kind of control we would have for L & R channels.
Thanks for the response and clarification.
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 11:59am | IP Logged
|
|
|
Hi Fitz,
You >>>
To make certain I understand correctly…. [parameters] 1 and 2 are strictly related to file recording. Where as 3 & 4 effect both file recording as well as record_callback_proc?
<<< Randal
Yes – exactly.
You >>>
I suppose this brings us back to a request we had made a while back to enable us to detect which direction the audio was going in order to allow us to record in stereo.
<<< Randal
Ahhh… yes, I remember this request from the past. The latest record capability in v6.0.0.16 allows a VOIP app to select if Rx, Tx or Rx+Tx audio are recorded by a phone line (either to a file an or as sample blocks via the callback mechanism). Phone line recording still does not allow us to offer separate Rx and Tx sample blocks to the app. This latter functionality is a bit trickier for the media engine at this time and we would have to rethink some of the current implementation. However, let me say this – this new functionality is not impossible to achieve.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 12:17pm | IP Logged
|
|
|
Let me ask this.
Idea 1:
It would be preferred that LS allow us to choose which channel it sends audio to (or if the packets are L/R sensitive, to disable one channel or the other). Though I believe it was mentioned, this is mono audio (I could be wrong).
Idea 2:
If it were possible to detect if a packet was Tx vs Rx, we might be able to have 2 Pa's, one for Tx, one for Rx each going to a specific channel of the VAC.
Idea 3:
Because the "StartPhoneLineRecording()" function has the ability to send only Rx or Tx to a callback function, how difficult would it be to have two functions for each? i.e. if audio is Rx, send to one callback, if Tx, send to another. I'm certain we can get PA to work in this scenario as we've done stereo recording using multiple VAC's & Pa's and we can make Pa one channel or the other (if I recall correctly, Greg really did the development in this and I'll ping him for clarification on this thread).
#3 might be easier for both parties.
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: July 21 2009 at 12:32pm | IP Logged
|
|
|
Can StartPhoneLineRecording be called multiple times? If so, it could be called once with Tx enabled using callback fn 1, and then again with Rx enabled using callback fn 2. Each callback function would record to either the right or left channel.
Is that possible?
Greg
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 1:17pm | IP Logged
|
|
|
Hi Fitz and Greg,
You both are posting great questions.
Fitz’s ideas 1 through 3 are all technically possible. Your requirement/need to receive separate Tx and Rx phone line recorded audio is a special case of what occurs internally in the media engine.
I will try to summarize what goes on internally in the media engine (parts of this you already know):
Each phone line can record Tx and Rx audio. The current v6.0.0.16 media engine allows the VOIP app to determine what gets recorded (Tx and/or Rx audio). There are three record possibilities that exist:
1)
The app can specify that only received (Rx) audio be recorded in mono.
2)
The app can specify that only transmitted (Tx) audio be recorded in mono.
3)
Alternatively the app can specify that both received (Rx) and transmitted (Tx) audio be recorded. When both Rx and Tx recording is enabled, Tx and Rx signals are digitally mixed into a mono audio stream.
All phone line recording currently produces a mono audio stream that can be written to a file (wav file or raw sample file) and/or that gets presented to the app in the form of 20Ms audio sample blocks. Selecting “record to a file” and/or “receive recorded sample blocks” is controlled by how the app calls the StartPhoneLineRecording() API procedure.
Side Note - Conferencing:
If the phone line being recorded is also associated with one or more conference sessions, all conference session audio that is received on other conference session phone lines will also be recorded as part of the phone line’s Tx call path.
Phone line record operations function on strict 20Ms sample block times. What appears to be needed is the ability to circumvent the normal digital mixing of the separate Tx and Rx phone line audio streams and present this separated audio directly to the VOIP application. In this way, the app will experience the same sample block record timing that currently exists. The difference would be that the record callback procedure would reference two sample buffers in the PHONE_LINE_RECORD_DATA structure that is passed to the callback proc. Curently a single (mono) sample buffer address is passed to the app. This could be augmented to support two separate sample buffers. One representing Tx audio and the other Rx audio.
We would need to update the StartPhoneLineRecording() API procedure to allow the application to specify this “new” multi-channel record capability. Not a big issue from the API standpoint. The issue is internally altering the record signal path to skip the digital mix operation and present individual Tx and Rx sample blocks to the app’s record callback.
It is not clear at this time if we would also want to support multi-channel or “stereo” file generation. Stereo wave file generation could be supported. Not an issue. The raw file recording poses a slightly different issue. Should we record raw samples to separate individual Tx and Rx sample files (that would be time synched) or interleave Tx and Rx samples in the same file. I have to think…
Greg’s question:
Can StartPhoneLineRecording() be called multiple times?
Answer:
Unfortunately no. The reason is that a single instance of digital mixing logic is instantiated for the phone line when pone line recording gets enabled. This is however another logical possibility.
Repost with any further thoughts or comments.
It sounds like I need to make a trip down to Texas one of these days. :)
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 2:32pm | IP Logged
|
|
|
Well, as I'm thinking about it, what about simply my #3 and greg's suggestion.
This would not break backward compatibility. It could be done in such a way that the digital mixer is only activated if StartPhoneLineRecording() is only called once during the startup process. Otherwise it would bypass the digital mixer and send the Tx packets to one callback function or wav/raw file and Rx packets to a different callback function or wav/raw file. If any user wants them mixed, then only call that function once with the proper parameters.
Question/Clarification Request
Additionally, if this function can only be called once, is there a method in which to handle different phone lines? There is a paramater which specifies which phone line the function is to be used, but if it can only be called once, how would one go about recording multiple lines.
Example:
Say for instance line 0 is on hold and the agent is actively talking to line 1. Line 0 was specified with the StartPhoneLineRecording() function, so there would not be a recording for line 1.
----
Greg
Do you recall if it was PA or VAC which was able to send the audio to a specific channel? I think it was VAC and not PA but, maybe I'm remembering wrong.
I'm trying to think of how we might handle sending the packets to a specific channel or the other and not certain how powerful a headache I want to get doing so.
Fitz
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: July 21 2009 at 2:49pm | IP Logged
|
|
|
Handling stereo audio (with left / right channel packets) can be done entirely in PA. It was handled in a slightly different manner previously due to a specific hardware/software configuration.
Regarding Randal's comment about stereo audio generation:
What are your thoughts on adding a bit-flag to the StartPhoneLineRecording API to indicate if stereo audio is requested. If stereo IS NOT requested, mono mixing would take place as it does today. If stereo IS requested then place Tx / Rx on separate channels and deliver stereo packets. This would hold true for raw packet delivery as well as file generation.
With the above approach, LS users could select if they want mono (traditional) or stereo (advanced) output. With stereo file output and currently available software tools (i.e. Audacity) a user could easily take the generated stereo output file and create their own individual Tx / Rx files (if that is what they desire).
For Fitz's purpose, the stereo packets would be passed in directly to the callback function, no modification required.
You also wouldn't need to specify anywhere in the audio packet if you are Tx or Rx since the callback function could "pan" the audio left or right to selectively choose Tx or Rx. I *think* that keeps it simple on the LS side as well as flexible on the user side.
Greg.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 2:54pm | IP Logged
|
|
|
Hi Fitz,
We will have to have a conference call to clarify the exact final approach for updating call recording. There are multiple ways to achieve what we want. Your stated approach is valid but I can’t determine exactly the best approach unless I review the media engine source code. That’s all I should say at this point.
Question/Clarification:
Phone line recording can be enabled or disabled on a per phone line basis. Call recording for each phone line is independent of all other phone lines. The StartPhoneLineRecording() API procedure can be called for phone line 0. It can then be called again for phone line 1… and so on. When I said that it can only be called once, I mean to say it is to be call once to enable recording for a specific phone line. The app can then call the StopPhoneLineRecording() to terminate recording for any specific phone line. I hope this helps to clarify.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 3:02pm | IP Logged
|
|
|
Excellent Randal.
BTW, because one can call StopPhoneLineRecording() to terminate recording a phone line, should I presume that StartPhoneLineRecording() may also be called at anytime?
i.e. during a VoIP call or between VoIP calls?
This may prove useful as we move forward as in the Aspect environment we have one LONG VoIP call even though our agent would handle multiple calls. This would result in troubleshooting scenarios of one excessively large audio with large sections of silence between "calls".
Let me know if I made that clear enough.
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: July 21 2009 at 3:06pm | IP Logged
|
|
|
Fitz,
Your software only records audio when it is on an ACD call. So even though it may be one LONG VoIP call, the software sees it as many small calls, each recorded individually. The audio would be output to VAC, but nothing would be recording it.
Make sense?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 3:10pm | IP Logged
|
|
|
Hi Fitz,
You >>>
…BTW, because one can call StopPhoneLineRecording() to terminate recording a phone line, should I presume that StartPhoneLineRecording() may also be called at anytime?
<<< Randal
Exactly.
You >>>
… i.e. during a VoIP call or between VoIP calls?
<<< Randal
Yup.
You >>>
Let me know if I made that clear enough.
<<< Randal
Very clear… perfect.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 3:11pm | IP Logged
|
|
|
I suppose I should have put the qualifier on that previous statment.
My fault.
I was curious about the write to wav/raw file, not the callback_proc used for recording as per your post Greg.
I tried using the write to wav file method to troubleshoot the issue with the recordings being silent.
I figure this could also be used when/if we need to troubleshoot audio quality issues in either the recording or through the agent-caller pipe.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 3:11pm | IP Logged
|
|
|
Hi Greg!
Thanks for the clarification.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 3:18pm | IP Logged
|
|
|
Greg, Fitz,
I will have to continue our support session again tomorrow morning. I have a previous meeting to attend and probably won’t be back in support mode for the balance of today.
Please continue to post to this thread (and other threads) as you require. I will respond as soon as I can tomorrow morning.
Thank you,
Randal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Possible Record Callback issue
