| Author |
|
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 14 2007 at 9:59am | IP Logged
|
|
|
Dear Sir,
When playing a wav file with your Dual Line IVR sample if the wav file is for example 6 minutes exactly then the real time needed to play the wav file completly in PlaybackThreadCallback function of "Dual Line IVR ServerDlg.cpp" is about 6 minutes and 844 miliseconds. This means the wav file maybe is streched during playing.
For testing this I changed PlaybackThreadCallback function as below.
Code:
...
hWaveFile = 0;
OpenWaveFile(pDlg->hSipEngine,pPlaybackThreadData->pWa veFileName,NumBytesPerWaveBuffer,&hWaveFile);
StartTickCount = GetTickCount();
...
//At the end of the loop
DurationTickCount = (GetTickCount() - StartTickCount);
...
|
|
|
DurationTickCount will be the duration of playing the file completely.
I'm sure this is a bug because the same results is in my application.
The delay is increased when the file is bigger.
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 14 2007 at 11:38pm | IP Logged
|
|
|
For more test I changed greeting.wav file of Dual Line IVR sample to 18 mintues (3 times bigger than previous) and the delay increased to 2344 miliseconds. This is about 3 times bigger delay than previous test.
Both tests is done on the same computer.
IVR Computer Specification
Windows 2000 Professional SP4
CPU : Intel P4 Celeron 2.4 GHz
RAM : 512 MB
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 16 2007 at 6:06am | IP Logged
|
|
|
Hi Jalal,
Thanks for this post. We are looking into it right now. We will post back with results.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 18 2007 at 6:30am | IP Logged
|
|
|
Have you encounter the same problem in your tests?
Or you have not ?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 22 2007 at 7:48am | IP Logged
|
|
|
Hi Jalal,
Sorry for the delay. We are still trying to track down and verify the problem. We will get back to you as soon as we have meaningful information.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 22 2007 at 8:19am | IP Logged
|
|
|
I'm ready to help you in your tests. You may count on me.
Thanks
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 24 2007 at 9:24am | IP Logged
|
|
|
Hi guys,
Don't you want to answer this thread? !!!!!!!!!! :)
As we were developing the delphi wrapper, we tested the Single Line Phone for long period calls. Again there is the same delay rate in the sound. This means in the begining of a call the delay is less than 200 ms. But as long as call duration increases to above 10 minute, the delay also increases above 3 second. I don't have accurate delay but the delay seconds can be counted when speaking on the microphone and hearing on the other side's speaker.
I don't know why other customer's have not reported this bug before. Because this is a clear bug when writing softphone with Lanscape Media Engine !!!!
Please Please Please answer this thread. This is so critical.
Thanks
Jalal Abedinejad
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 24 2007 at 10:58am | IP Logged
|
|
|
Hi Jalal,
Thanks for being patient. We are very busy lately.
I know the dev guys are looking into the playback delay you reported for the IVR sample app. We are told “it is on the top o the list”. When they give us the answer, we will post the info to this support thread. We have to wait until they give us the info.
The issue regarding voice delay for very long calls:
If you are trying to continuously stream RTP media from one call endpoint to another without allowing for some kind of RTP media “dead time” then yes, voice delays can occur between PCs. There are a number of reasons for this.
The single best way to keep end to end voice delays down to almost nothing (40 Ms is the least delay we can ever achieve) is to not continuously stream RTP voice packets during the entire call. In other words, allow RTP “dead time” during the call.
The media engine has VAD on all phone line transmit channels. See the developer’s reference for “SetNoiseThreshold”. Call this API to set the basic “noise level” for the phone lines. Then, when the signal level (the person talking) falls below the VAD/noise threshold, no RTP media will transmit for the phone line and long call delays will not build up.
Now if you are trying to continuously stream music or something similar and you are not allowing for RTP “dead time”, you can experience call delays that build up. The default max call delay that can ever occur in the media engine is 1.28 seconds (this represents 64 20Ms sample blocks). This figure comes from default internal buffering settings that are used. If you want to reduce this maximum delay, then you can set the MaxMixerLinebuffers value in the START_SIP_TELEPHONY_PARAMS structure that gets passed to the StartSipTelephony() API procedure. You can set this value to 2 or greater. The default is 64. Reducing this value will affect the max receiver delay of any phone line. It also saves internal memory if it is set lower than 64.
If you lower the MaxMixerLinebuffers value to 2, the media engine will start to toss out received RTP media packets if the receiving media engine is falling behind. Try setting this value to 4 to allow a max of 80Ms continuous delay.
I see that the “MaxMixerLinebuffers” structure variable is not documented in the developer’s reference. I have made a note of this and it will be documented next release.
We have on our product road map a new API procedure that would allow application software to specifically set the max receiver delay. It should be out in an upcoming release.
Thanks again for being patient. Repost as needed,
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 25 2007 at 3:52am | IP Logged
|
|
|
Hi
<<< Support
If you are trying to continuously stream RTP media from one call endpoint to another without allowing for some kind of RTP media “dead time” then yes, voice delays can occur between PCs. There are a number of reasons for this.
>>> Jalal
We used your "single line phone" sample for test. So the defaults are as below.
NoiseDiscriminationEnableState=True
NoiseThreshold=200
SilenceDecay=300
It seems these parameters is not saved in ini file when they are set. So the default is tested.
We are not continuously stream RTP media, but the Media Engine is doing so in "Single Line Phone" from sound card input.
In our previous test we did not speak continously on the phone for 10 minutes. There should be just the environment noise on microphone. The noise is such low that can be heard hardly. After setting NoiseThreshold to 600 the and testing about 10 minutes the delay did not appear again.
But what happens if the dialog time is more than silence? Your example of playing music on the phone is another situation that causes the delay.
I think your RTP transfer speed is slower than RTP receive. It means if we ignore "dead time" you do not send RTP streams of exactly 1000 ms on 1 second of real time. So after some time your Tx buffer become full and Tx data starts to be lost.
As you said you have a buffer like IVR Tx Buffer for streaming sound card input to RTP. Is there any function like GetNumIvrTxBuffers to show available buffers for Tx of softphone. When I checked GetNumIvrTxBuffers for IVR sample, when the playback time increased the available IvrTxBuffers decreased so that after some minutes this number was 0.
You have said "There are a number of reasons for this.". Let me know what your reasons are for this?
<<<Support
Thanks again for being patient.
>>>Jalal
I'm patient but our customer and our CTO is not.
Thanks
Jalal Abedinejad
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 25 2007 at 4:21pm | IP Logged
|
|
|
Hi Jalal,
We have been performing testing regarding the timing of IVR transmit data using the Dual line IVR server example app that comes with the media engine.
There is something definitely going on as you described. The interesting thing is that the time warp associated with playing back wave data to an IVR phone line output appears to be a constant percentage of the total continuous playback time. Here are some numbers from our tests. The test times were chosen arbitrarily:
Code:
Total wave file size: 23,137 Ms (approximately 23 seconds)
Average time to play back: 23,187 Ms
Time Difference: 50 Ms
% time skew: 0.216%
Total wave file size: 46,724 Ms (approximately 47 seconds)
Average time to play back: 46,359 Ms
Time Difference: 85 Ms
% time skew: 0.183%
Total wave file size: 277,648 Ms (4 min, 37 sec, 648 Ms)
Average time to play back: 278,187 Ms
Time Difference: 539 Ms
% time skew: 0.194%
Total wave file size: 1,110,595Ms (18 min, 30 sec, 595 Ms)
Average time to play back: 1,112,719 Ms
Time Difference: 2,124 Ms
% time skew: 0.191%
|
|
|
The interesting fact is that the “% time skew” figures all hover around 0.2% of total playback time. Even in your tests, your numbers crunch out to be 0.23% and 0.21% for your test 1 and test 2 from above. Hmmm… strange.
We think the phone line’s transmit mixer may be the issue. We are going to continue looking at the transmit mixer timing and thread execution. If there is a bug there, it would cause something like what we are seeing. Also, in the IVR callback loop, calling the WaitForIvrTransmitComplete() procedure can affect the absolute timing measurements because the calling thread is put to sleep using a polling resolution of 100 Ms as the API waits for all transmit IVR buffers to be consumed/mixed and transmitted.
<<< Jalal
As you said you have a buffer like IVR Tx Buffer for streaming sound card input to RTP. Is there any function like GetNumIvrTxBuffers to show available buffers for Tx of softphone.
Support >>>
I’m sorry Jalal. I’m not sure what you are asking. Can you ask this question in another way?
<<< Jalal
You have said "There are a number of reasons for this.". Let me know what your reasons are for this?
Support >>>
The primary reasons are things like:
PCs may have slightly different “time bases” and no two are ever exact. We are working with VOIP call endpoints that are not synchronous in any way.
Windows thread execution characteristics: Windows executes all our thread code on a “best effort” basis. If something the OS needs to do comes along and pre-empts our audio code sufficiently in the media engine, there is not much we can do about it. Delays will creep in unless some form of “dead time” can be introduced.
<<< Jalal
I'm patient but our customer and our CTO is not.
Support >>>
I hear that. It is a bit uncommon that we have been so busy lately. It should get back to normal soon.
Repost as needed,
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 27 2007 at 2:57am | IP Logged
|
|
|
Hi
I try to describe my last question again. For playing a wave file on a phone line we should use TransmitInCallIvrData function. The data pushed to this function is saved on the Transmitter buffer. The number of available 20 ms buffers on the transmitter buffer can be get form GetNumIvrTxBuffers.
The same buffer should exist for transmitting sound data received from Sound Card's microphone on the phone line.
I used GetNumIvrTxBuffers to check how IVRTxBuffer available buffer decreased from 64 to 0 when playing a long period wave file on the IVR channel.
I think if it was another function like GetNumIvrTxBuffers, we could see how much available buffers is in Tx Buffer of "Single Line Phone" sample.
In my opinion the delay happened on the softphone call and the delay happened on IVR playback are caused from the same bug in your transmit buffer thread.
I don't know if I could describe the problem well or not.
Thanks
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 30 2007 at 4:57pm | IP Logged
|
|
|
Hi Jalal,
The software guys have finally performed their look into the transmit delay and “time skew” problem you described. They measured the “time playback” and “time skew” of different length wave files using a phone line transmit IVR output. The results: There should not be a problem. Here is the basics of their report:
-------------------------------------------------------
Transmitter Delay Test Results:
Tests were conducted using the dual line IVR sample application and v5.12.3.13 VOIP Media Engine. The goal of our tests was to determine that the media engine would transmit the proper number of 20Ms RTP payload packets for a specific length IVR prompt file sent out a phone line with minimal initial RTP transmitter delay and transmit the proper number of RTP payload packets that represent the IVR wave file (rounded up to the next higher 20Ms RTP packet boundary – null sample padded at the end).
In our understanding of the problem report via the support forum, Jalal reported that it appeared the media engine was not generating the proper number of RTP real-time payload packets for a specific length prompt wave file. His “in application” timing analysis of how long the Tx IVR wave file play back took was too long and got worse as the length of the playback wave file increased. LanScape support group initially confirmed this as TRUE.
In Jalal’s original post to this thread, he showed us that he was trying to “time profile” the transmission of IVR data to a phone line using the GetTickCount() Windows API procedure. The basic dual line IVR server sample app was used. The start time sample point was immediately after the OpenWaveFile() procedure call in the PlaybackThreadCallback procedure. The stop time sample point was taken immediately after the call to the WaitForIvrTransmitComplete() API procedure.
Timing the transmission of Tx IVR data this way will not yield an accurate result. Timing measurements performed this way will be longer than expected. The elongation of the playback time is dependant on thread execution times. It is also dependant on the resolution of available Windows timer functions – which are not accurate. Software interval timing using various Windows timing APIs can not be used.
As soon as the VOIP application starts to transmit “in call” Tx IVR data to a phone line, the sample block data gets queued to an input of the phone line’s internal transmit mixer. The processing of the phone line transmit mixer is performed in a different thread relative to the queuing thread (i.e. the queuing thread is the PlaybackThreadCallback() callback procedure.)
As soon as the phone line Tx mixer detects data for RTP transmission, the mixer will process the available sample block data and ready the mixed sample blocks for RTP transmission. This continues until the phone line Tx mixer goes into a blocking state due to lack of Tx phone line data to be transmitted (data starve condition).
Initially we performed timing similar to Jalal using GetTickCount(). This did not yield acceptable results. It appeared the time to play a Tx IVR wave file was always roughly 0.2% longer that would be expected. This figure was consistent as Tx IVR wave file length grew. We tested this characteristic up to playback wave file lengths of 37.1.191 (37 minutes, 1 second and 191 Ms). This max file size was chosen arbitrarily. We do not know what occurs when using playback file lengths larger than this.
We conducted timing of internal Tx digital mixers using a standard x86 hardware emulator and I/O ports. Internal timing showed that the performance of Tx IVR phone line mixers are correct for various system loading.
We then verified that the proper number of RTP payloads were being generated using the “internal” media engine API procedure SetPhoneLineTransmitRecordState() to allow all transmitted RTP data to be written to a wave file. Doing this allowed us to determine that the number of RTP packets actually transmitted correlated to the length of Tx IVR data used during testing. The number of transmitted RTP payload packets was the exact integer number of packets expected for the number of Tx IVR playback samples (rounded up to the next higher 20 Ms Packet boundary – NULL sample padded at the end).
As an added test, we took the open source Ethereal network analyzer and performed RTP packet sniffing tests on the Tx IVR playbacks. Ethereal validated the required number of RTP payload packets transferred for each test. Ethereal overall RTP times were very close to the hardware emulator times and always within the zero to +40 Ms error band. We have not looked at Ethereal source code and are assuming that some form of packet timing inaccuracies are present.
In summary, we do not see timing problems with media engine RTP generation as the result of local voice or Tx IVR generated signals.
In regards to RTP receiver maximum delays (falling behind):
Playing “very long” continuous Tx IVR prompts or continuous speech from a VOIP source may cause built up audio delays from end to end. This may be due to multiple factors such as differing multimedia clocks, real time audio (receiver) software being preempted by operating system tasks, etc. For normal VOIP speech, this generally is not an issue. For very long continuous Tx IVR playback, it can be an issue.
If an RTP receiver gets too far behind in its reception and processing of received RTP payload data, perceived audio delays can result at the receiving end until the receiver experiences some form of RTP “dead time”. We have noted this and will be taking steps to incorporate additional API support so applications can tailor RTP receiver “max delay” characteristics and also possibly Tx IVR VAD functions.
-------------------------------------------------------
Thanks Jalal for your input. We are always looking to fix issues. Repost anything else you may find. We apologize for this delayed response. Repost with your questions or concerns.
Thanks,
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 31 2007 at 12:29am | IP Logged
|
|
|
Hi Support,Software
Thanks for your detailed description. But I'm not convinced. We have tested another application as we had discussed later in http://www.lanscapecorp.com/forum/forum_posts.asp?TID=144&PN =3.
Exactly for providing a conference state between an IVR and two endpoints we used the Tx and Rx IVR APIs to “cross-wire” the logical phone lines.
We have used TransmitInCallIvrData function to transmit all received data from A-part in our PhoneLineReceiveAudioCallback function to B-part.
See following Delphi Code:
Code:
procedure Start;
begin
....
for i := 0 to MaxLines - 1 do
begin
SetAudioMediaFormat(hSipEngine,i,Media_Format_uLaw8k);
// tell the LanScape VOIP Media engine that we want to receive
// streaming phone line audio data when the phone line is active.
OpenRxIvrChannel(
hSipEngine,
i,
PhoneLineReceiveAudioCallback,// callback.
Channel ,// callback instance data.
TRUE,
AUDIO_BW_ULAW_8K,
TSIPChannelCT(Channel ).IvrReceiveChannelHandle,// save the returned handle.
SamplesPerIvrBuffer,
BytesPerIvrBuffer
);
end;
....
end;
procedure PhoneLineReceiveAudioCallback (var IvrRecognitionData : IVR_RECOGNITION_DATA);StdCall;
var
pSample : PByte;
SIPChannelCT : TSIPChannelCT;
Event : TEvent;
status : TELEPHONY_RETURN_VALUE;
begin
pSample := PByte(IvrRecognitionData.pSampleBuffer);
SIPChannelCT := TSIPChannelCT(IvrRecognitionData.pUserData);
if SIPChannelCT.SwitchedWithChannel <> nil then
if SIPChannelCT.SwitchedWithChannel.hSwitchTransmit <> nil then
begin
status := TransmitInCallIvrData(SIPChannelCT.SwitchedWithChannel.hSwit chTransmit,pSample);
if status <> SIPSuccess then
Log.Error(18,1,['TransmitInCallIvrData Error :',GetTelephonyStatusString(status)]);
end;
end;
|
|
|
The problem shows itself when noise threshold and silence decay are default. When A-part and B-part where speaking for more than 10 minutes, the delay that is increased to more than 1 second shows itself in the speaking.
I used GetNumIvrTxBuffers for both phone lines 0,1 in a timer of 50 ms period. When the "cross-wire" call started, number of available Tx Buffers was 64 on both lines. This number started to decrease to 0 by passing time. This means the IVR Tx Buffer became full after about 10 minutes. After this packets started to lost so that the spoken words where not clear on both sides.
I used your single line softphone for both sides. I also tested another softphone named "Phoner Free" but the result did not change.
Again I remention previous results for two softphones calling, which noise threshold and silece decay is off. This situation also has increasing delay.
The IVR playback delay may not be so important for simple IVRs. But it is important when IVR is used for playing FAX files. Because usually FAX files are long duration files, and timing is critically important during sending FAX.
To Support:
You did not answer my last question in my previous post.
Thanks
Jalal Abedinejad
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 31 2007 at 9:10am | IP Logged
|
|
|
Hi Jalal,
Ok. I think we have to go further here. The 1 second delay in 10 minutes of RTP streaming should be re-creatable here and detectable. We must be missing something simple. The symptoms are pointing to Tx mixer latency (lagging behind over long periods of time).
What we are going to do is to code up an example like you are talking about (cross wired Tx and Rx IVR channels) and perform additional tests. We will use Windows XP Pro as the operating system.
For our own support information, can you answer the following questions:
1)
FAX transmissions are full duplex modulated signals between the fax sender and receiver?
2)
Do the FAX endpoints continuously handshake using modulated signals for the entire duration of the fax session?
We will repost with additional results.
Regarding the question we missed from your last post: There is no API procedure for checking the number of available transmit mixer buffers for locally recorded audio (from the multimedia hardware). The point you made is interesting and we will also look at this as a test case.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: January 31 2007 at 11:02am | IP Logged
|
|
|
Dear support,
I have done three other tests on two different machines.
In my tests IVR is "Dual Line IVR sample" and softphone is "SingleLine Phone".
I made a 20 minutes wav file with help of CoolEdit which had a busy tone of 500 ms 440Hz and 500 ms silence. I replaced the wav file with your Greeting.wav. (Sorry!)
A-Machine :
Windows 2000 Professional SP4
CPU : Intel P4 Celeron 2.4 GHz
RAM : 512 MB
B-Machine :
Windows XP Pro SP2
CPU : Intel P4 Celeron 3.1 GHz
RAM : 512 MB
Test 1- Calling from A-Machine softphone to B-Machine IVR I used included Phone Line Recording option to record complete wav file. It was so interesting because as you had said in previous post it did not lost even 1 milisecond.
NOTE: To check delay, I deleted the first 300ms silence and checked start of each busy tone time with cooledit. I also used TAPIEx's Phone Tone Decoder to detect busy tones. So I'm sure the test result is accurate.
CPU Usage for B-Machine: Less than 2%.
CPU Usage for A-Machine: 30%-40%. <--- This is 10% softphone + 20-30% System
Test 2- I had run both IVR and softphone on the B-Machine.
In this situation I had a total of 800 ms delay, but delay is not periodically occuring. My Results:
1- The delay is made of sum of some chunk delays which is always a multiplicant of 20 ms.
2- When delay is happened softphone has recorded silence. Because it had sometimes broken 500 ms busy tone.
3- Softphone takes a lot of CPU Time.
CPU Usage for B-Machine: 10-15%. <--- CPU usage is not as much as previous A-Machine's CPU Usage becuase this computer has faster CPU
Test 3- I called form A-Machine's softphone to B-Machine's softphone. I also disabled noise discrimination.
In this situation I could not play my wav file. But I played DTMF with help of Buttons. I can not exactly how much was the delay, but it is at least 2 seconds after 20 minutes.
CPU Usage for A-Machine: 30-40%.
CPU Usage for B-Machine: 10-15%.
Answering your two questions:
1-Fax transmissions are half duplex, not full duplex.
2-No, Faxes just handshake in start of a call.
My Opinion About the delay problem:
I think you have used lots of Threads to implement your Media Engine. But unfortunately task scheduling costs lots of CPU usage.
So when for a short time a thread is starved, then delay will be occured.
I think you should optimize your codes to use as less new threads as can.
Thanks
Jalal Abedinejad
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: February 01 2007 at 12:46am | IP Logged
|
|
|
Hi
Last night I did not close softphones in Test 3. After about 14 Hours the delay is not increased from about 1.5 second. So this means the delay in softphone has a maximum. I think this is max stored data in your Tx buffer.
Is it possible to describe what is your algorithm for sending exactly 8000 samples in 1000 miliseconds? (for ulaw codec)
We have had some expriences in windows timing. I think if you could send me your source file for sending RTP packets, we can check if any bug would exists.
Thanks
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 01 2007 at 8:19am | IP Logged
|
|
|
Hi Jala,
Thanks for the additional information. You are doing a great job in reporting these details. This helps tremendously.
I know the dev guys were performing additional tests yesterday on various host PCs we have in the lab. We will check with them when they get in and see what new information is available.
Thanks for the offer of reviewing the RTP transmit source code. We will inform the dev guys of this. What we suspect the problem to be is that Tx phone line threads are sometimes experiencing small amounts of latency in the thread execution. The time slice for these threads is 20Ms. If a small amount of latency builds up each time slice, then eventually the final RTP data that gets transmitted will be delayed – up to a max of 1.28 seconds (64-20Ms buffers). In other words, the Tx mixer threads are running too slow on average. This seems to correlate to what you are reporting. In this case, the MAX worst case delay would be the same max length for local voice coming from a multimedia sound card or for Tx IVR data being streamed to any of the phone lines. We will be working on this continuously until we get a proper resolution.
We will repost as soon as we have something solid to report. If you have further info, don’t hesitate to post it.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: February 02 2007 at 8:58am | IP Logged
|
|
|
Hi
<<< Support
the MAX worst case delay would be the same max length for local voice coming from a multimedia sound card or for Tx IVR data being streamed to any of the phone lines.
>>> Jalal
I agree about max worst case delay for local voice coming from a multimedia sound card. But max worst case dalay for Tx IVR is not a constant value.
This is because when Tx buffer is full, new generated sound from multimedia sound card will be discarded. So the max delay will not go above max length of Tx buffer.
But for IVR applications new voice data will not be pushed to Tx buffer until there is some free buffer locations available. So no voice data will be tossed out, and delay will be increased when playing wav file is bigger.
I have two new proposal.
1- Why do you buffer received data from multimedia card? You can send received data from multimedia sound card immediately. This way you will not need using sleep in your send Tx buffers' thread.
By this solution the max delay for softphone applications will be canceled.
2- This is my guess of your IVR send RTP packets routine.
Code:
while( send thread not terminated) do
{
sleep(20);
if there is any packet in Tx buffer then
send head of Tx Buffer to RTP.
....
}
|
|
|
If my guess is true then your algorithm is wrong. This is because windows does not garantee sleep(20) to sleep the calling thread exactly 20 miliseoncds.
For sending IVR voice packets you should calculate exact amount of time passed from start of playing, and use sleep with lower duration.
We can also send some pacekts at the first of playing without regarding time. The number of these packets should be the number of time slices we are
sure other party has free rx buffers.
This is my solution for this problem.
Code:
LastTimePacketSent = GetTickCount - 20 * NumberOfTimeSlicesWeAreSureOtherPartyHasFreeRxBuffers;
while( send thread not terminated) do
{
sleep(5);
if (GetTickCount - LastTimePacketSent) > 20 then
{
NumberOfTimeSlicesWeAreBehind = (GetTickCount - LastTimePacketSent) div 20;
for i = 1 to NumberOfTimeSlicesWeAreBehind do
{
LastTimePacketSent = LastTimePacketSent + 20;
if there is any packet in Tx buffer then
send head of Tx Buffer to RTP.
}
}
....
} ;
|
|
|
Again I propose you let me see your source code for sending Tx buffers. This will help solving the problem faster.
Thanks
Jalal Abedinejad
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: May 01 2007 at 5:07pm | IP Logged
|
|
|
Hi there,
We are experiencing the exact same issue. Once playing a wave file into the transmit buffer, audio playback starts to lag when connected to another line. It seems to be at most around 1.8 seconds as mentioned here. This also happens if two calls are directly connected, and we simply transmit the received side to the other side (cross the lines) – and if one end is transmitting continuous tones/noises. We have tried a few items to reduce lag generated lag caused from wave file playback:
1) Reduce number of transmit buffers (no really effect seen) to 50.. we could try lower still
2) Wait some random number of seconds in between IVR voice prompts before we start playing more.
3) Also wait many seconds when connecting another phone call to the active call (which was in IVR session) – waiting about 15 seconds
2 and 3 aimed to allow the audio to finish playing, while allowing for plenty of “dead time” RTP traffic. Now, after some tweaking, this did indeed reduce the lag to not even noticeable. However, it doesn’t take much voice coming through (when crossing the line data) to generate the lag again. And of course, this happens when not playing wave files, but just constant streaming data. Also, our tests are all conducted within the same LAN. So, I think this problem is exactly as mentioned with the transmit buffer thread timing being way off, causing delays in sending. Is there any progress on a fix for this?
One thing to also note, is that the lag is much less noticeable when both soft phones connected (through the IVR system) are Lanscape phones – probably because of noise reduction. When they are other phones, the lag build up is quick and very noticeable.
Anyway, the work arounds kind of work, but the issue could be better handled inside of the transmit thread as the original poster noted. Also, we think a method for flushing/clearing the queued transmit buffers would help clear buffered data induced lag, as well as make IVR prompts sound more responsive.
Andrew
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: May 02 2007 at 12:00am | IP Logged
|
|
|
Hi juice,
They have reported me directly this bug is fixed, but they will not release it until next version!!! :(
Regards,
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 02 2007 at 8:36am | IP Logged
|
|
|
Hi Andrew,
Thanks for taking the time to submit a post that contains accurate and valuable information. We know this takes effort on your part and it is appreciated at this end. Good job.
You and Jalal have done great work in passing your information back to us so rest assured that we are going to address any existing latency issue(s).
There are three main identified areas in the media engine that we have analyzed and have tentative proposed enhancements ready to mitigate/minimize continuous media delays.
Here is the current unofficial summary:
Transmit related audio latency:
There are two areas that need consideration/improvement.
(1) Transmit mixer latency:
Each phone line in the media engine has associated with it a transmit mixer that digitally mixes digital audio from multiple sources – from other phone lines, from locally recorded audio and from Tx IVR outputs, etc.
The code for the mixer is based on an adaptive algorithm that works to keep the mixer time slice right at 20Ms +/- (delta error). Under certain situation it is possible for the mixer code to miss a block time and therefore cause audio that should be transmitted to be delayed by 20Ms. This shows up as longer playback times when continuously streaming wave file data to the phone line in IVR based apps. As Jalal reported, it may take 30.080 seconds to stream 30 seconds worth of audio data to the phone line. The longer the continuous Tx IVR streaming, the more delay that can build up. More accurate mixer code will alleviate this.
(2) Multimedia record real-time behavior:
Another latency issue is that multimedia record functions have been shown to record 20MS blocks on data in under 20Ms depending on your multimedia hardware/drivers installed. Something like 19.9998Ms for each expected 20Ms block of recorded audio data. Over time, the record functions from the multimedia hardware can generate more 20Ms blocks of data that start to accumulate in the phone lines “locally recorded audio” input and cause transmit delays of that recorded audio. Audio resampling will alleviate this.
Receive related audio latency:
There is one area that need consideration/improvement.
(3)Delays associated with multimedia playback of received RTP media:
This delay issue is similar to that identified in item (2) from above. In this case however, received RTP payload data that is received from the phone lines is digitally mixed and set to the host’s multimedia playback system. It has been shown that multimedia hardware playback can take longer than 20MS per block – something like 20.0003Ms for each 20Msblock of data that the media engine plays back. Over time, this causes a backup of received audio data. Audio resampling and/or VAD (Voice activation detection) on the final digitally mixed playback audio will alleviate this.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: September 20 2007 at 6:31am | IP Logged
|
|
|
Hi,
Is it possible to schedule a date for releasing a version to fix this bug?
Jalal
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: October 04 2007 at 6:13am | IP Logged
|
|
|
Hi,
It seems you have forgot to answer my last message on this thread. I had posted my last message 2 weeks ago !!!!
Jalal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 04 2007 at 7:12am | IP Logged
|
|
|
Hi Jalal,
Unfortunately we can’t state a solid release date for this. I know this sucks but that’s the way it is. Other paid support enhancements/issues are ahead of this one and there are only so many resources here. You will have to be patient until we release the next official version. Try not to be too upset. We plan to go through the media engine and tighten up all the continuous audio paths where possible. If you want this done immediately, please open a support contract with us. We are glad you are our customer and we are working long hours to get customer requests fulfilled.
Support
|
| Back to Top |
|
| |
Jalal
Vetran
Joined: April 24 2006
Location: Iran
Posts: 188
|
| Posted: October 04 2007 at 7:43am | IP Logged
|
|
|
Hi,
Is there any predict about your next release date?
At least can you say if it will be ready before end of this year or not?
Thanks for your response.
Jalal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Playing Delay Bug
