| Author |
|
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: March 31 2009 at 9:26am | IP Logged
|
|
|
Audio input issues and troubleshooting techniques.
To start off, we do not believe this is strictly an LS issue. Though maybe there is a setting I'm missing or something.
Environments (Call Center Type):
(E1) is not experiencing any audio issues
(E2) is ONLY experiencing an audio problem with audio going from the agent (i.e. the person at the work station) out to the caller
(E3) is the same as E2, same station just using a pre-built Soft Phone for the calls.
Given:
Agent - The person at the work station taking calls through LS
Caller - The person calling via DID into a queue till an Agent answers the call
E1 and E2 environments are setup for different products. At this time we're researching the configuration settings between the two to see if there's something set differently there.
Curious-er:
What I find interesting is that with E2 we have had problems with echo. It appeared Agent's USB headset's mic was sensitive enough to pickup the Caller's voice from the Agent's headset (ear piece) creating an echo effect. (note This was not experienced in E1 with the same headsets.) The echo issue seems to be resolved when the USB headsets were switched for less sensitive analog headsets with better sound cards.
Though with additional audio problems between E1 & E2 I really question exactly what is or if there is some common factor somewhere that no one can find that could be the soul cause all these audio issues.
Back on Subject
The current problem in E2 is bad audio from the Agent to the Caller will sporadically but frequently sound like underwater audio or tin-canned audio.
NOTE: This is appears to be strictly from the mic of the Agent to the Caller.
When these calls are recorded, the recording also suffers the same audio problems as the live calls.
Tests:
We have already preformed some tests in E3 routing the calls through the same network with the same test DID number used for E2 and experience absolutely no audio issues.
This uncertainly has brought some to believe it was an issue with LS, however as we're using LS in the same location in E1 and its not experiencing any issues it appears that it couldn't/shouldn't be LS.
Any pointers, solutions, options, suggestions would be greatly appreciated.
Thanks as always for the quick response.
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 31 2009 at 3:44pm | IP Logged
|
|
|
Hi Fitz,
Good explanation.
What would be extremely helpful would be to get a recording of one of the calls that experiences the “underwater audio or tin-canned audio”. Is this possible?
If the issue occurs on multiple machines, please do us a favor and report if these machines are using the same multimedia hardware and drivers.
A couple of causes may be possible:
1)
We need to make sure there are no RTP transmit errors being detected on the phone line. If for some reason the media engine is getting RTP transmit errors, then this could point us in a different direction. Your apps can call the GetRtpTransceiverStatistics() API procedure to see if the media engine is reporting any RTP transmit failures. Take a look in the Software Developer’s Reference for the RTP_TRANSCEIVER_STATISTICS structure and the API proc from above.
2)
The second thing that may cause something like you described would be non-periodic or spurious recording of local audio sample blocks. If this occurs, it is possible that it could have a ripple effect as the sample blocks are sent down each phone line’s processing chain. Its possible that the possible non-periodic record rate is perturbing the output time scaling and phone line digital mixer logic. This is only a guess. We would have to perform additional logging to see if this is what is occurring. If we can determine that item 1 above is not the cause, then we will have to look at this as a possibility. It will mean that we will have to enable additional media engine audio logging and run tests.
Question 1:
What value have you specified for your MaxMixerLinebuffers and PhoneLineTransmitBuffering settings in the START_SIP_TELEPHONY_PARAMS structure when you start the media engine?
Side Note - Updating your current media engine product:
A newer version of the media engine is available. Because your group has a support agreement, we would like to get you the latest product image. Please post again if you would like to request the latest product image.
Thanks,
Randal
Background information:
The customer who submitted this post uses the VOIP Media Engine in their “agent station” applications that are deployed into their large call center environments. The media engine’s purpose is to support SIP/RTP VOIP connectivity with the call center’s IP PBX switches.
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 02 2009 at 9:16am | IP Logged
|
|
|
I have three recordings we can share with you, due to the nature of the recordings we of course would need to request they be kept in strictest confidence. Though I believe we already have an NDA anyway.
These recordings will be sent to your email account.
System specifications for both E1 and E2 are below. All systems in their respective environments are the same.
E1 System
Quote:
System
Dell Optiplex 745
Hardware
Intel Core2 CPU 4300 @ 1.79GHz
512 MB RAM
40GB SATA
SoundMAX Integrated Digital HD Audio v5.10.1.452
PLTDA60 (USB Plantronics)
LS 6.0.0.7
Software
Windows XP v5.1.2600 + SP3, all updates to 3/31/09
LS 6.0.0.7
|
|
|
E2 System
Quote:
System
Dell GX760; BIOS A02
Hardware
Pentium Dual Core 3GHz
1GB RAM,
80 GB SATA HD,
Soundblaster 5.1VX sound card,
Plantronics MX10 switcher
Software
Windows XP SP3, patched all the way to the latest,
Symantec AV,
Soundblaster 5.1VX latest driver
LS 6.0.0.7
|
|
|
To answer your question 1.
* MaxMixerLinebuffers is not set, so the default value, according to the LS doc, should be 64
* PhoneLineTransmitBuffering is 2
At this time I'm actually working on another product, until they switch priority I'll only be looking into this a bit to get some options.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 02 2009 at 9:23am | IP Logged
|
|
|
Hi Fitz,
OK, I understand. I have received your email with recordings and will investigate.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 02 2009 at 11:35am | IP Logged
|
|
|
Fitz,
Yes, the audio is no good.
Three questions:
Question 1:
You stated:
..When these calls are recorded, the recording also suffers the same audio problems as the live calls.
Do you mean that you activated call recording for the media engine phone line and the recorded transmitted audio was also garbage?
Your answer is important. If the answer is YES, it means there is no RTP transmit issue but possibly a signal path issue from local multimedia audio recording to the RTP transmitter for the phone lines.
Question 2:
Regarding E3- pre-built Soft Phone for the calls.
Is E3 a soft phone based on the media engine?
Question 3:
Two parts:
Is the media engine on the E1 system recording audio from the “SoundMAX Integrated Digital HD Audio v5.10.1.452”?
Is the media engine on the E3 system recording audio from the “Soundblaster 5.1VX sound card”?
Thanks,
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 03 2009 at 5:09pm | IP Logged
|
|
|
Randal,
We didn't have MaxMixerLineBuffers available as an option in our app's config file. So LS' default was being used (64).
Question:
What is the proper range for this option (2 - 64)?
I'm looking at the SDR (Software Developer's Reference) and I do not see the valid range listed.
I'll get back to you regarding the rest of your reply and suggestions.
Thanks,
fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 04 2009 at 8:51am | IP Logged
|
|
|
Hi Fitz,
Ok, I eagerly wait for your additional answers. I eventually need your answers with possibly some additional timing info (you can log for me later). We will be able to synthesize/duplicate the execution characteristics of your host’s local audio record and see what exactly might be occurring in the media engine’s play-out signal paths.
You >>>
…What is the proper range for this (MaxMixerLineBuffers) option (2 - 64)?
<<< Support
Technically, the minimum is 2 and the max can be just about anything. This value simply controls the amount of internal buffer memory allocated within certain internal audio signal paths.
The default value (64) will work for all application cases except for those media engine apps that are running on host machines that are very heavily loaded. The default value of 64 represents a max internal signal path delay of 1.28 seconds (64 * 20Ms per sample block).
What this means is that when using 64 as the setting, the media engine will tolerate up to 1.28 seconds of falling behind what is considered “real-time” which is 20Ms time slices. If the 1.28 second max is reached, everything falls apart from the standpoint of real-time continuous streaming audio. Normal VOIP applications with proper system loading (say no more that 90% of all CPU cycles) normally stay well within double to quad buffering requirements that are normally used in order to obtain the lowest latency (delayed) and continuous unbroken/“choppy” audio.
I would leave the MaxMixerLineBuffers setting at its default unless there is a reason otherwise… like having to conserve process memory for a high line density VOIP app deployment.
I hope this helps.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 07 2009 at 2:18pm | IP Logged
|
|
|
Thank you for the update to the LS Media Engine.
I cannot access the FTP site according to the connection information we have.
Please advise
Thanks,
fitz
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 07 2009 at 2:55pm | IP Logged
|
|
|
Ah... almost forgot to ask, the version that is on the ftp. That wouldn't be a version that expires would it?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 07 2009 at 6:57pm | IP Logged
|
|
|
Hi Fitz,
Access to support FTP accounts now uses a secure mechanism. See the following web page for the current info:
Secure access to customer support FTP accounts:
http://www.lanscapecorp.com/support/SecureFtpAccess/FtpAcces sInstructions.asp
This should get you going….
Please repost if problems persist.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 07 2009 at 6:58pm | IP Logged
|
|
|
… Rats… I almost forgot…
The product image in your support FTP account is the “real deal”.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 14 2009 at 10:51am | IP Logged
|
|
|
Hi Fitz,
We have been trying to duplicate the transmitted audio you reported but its been troublesome to reproduce. I would like to get this issue understood and narrowed down as soon as we can. One thing that would help me at this end would be for you to enable raw sample logging on the phone line. It would be very helpful to see only the media engine transmitted audio waveform.
There is an undocumented API procedure that you can use to record raw RTP received and transmitted samples to disk:
Code:
TELEPHONY_RETURN_VALUE VOIP_API WriteRawRtpSamples(
SIPHANDLE hStateMachine,
int PhoneLine,
BOOL EnableState,
char *pTransmitLogFileName,
char *pReceiveLogFileName
)
|
|
|
The above API requires that both receive and transmit sample log file names be specified. If you can get me the Tx sample log file for a “botched call”, it would go a long way to seeing the phone line’s tx audio waveform and the possible solution. All I should beed is the Tx raw sample file and the RTP media type you are using for your calls.
Let me know what is possible at your end.
Randal
Notes:
This post discusses VOIP Media Engine undocumented API procedures that are used for internal test purposes. Do not use these API procedures in your VOIP applications.
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 14 2009 at 6:16pm | IP Logged
|
|
|
I've had an opportunity to look into this some more.
I do not believe GetRtpTransceiverStatistics() nor WriteRawRtpSamples() will be helpful with this problem [though I could be wrong] (I'll explain in a bit).
I've been running test calls all this morning in an attempt to replicate the audio problem you heard on the recordings we sent a while back.
The single reliable method we have found to compromise the audio is to startup two applications (1) – an end-customer's POS and (2) – our in-house VoIP solution using LS for voice transport.
The problem occurs on a fairly regular basis, when windows (xp) is logged-in and the two apps are started immediately. (We have already tested with time delays between each application with no effect).
I have noticed that simply re-signing on with our application (even rapidly) will clear the audio. (note: the application does not restart, it is ONLY started when windows logs in and stopped when windows logs out).
This is the method in which we have been able to replicate the audio problem on a fairly regular basis. Though we will experience the problem when an agent comes back to the station after a break 15 – 30 mins and signs on (windows was already logged in). I don't know how often this happens, but it is not something we can reliably replicate.
Additionally we have not been able to replicate the mic problem in our test lab.
During these tests we have tried both USB headsets as well as the upgraded sound blaster sound cards and good analog headsets. The results were exactly the same.
(Side Note: An interesting aside... for whatever reason we are not hearing any echo problems with the USB headsets now.)
Explanation of recording:
The mic audio is bad in the recordings as well as what we are able to monitor at the switch and what the caller hears.
We route the audio for our recordings by use of third party applications Port Audio (SDK) and Virtual Audio Cable (i.e. VAC) (Binary) in conjunction with LS's PhoneLineRecordCallback().
The PCM data given by LS via the callback function is ported through Port Audio to VAC.
The recording application obtains it's audio from VAC.
Note: We have tested with this recording feature enabled as well as with it disabled just to ensure it is not somehow causing some problem. Again, we see no difference in the results.
This is why I don't think RTP monitoring or sampling will help:
1. LS is connected directly to the sound device the agent is using (either USB headset or the sound blaster card)
2. PCM packets are taken from PhoneLineRecordCallback() and (via Port Audio) are directed to VAC where we hear the problem in the recordings
All this is done before any RTP transmit occurs--I would think. Therefore any RTP monitoring or sampling should not matter because the problem it is occurring somewhere between the agent's mouth and the LS callback.
Recall that we do not believe this to (strictly) be a software issue as we do not experience any of these problems in E1. This is not to say that there would not be a software solution to fix the problem.
Let me know what you think, if you have any additional suggestions or if you need more details.
Thanks,
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 15 2009 at 6:43am | IP Logged
|
|
|
Hi Fitz,
Very interesting information….
Event though we do not know the exact cause of the audio issue, we are treating it as though it is something in the median engine. If we eventually determine that it is not a media engine issue, that’s OK. If it is a media engine issue, then we can fix it and make the media engine a better product. Either way, getting it resolved is a “win” in the end.
One thing that is certain, low latency media streaming on Windows machines (or any other similar “best effort” operating system) is a balancing act. You trade off between low latency and continuous audio. To get the lowest latency audio possible, internal buffering depth is kept to a minimum. This can prove to be an issue if anything in the systems perturbs average thread execution times for a “prolonged” period of time in excess of internal buffering an/or time scaling of the audio signal paths. If this occurs, the result is most often broke, choppy or in your case “bubbly/gurgled” audio.
You are correct. Based on what you have described, it would not be an RTP transmit issue and therefore I would expect that we would not see any RTP transmit packet errors as reported by the GetRtpTransceiverStatistics() API procedure.
One thing that we need to solidly determine is the integrity of the sample blocks (audio frames) that are being presented to the PhoneLineRecordCallback() proc. This is very important. If done properly, it will allow me to isolate the issue to the media engine.
If I examine the transmit only sample blocks, it will give me an indication of the possible problem. Usually I can look at an audio waveform and see the cause of the issue. This then helps us pinpoint the place in the media engine source code that may need an update, fix or improvement.
Some tech speak:
Internally the VOIP media engine uses our “audio engine” subsystem. The audio engine handles all sample block I/O to/from the host’s multimedia hardware. Recorded audio is taken from multimedia hardware by the audio engine. Local recorded audio sample blocks are then time scale processed (if required) and passed on to a software MUX to distribute the recorded audio to phone lines. The phone line audio is then passed through the phone line’s digital transmit mixer and then finally transmitted via RTP, passed onto the app via the raw RTP interface, etc. It is this overall signal path that I have to look at. If I can get the sample blocks that are being passed to your raw RTP packet interface callback, then I will be able to determine if anything in the signal chain I mentioned above is breaking down or causing us grief.
Task 1:
I need you to call the WriteRawRtpSamples() API proc somewhere in your VOIP app after you enable the media engine.
This proc will allow the media engine to record to disk the Tx sample blocks that are being sent to your app via the raw RTP callback.
Once I get this raw sample file from you, I will investigate further.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 15 2009 at 9:59am | IP Logged
|
|
|
Some clarification:
1) Should WriteRawRtpSamples() be called at the end of the StartUpCallback() function or after StartTelephonyEngine() is called?
2) I presume the file name parameters are path plus file name. If so are they relative, absolute or either?
From there simply add the WriteRawRtpSamples() decloration:
Code:
TELEPHONY_RETURN_VALUE VOIP_API WriteRawRtpSamples(
SIPHANDLE hStateMachine,
int PhoneLine,
BOOL EnableState,
char *pTransmitLogFileName,
char *pReceiveLogFileName
)
|
|
|
in SipTelephonyApi.h
Thanks,
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 15 2009 at 11:12am | IP Logged
|
|
|
Hi Fitz,
Item 1:
Call the WriteRawRtpSamples() API proc anytime after StartTelephonyEngine() and before you start making or receiving calls.
Item 2:
The file names can use relative or absolute path specifications.
Item 3:
Yes, simply place the function prototype for the WriteRawRtpSamples() API proc somewhere in your code. Anywhere is OK.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 16 2009 at 9:33am | IP Logged
|
|
|
Note: This is an email LanScape support received from Fitz.
Here are a couple raw rtp data files.
You should know these are from a test I did on a lab setting. It’s a similar situation. It appears that the first call would come in botched, but (in a full VoIP environment) the next call would come in clear.
I will get the actual production type raw rtp files to you tomorrow. Trying to get the right people together to install the app correctly.
I figured this would be better than nothing.
Our product is capable of working seamlessly in multiple switch solutions/environments. Some full VoIP and others not. In non-full VoIP environments we have a single SIP call which stays active during a "session". If the mic audio is botched, it will remain like that regardless of how many “calls” are received because in reality the SIP call is still active even though the 3-rd party switch environment has complete call control.
The difference we experienced is in a full SIP environment the first call may have botched mic audio, but the second call is completely clear.
As I said before (and I’ll update the public forum accordingly tomorrow) the full VoIP version would clear up on the second call, however because the environment we’re seeing this in only performs that one first LONG call, it would never clear.
I don’t know if that helps, but I found it interesting.
BTW… the files are only for a single call, not two, if you need me to try to get both a bad and a good back to back, let me know. Its not all that consistent in the lab as I had to bog my system down with several apps to get the bad audio.
Sorry if this email seems a little discombobulated, I’m trying to rush out the door.
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 16 2009 at 9:37am | IP Logged
|
|
|
Hi Fitz,
I analyzed the waveform you sent and based on its content, we should be able to narrow down a possible cause.
There is one test we can perform that will really help to narrow down the possible cause of the gurgling Tx audio. The test is associated with enabling and disabling time scaling of the phone line’s transmit audio signal path within the media engine.
When you are in a VOIP call (using the test setup in your lab environment), you can enable/disable the internal time scaling algorithms by calling the following undocumented API procedure:
Code:
TELEPHONY_RETURN_VALUE VOIP_API SetMixerResampleState(
SIPHANDLE hStateMachine,
BOOL MixerResampleEnableState,
int MixerResampleBlockTrigger,
BOOL MasterPlaybackResampleEnableState,
int MasterPlaybackResampleBlockTrigger
);
|
|
|
Once you are in a call that is transmitting the “gurgled” audio, have your code call the above proc as follows:
Code:
.
.
.
TELEPHONY_RETURN_VALUE status;
// Disable Tx signal path time scaling.
Status = SetMixerResampleState(
hStateMachine,
FALSE, // disable transmit path time scaling
4, // normal default value.
TRUE, // normal default value.
4 // normal default value.
);
.
.
.
|
|
|
If Tx signal path time scaling is the issue, then after calling the above proc, the Tx audio should instantly clear and be normal.
Normally the Rx and Tx audio time scaling in the media engine should remain enabled and in their default state. There are a number of reasons for this and they all have to do with maintaining the balancing act associated with “real time” streaming audio.
If disabling Tx time scaling (resampling as it is called) in the media engine clears the gurgled Tx audio, then you should re-enable it using a value higher than 4 for the MixerResampleBlockTrigger value. A value of 5,6,7 or 8 should allow you to have clear Tx audio on the host machines while still keeping Tx signal latency as low as possible.
If you need more explanation or details, repost and I will follow up.
Randal
Notes:
This post discusses VOIP Media Engine undocumented API procedures that are used for internal test purposes. Do not use these API procedures in your VOIP applications.
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 16 2009 at 6:20pm | IP Logged
|
|
|
I've just completed the test including calling SetMixerResampleState() during the middle of a call.
In our production environment, the mic audio was completely incomprehensible. We were able to trigger the SetMixerResampleState() as described above and the call became clear enough the agent's audio could be understood with a little difficulty.
I did not expect this to be a "fix" for the problem. I expect this method is more of a tool to help peg down exactly where the audio is being corrupted.
I did note, when I ran the test in the lab and in the production, it was when we started our application up on the first time and not necessarily related to a windows log-in.
Note that our application starts up when windows logs in.
We've sent the rawrtp files for our test results via email and await your response.
Thanks,
Fitz
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 17 2009 at 11:00am | IP Logged
|
|
|
Question of curiosity.
The WriteRawRtpSamples() function.
Does this over write the file on each new call or would it be one continuous file for the duration that LS is running?
Can this be stopped and started w/o any adverse effects between calls?
If so, perhaps we could fix it to start before a call is made or answered and append a timestamp to the raw rtp file so each call would get its own file.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 17 2009 at 3:03pm | IP Logged
|
|
|
Hi Fitz,
You >>>
The WriteRawRtpSamples() function… Does this over write the file on each new call or would it be one continuous file for the duration that LS is running?
<<< Support
The raw Tx and Rx sample logs (per phone line) that are created by calling the WriteRawRtpSamples() API procedure remain open until the media engine is terminated. While the logs are open, samples will be logged for all calls (all media exchanges).
The logs can also be closed prior to termination by calling the WriteRawRtpSamples() API procedure again with the “EnableState” parameter set to FALSE.
Once the logs are closed, reopening them will overwrite the old log files.
You >>>
Can this be stopped and started w/o any adverse effects between calls?
<<< Support
Yes, exactly. You can open/close the logs with this API anytime.
You >>>
If so, perhaps we could fix it to start before a call is made or answered and append a timestamp to the raw rtp file so each call would get its own file.
<<< Support
That sounds like a great idea. The API proc will allow this.
Other notes regarding the direct email you also sent today.
Heavily loaded or bogged down system vs fast systems:
Looking at the audio logs you forwarded, a loaded down system is not the only way we may get into trouble. Yes, this seems to trigger the issue. More importantly, the same issue is occurring on faster host CPUs that have more than enough processing power for the intended purpose (as per your email information). From what I see from your raw Tx media sample logs, we have a time scaling issue. There is some state the media engine transmit/playout logic is entering where it is not recovering. My intuition tells me it is probably due to some subtle timing+computation associated with recorded multimedia playback buffers and then passing these buffers to the Tx signal chain for each phone line. I can actually see the cause of the “gurgling” sounding audio in your sample log file waveforms.
When you make the statement:
It baffles me why a faster system would experience the audio issue at all. But, the most important thing for us is not just to fix the audio issue as it stands, but to solidly track down exactly what is causing the problems in the first place.
solidly track down exactly what is causing the problems - I agree 110%. This same issue could occur on any system if the timing is just right.
Turning off Tx resampling/time scaling:
This next bit is very important.
Have you completely turned OFF Tx time scaling using the SetMixerResampleState() proc above?
From what I see in your Tx sample logs, turning off Tx time scaling should completely remove the “gurgling” transmit audio at the possible expense of Tx audio latency. I need to be sure I understand your test findings regarding this issue so as to narrow down causes.
I am absolutely confident this issue will be fully identified and fixed. For long term ,your production environment will not be at risk.
Work will continue this weekend on this issue.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 17 2009 at 4:33pm | IP Logged
|
|
|
Excellent news.
One more question to continue with the "question of curiosity." Can this be stopped and started during a call w/o adverse effects. I'm asking this because this particular case the SIP call is one long call even though the agents would experience "multiple calls".
I don't know if it would be helpful, but maybe we could start and stop the raw rtp during the "long SIP call" but break up the raw rtp files according to actual voice calls. Did that make sense?
----
Back to the subject:
NOTE: attachments mentioned below are of raw rtp files, not the recordings we sent at the beginning of this thread.
The first two pairs of raw rtp files (emails 1-L & 2-P with attachments) are calls experiencing the audio problem. The first email was from a lab (L), the second was from a production (P) system. These did not use the SetMixerResampleState() function.
The next two pairs of raw rtp files (emails 3-L & 4-P with attachments) are calls experiencing the audio problem, however we triggered the SetMixerResampleState() as specified in the support posting on April 16 2009 at 9:37am. Both triggered SetMixerResampleState() during the conversation. I don't know how we could specify exactly at what point it was triggered. If there is a method or you know of a way, please let me know.
Because of the environment we are using, the actual SIP call (in P) may have been active for a while before we actually have audio traffic. Shortly after the audio started the mic audio was noted as being botched, we triggered SetMixerResampleState(hME,FALSE,4,TRUE,4).
In both cases (L & P) the audio was corrected to a point. It was not completely clear, but there was a marked improvement in both environments. More so in P.
In the P-test, there was absolutely no way anyone could understand what the agent was saying during the beginning of the conversation. Once SetMixerResampleState() was called there was an amazing improvement in quality. Granted, the audio still suffered, but at least the agent could be understood.
If you require more raw rtp or additional information feel free to let me know.
Thanks again for your diligence in this matter,
Fitz
Caliginous issues are one of the worst ones to track down. Once solved, they can result in the greatest of triumphs.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 20 2009 at 10:12am | IP Logged
|
|
|
Hi Fitz,
You >>>
Can this be stopped and started during a call w/o adverse effects.
<<< Support
The SetMixerResampleState() API proc can be called without problems anytime during a call. At the time of calling the proc (if a call is active), there may be a bit of noise in the Tx call audio but it would last only for 20 to maybe 60Ms or so. If we can use this API proc to buy us a little time, that would be good.
The WriteRawRtpSamples() API proc can also be called anytime without issue.
You >>>
I don't know if it would be helpful, but maybe we could start and stop the raw rtp during the "long SIP call" but break up the raw rtp files according to actual voice calls. Did that make sense?
<<< Support
Yes – that made sense. This would be helpful. If you want to generate a few more Tx sample logs using this technique, we will definitely analyze the data. It would be a good way to insure that there is only the single “time scaling” issue going on.
You >>>
…I don't know how we could specify exactly at what point it was triggered. If there is a method or you know of a way, please let me know.
<<< Support
There is no way in the sample logs to know this or to force some king of “sample tag” in the log file.
You >>>
Because of the environment we are using, the actual SIP call (in P) may have been active for a while before we actually have audio traffic. Shortly after the audio started the mic audio was noted as being botched, we triggered SetMixerResampleState(hME,FALSE,4,TRUE,4).
In both cases (L & P) the audio was corrected to a point. It was not completely clear, but there was a marked improvement in both environments. More so in P.
<<< Support
That does make sense. Time scaling of the signal gets disabled which should improve the Tx signal quality if this is the primary cause. The fact the there may still be Tx signal noise is most likely due to the disruption if the Tx signal buffering that could occur die to calling the SetMixerResampleState() proc. Calling the SetMixerResampleState() proc was meant to give us an indication of where the issue may be located. It is not meant to be a complete workaround.
Right now, we should have enough info to get a software update to you. It primary issue now is: how fast we can complete the updates.
From the compilation of information we have received from you, we should be able to synthesize Tx signal path timings and what we think is going on with your host machines to locate the issue.
By the way, What OS are the problem systems running?
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 20 2009 at 11:11am | IP Logged
|
|
|
Both lab and production systems are running:
Windows XP SP3, patched all the way to the latest.
There are more details about hardware in our 2nd post (April 02 2009 at 9:16am).
-----
I'm switching back and forth between this and another high priority project. If you do not feel you need more data files, I'll return to the other project.
If you need more I will make the appropriate modifications to split the raw rtp files according to "actual calls" and forward the findings to you.
Just let me know,
Thanks,
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 21 2009 at 11:49am | IP Logged
|
|
|
Hi Fitz,
Ok, thanks for that additional info.
At this time we should have enough information to obtain the solution. If we need more info, I will ping you again.
I am working on this issue as we speak. We plan on synthesizing various record sample block timings to see exactly where the time scaling of the Tx audio signal is getting processed incorrectly. The issue seems very subtle but I am confident we will be able to recreate what you are seeing. Once we absolutely locate the issue, we can implement a solid update. This issue is being treated as high priority at this end.
The only other questions I have (for curiosity reasons):
Was this Tx audio issue recently noticed due to you running your agent station VOIP apps on new host hardware?
In other words, I assume for the majority of your deployed VOIP agent stations up until recently, everything is OK and the media engine is performing as intended. Is this correct?
Thanks,
Randal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Botched Mic Audio
