| Author |
|
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 22 2009 at 5:29pm | IP Logged
|
|
|
I have an update for you. Though we were under the impression the agent was using a USB headset. I have just found out that all the production tests were done using the on-board audio device (not the sound blaster) and an analog headset. (In fact the sound blaster card has been removed from the test stations completely).
(The problems with troubleshooting something remotely!)
I'll send you the raw rtp data from the test call we just finished.
There was no audio issue at all. The call was crystal clear.
Note: That on one call we did have an audio issue using LS 6.0.0.7. After upgrading to 6.0.0.11 I have been unable to duplicate a bad audio scenario.
Rest assured we will perform some additional tests and see if it is the difference between using an analog headset vs a true USB headset.
In addition, I understand the "USB" headsets they were testing with on other stations are basically a USB sound board with analog headsets plugged in. They are experiencing the problem.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 22 2009 at 7:50pm | IP Logged
|
|
|
Hi Fitz,
That is very interesting.
Request 1:
(From my previous post)
Was this Tx audio issue recently noticed due to you running your agent station VOIP apps on new or different 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?
Request 2:
Do me a favor, in the most simplest terms, please explain to me your host hardware setups that function perfectly and the hardware setups that suck. From what you have described, the record multimedia hardware (and drivers) is the only difference… right? I want to be able to completely understand and do not want to miss or assume something important.
Results of testing at LanScape:
We have a multi-line soft phone test setup here in the lab using the media engine. With this setup, we can synthesize all sorts of random multimedia hardware record timings. We have successfully recreated transmit audio like you have forwarded to me in your raw sample logs. That’s the good news.
The bad news is, the media engine is performing as expected. The only time you get that type of garbled transmit audio is when the average record sample block times from the multimedia hardware are way shorter than what is expected (20Ms). To keep things simple, the media engine basically is expecting sample blocks from multimedia hardware at a 20Ms rate and can handle pretty wide +/- variations in this timing.
The media engine starts to have issues and produces the bubbly/garbled audio when we push the record sample block timing to something less than 13 to 12Ms. We can see what is going on in the Tx signal time scaling code and why the audio is being garbled.
The good news is we have additional DSP techniques that can be implemented to improve the audio for these bad record timing scenarios. We are continuing to look into this. We would like the media engine to handle the widest possible timing variations as we move forward. There is a limit to what we can finally accomplish. I would suspect that we will be able to tolerate bad record timings down to 8-10Ms with the changes we are thinking to implement. This may or may not help. We do not yet have actual record timing information from your problem host machines.
Request 3 - Your record multimedia hardware:
Based on the testing performed here, we are assuming the hardware you are using for record functions is causing some pretty massive record timing variations. Can you shed any light on this?
We plan to get you a software build that will have additional Tx signal path improvements in addition to being able to log record timing information. We would like to eventually run this new media engine build on one of your problematic host machines to see the actual record sample block timings. With any skill, it should corroborate what we have synthesized here and will give us additional timing headroom to even use the problematic audio record multimedia devices.
Thanks,
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 23 2009 at 9:31am | IP Logged
|
|
|
We are still compiling the exact information you've requested. It was during this research we found there was a discrepancy in the understanding of what was and was not a USB headset. This leads us to question other possible "knowns".
Apparently even though we have described specifically what we need, there has been some assuming on both sides as to exactly what the hardware setups are and what they need to be.
I will reply when we are absolutely certain what the hardware configurations are, including the physical headset.
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 23 2009 at 5:01pm | IP Logged
|
|
|
Request #1
Yes. All other current deployments (and some older versions of LS) are performing without issue. This is one reason we are scratching our heads. It simply doesn't seem logical that only this one specific environment should experience these problems.
Request #2
I've sent some (more than simplified) stats on the systems that do and don't "suck" via email. I'm awaiting confirmation to post a more "public" version on the forum. I may not obtain that permission till Monday.
Request #3
I may be misunderstanding the question here. There is no "special hardware" required for recording the calls. We are using the software mentioned before via the callback function to port the audio to a virtual audio board (i.e. VAC - this is software, not hardware). This is kept out of the loop in regard to what is played/passed through RTP stream.
The recording application uses this VAC device as it's source to combine the video and audio for it's recordings.
Does this sufficiently answer your questions?
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 23 2009 at 5:20pm | IP Logged
|
|
|
I've formatted a more precise/definitive outline of all the environments we have discussed.
NOTES:
• I’m using new Environment numeration from this point on.
• The mention of “Customer” here indicates the company we are taking calls for and not the people who are calling into our service.
The environments listed below are migratory over an ambiguous amount of time. They reflect movement from one environment to another. They are broken up into table groupings to indicate simultaneous timelines.
1. We will not be concerned (at this time) with E1 as they have moved everything there to E2 and E3 and the echo issue has not been an issue after that modification
2. E2 and E3 are the environments that are in production and are experiencing the audio jitter issue
a. E2 migration occurred as a direct result of the echo issues
b. E3 were newer stations purchased due to growing volume
3. E4 is a test station I am using in the production environment (We had just run some tests with a different headset)
4. E5 is not filled out as we have not done tests for that environment at this time – I leave it here just to keep our internal docs and this in sync
5. E6 – E8 are all the “similar” systems which are not experiencing the audio issue.
Customer 1:
Environment # 1
System
Dell Optiplex GX260; BIOS A09
Hardware
Pentium 4 - 2.26Ghz
1GB RAM
40GB IDE HDD
Soundmax on-board audio
Software
Windows XP SP3, patched all the way to the latest
Symantec AV
LS 6.0.0.7
Headset
PLTDA60
Audio Quality
Echo issues
The second and third environments are what additional (Customer 1) stations were placed on. The headset was changed from E1 due to the Echo issues.
These environments are what production (Customer 1) is currently running in.
Environment # 2
System
Dell Optiplex GX260; BIOS A09
Hardware
Pentium 4 - 2.26Ghz
1GB RAM
40GB IDE HDD
Soundmax on-board audio
Software
Windows XP SP3, patched all the way to the latest
Symantec AV
LS 6.0.0.7
Headset
MX10 + Avaya phone
Audio Quality
Jitter
Environment #3
System
Dell GX760; BIOS A02
Hardware
Pentium Dual Core 3GHz
1GB RAM,
80 GB SATA HD,
Soundblaster 5.1VX sound card,
Software
Windows XP SP3, patched all the way to the latest,
Symantec AV,
Soundblaster 5.1VX latest driver
LS 6.0.0.7
Headset
MX 10 + Avaya phone
Audio Quality
Jitter
The fourth environment is my test environment, using a different USB headset.
Environment #4
System
Dell Optiplex 760
Hardware
Pentium Dual Core 3GHz
1GB RAM,
80 GB SATA HD,
Soundblaster 5.1VX sound card,
Software
Windows XP SP3, patched all the way to the latest,
Symantec AV,
LS 6.0.0.7 or LS 6.0.0.11 (depends on test)
Headset
AUDIO625 - Plantronics USB-01
Audio Quality
Jitter
Customer 2:
Environment # 6
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
LS 6.0.0.7
Software
Windows XP v5.1.2600 + SP3, all updates to 3/31/09
Dual boot: Windows 2000 + SP4
LS 6.0.0.7
Headset
PLTDA60 - (NOTE: some use the MX10)
Audio Quality
Clear
Environment #7
System
Dell Optiplex 280
Hardware
Intel P4 CPU 3.00GHz
512 MB RAM
40GB SATA
SoundMAX Integrated Digital HD Audio v5.10.1.452
LS 6.0.0.7
Software
Windows XP v5.1.2600 + SP3, all updates to 3/31/09
Dual boot: Windows 2000 + SP4
LS 6.0.0.7
Headset
PLTDA60 - (NOTE: some use the MX10)
Audio Quality
Clear
Environment #8
System
Dell Optiplex 280
Hardware
Intel P4 CPU 3.00GHz
1024 MB RAM
40GB SATA
SoundMAX Integrated Digital HD Audio v5.10.1.452
LS 6.0.0.7
Software
Windows XP v5.1.2600 + SP3, all updates to 3/31/09
Dual boot: Windows 2000 + SP4
LS 6.0.0.7
Headset
PLTDA60 - (NOTE: some use the MX10)
Audio Quality
Clear
Headset Configurations:
• PLTDA60 - USB headset (the actual headset is removable from the USB portion of this device and is interchangeable with the MX10 analog device)
• MX10 - Fully Analog device, this connects to either the Sound Blaster analog out/in-puts or the embedded audio device’s analog out/in-puts
o NOTE: this device is also physically connected to an AVAYA phone. I’m confused as to why the MX10 is connected to an AVAYA phone. This is certainly not something I know anything about. These are supposedly setup in such a way that the AVAYA phones do not impose an effect of any sort into the audio stream.
• AUDIO625 - Plantronics USB-01 (http://www.panafonic.com/b2c/product_info.php?cPath=27_28&p roducts_id=457). This headset is only on test station 042
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 24 2009 at 9:24am | IP Logged
|
|
|
Hi Fitz,
Great information. I also received your email version of this info. Thank you.
Regarding “Issue 3” from the above post, what I was asking was: What type of multimedia hardware is being used for audio recording? Your post and email information answers this multimedia hardware question fully.
We have created a build of the media engine that will tolerate wider audio record timings in addition to improving time scaling of the Tx audio streams from the media engine.
I am hoping to complete the first “bench testing” of this new functionality before the end of today. We should be able to get the results we are looking for. I will post again when we have our results.
It will be good to have a wider “operational tolerance” for all the multimedia hardware/drivers and OS combinations that are possible these days.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 27 2009 at 8:39am | IP Logged
|
|
|
Correction for E3 only.
There is no Sound Blaster card. It had been removed before our tests.
(copy/past error in my posting)
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: April 27 2009 at 9:11am | IP Logged
|
|
|
Clarification
Also, station 042 (last line of the stat-details post) is the station I have been testing on in the production environment.
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 04 2009 at 2:00pm | IP Logged
|
|
|
Ping?
We may have some additional information for you.
Do you have any news for us?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 05 2009 at 8:32am | IP Logged
|
|
|
Hi Fitz,
Yes we have some news.
We have implemented updates in the media engine play-out path that will tolerate wider variations in audio record times. The updates also use a different time scale algorithm to ensure recorded audio is synchronized to internal 20Ms block times and that phone line transmit audio is smooth.
We are working on what should be the final issue associated with the new play-out changes. This last issue has to do with minimizing Tx path latency while at the same time maintaining the highest possible audio quality. Be assured we are working to get this wrapped up as soon as humanly possible.
If you also have further info, do not hesitate to post.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 05 2009 at 3:54pm | IP Logged
|
|
|
I wish I had some definitive information to pass on, but I've only been able to keep my ear out for new developments regarding this issue.
The only information I can pass on to you is what I have understood and what others have said. I would not chalk any of this up to actual fact, but speculation might suffice.
The rough difference between the systems that have not experienced the audio issues appears to be a difference between those audio cards which claim to be HD and those that don't. I'm not certain exactly what "HD" would have to do with audio.
Is it possible the "HD" audio device drivers could be using a sample block size which is causing adverse effects with LS?
Re-Visiting something
When I was able to "simulate" the problem in a lab environment, I found that the audio in a full VoIP setup would be bad during the first call, but the second would be clear.
Can you speculate why a second call would clear the issue up in the full VoIP setup?
Note: LS never unregistered for this, nor would LS have restarted.
What is re-structured between SIP calls that could have fixed the audio?
Note: that the systems in production are using the environment where a single SIP call is placed and all audio traffic is started and stopped during this single SIP call via 3rd party applications. Because all "calls" were handled during a single "SIP" call, the audio would remain poor.
What would be the common thread here that causes the audio to be good on a second call or a re-register and new call that could "fix" the audio problem?
Are the audio connections with the devices started and stopped between each SIP call?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 06 2009 at 11:04am | IP Logged
|
|
|
Hi Fitz,
You >>>
Is it possible the "HD" audio device drivers could be using a sample block size which is causing adverse effects with LS?
<<< Support
The “HD” attribute is interesting. When the media engine receives recorded sample audio blocks from the multimedia hardware, the low level drivers are in the “food chain”. Any strange timing characteristics of received recorded sample blocks can absolutely be affected by the OS software drivers installed for the hardware. The sample block size that is received by the media engine would not be different but the timing or periodic nature of the received sample blocks is what is causing the play-out issue.
At this time, more and more new host PCs are being equipped with HD audio chips. It’s a natural progression. It is feasible that, in the rush to get new HD audio hardware into new PCs, drivers are not quite as good as they should be. I have seen this before over that last 20-25 years using various PC hardware.
You >>>
Can you speculate why a second call would clear the issue up in the full VoIP setup?
<<< Support
Sure, I love to speculate. :)
<Speculation>
If the fist call on these host PC are always experiencing the play-out audio issue, and then all subsequent calls are all fine, that points to an “initial condition” issue. Once again, there is some record timing situation that is setting up and causing the audio play-out issue. From what I saw in my lab, the recorded audio must be received at some weird non periodic rate to establish the problem. The non periodic rate is enough to put the audio play-out time scaling algorithm we use into a fit. It is a very weird problem and from first appearance, it is a problem that should not occur.
Why it does not occur for latter calls (after the first bad audio call), I do not know, I did not reproduce that behavior here. What I can say is that the updates we are implementing will widen the tolerance for the media engine to be able to handle larger variations in sample block times from record multimedia hardware. The new tolerance is now 20Ms +/- 20%. This should be more than enough to handle the current and future audio hardware situations. This update will effectively null out the issue of “non-periodic record sample block timing” from record hardware or installed drivers. In addition to that, this issue has allowed us to update our time scaling algorithm.
</Speculation>
You >>>
What is re-structured between SIP calls that could have fixed the audio?
<<< Support
When the media engine starts, multimedia record and playback channels are initialized for use. The record and playback channels are not un-initialized until the media engine terminates. For one or more concurrent calls, multimedia sample block recording is started at the beginning of the first call and then stopped at the end of the last call. The whole internal record path is stopped when no calls demand recorded audio. If a new call is established, the record path is again activated to receive recorded sample blocks. The only difference is on the first call, enabling recorded audio would immediately follow the initialization (the opening) of the record channel.
I do not know your exact record sample block timing but this indicates something. If I wildly speculate, I would say that the host’s multimedia record sample block timing is the worst immediately after the first open and then enable of the record path from multimedia hardware. Subsequent enabling of the record path does not experience the strange timing. Possible? Yes. Probable? I do not know for sure without hard record sample block time logs. One thing we do know for sure, the media engine should be able to handle even this one-time scenario.
You >>>
What would be the common thread here that causes the audio to be good on a second call…
<<< Support
Hopefully the previous verbiage addressed this.
You >>>
…or a re-register and new call that could "fix" the audio problem?
<<< Support
Hmm.. not sure what you mean here. Are you saying that a SIP REGISTER operation would clear the play-out audio of a “botched” first call?
You >>>
Are the audio connections with the devices started and stopped between each SIP call?
<<< Support
Already discussed above.
I will repost when code is available.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 06 2009 at 11:37am | IP Logged
|
|
|
Clarification:
me >>>
Quote:
| ...or a re-register and new call that could "fix" the audio problem? |
|
|
This was regarding the true full VoIP environment (V1) vs, the SIP environment where a single SIP call takes place for the duration of an agent's session (V2).
Our application (with LS) starts when an agent logs into Windows (registry entry).
The agent interfaces with our application, and performs their sign on process.
From here our application detects the Switch environment it is in and executes the proper procedures to signon with 3rd party apps (V2) as well as LS.
In (V1):
* Register LS with PBX
* Wait for a call (note: each call the agent receives is a new SIP Call):
In (V2):
* Register LS with PBX
* Login to 3rd Party apps
* Wait for incoming INVITE (initiated by 3rd party apps)
* Finalize login with 3rd party apps
In (V2), the SIP call stays active while the agent is signed on. Thus the "one long SIP call". The 3rd party apps handle audio direction and everything else. The only way to start a "new SIP call" in this environment is to have the agent logout of our application, then log back in. This results in taking down the connections with 3rd party apps, as well as the SIP Registration. When the agent signs back on, this "re-registers" the agent, and the process starts over again.
P.S. I have just received some generated *.nfo station information files with specific details on each of the stations if you are interested.
<speculation>
Perhaps it will give some indication of what hardware/drivers are buggy.
</speculation>
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 06 2009 at 2:07pm | IP Logged
|
|
|
Additional Info:
I've recently received this information. The following quote was regarding the audio card for the GX 760 (see above). The on board audio device uses the same 1/8" stereo plug for both mic and line-in audio. There is a soft-switch to adjust the gain of this accordingly. Testing "this," in the quote, refers to moving the soft-switch between "mic" and "line-in."
Quote:
We were testing this on a GX760 yesterday, but what we experienced is a bit strange: If the agent selects the default setting on the pop-up prompt, (which is mic in) the audio is all jittery. But...if the agent selects line-in, it sounds fine. (albeit a little echo)
|
|
|
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 06 2009 at 2:42pm | IP Logged
|
|
|
Hi Fitz,
I don’t know this for sure, but changing a setting like that most likely changes a driver setting somewhere. This is good info because it indicates to me that it is probably an esoteric software timing issue as we have already talked about.
If you want to upload the *.nfo station information files to your support FTP account, that may prove useful.
I see this as our steps to completion:
1)
Complete the current media engine play-out updates.
2)
Get your team a temp updated image to test and qualify. I am 99% sure we are on the correct path to resolve this issue. We have synthesized what we believe is the same issue here and the code updates look like a solid resolution.
3)
If we are OK, issue a real product update to you.
4)
If for some reason the problem still exists, get hard core timing data from one of your problematic host machines and continue. Hopefully we don’t get burned by the 1% unknown.
Getting this completed is “center stage”. It just takes time to implement the changes.
I appreciate your patients.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 11 2009 at 3:48pm | IP Logged
|
|
|
Hi Fitz,
There is an engineering release of the v6.0.0.12 media engine in your support FTP account. It includes updates to the media engine’s audio playout path and incorporates updated time scaling algorithm/logic. We will need your team to verify this image. The image is good for the next 2 months. Please see the file:
“VOIP Media Engine Engineering Release v6.0.0.12 Expires 6-30-09.zip”
Notes:
1)
A new startup value has been added to the START_SIP_TELEPHONY_PARAMS structure that gets passed to the StartSipTelephony() API procedure.
The new value is PhoneLinePlayoutBuffering. Your application should set this value to 2. The value 2 should work for all of your host machines. If for some reason transmitted audio is broken, increase this parameter value by 1 and retest the deployment. A value 2 should work for all your machines that have experienced the botched Tx audio. With this setting, transmitted call audio should immediately be clear for all machines and remain clear throughout. Increasing this value will ensure that Tx audio remains continuous but will also increase Tx audio latency. For the lowest latency, use the smallest value possible. As I mentioned, the value of 2 should work for all installs.
2)
You will have to rebuild you agent station apps against the new media engine header file. No way around this. Sorry.
Post with any test results you have. We look forward to good results from you.
Thanks,
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 12 2009 at 12:01pm | IP Logged
|
|
|
We should be able to run these tests shortly today. Possibly tomorrow as well.
I will report our findings ASAP.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 12 2009 at 12:27pm | IP Logged
|
|
|
Good show.
:)
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 13 2009 at 2:17pm | IP Logged
|
|
|
OK, preliminary test results:
Tests
1. Test with old version - verify bad agent mic audio
* Result - verified the audio issue still existed
2. Test with new version (6.0.0.12) using default '2' value
* Result - Bad mic audio
3. Test with new version, modify setting using value '3'
* Result - Slightly improved audio
4. Test with new version, modify setting using value '4'
* Result - Acceptable to good audio.
I don't know if this is due to the agent's voice, but when you experimented with this did the "agent's" voice seem to have a narrow frequency response in the higher range? Almost squeaky or high pitched?
I don't know if it is a side effect, but it sounds like the mid and low-range is turned down on an EQ.
Aside from that the audio is not suffering at setting '4'. It looks like you guys nailed it.
We will continue to run tests on this for the rest of the day.
We would like to know about how long it would take to receive a full release of 6.0.0.12.
Thanks and amazing work guys,
Fitz
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 13 2009 at 3:08pm | IP Logged
|
|
|
I'll update when we have performed more tests.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 13 2009 at 5:18pm | IP Logged
|
|
|
Hello Fitz,
When I read your post I started to develop a sinking feeling that we did not achieve the desired results. I am relieved that your results are in line with expectations.
A play out buffering set point value of 4 is OK. You should still have low latency tx audio that is clear.
A value of 4 indicates that the audio timing from the multimedia hardware is varying pretty wide… dare I say “sloppy”. There is no need to get real record sample block timing from your host machines. I can pretty much imagine what is going on timing wise.
Side Note:
We are going to implement ASIO streaming support in the media engine to effect very low latency audio I/O. When competed, this should lower latency even further for us all.
You >>>
…I don't know if it is a side effect, but it sounds like the mid and low-range is turned down on an EQ.
<<< Support
That does sound a bit strange. I assume you are using G729 for your calls. If so, make sure to use G729 and not G729A. G729A has slightly less quality because of it’s computationally efficient implementation but is bit compatible with G729.
I did not perceive any degredation in sonic content all the while during development and testing of the last playout updates. For voice, any fidelity “degredation” in the playout path due to time scaling the tx audio should not be noticeable by the human ear. Other polyphonic music may slightly degrade due to our time scale implementation but it is still very good.
We can investigate this further if need be. Just say the word. The only other thing that would be immediately possible would be to use iLBC or possibly ulaw or alaw codecs (bandwidth… I know).
You >>>
Aside from that the audio is not suffering at setting '4'. It looks like you guys nailed it.
<<< Support
OK... good.
You >>>
We will continue to run tests on this for the rest of the day.
<<< Support
Good idea… I would too.
You >>>
We would like to know about how long it would take to receive a full release of 6.0.0.12.
<<< Support
Whenever your team gets done with verification and qualifies the new build, say the word and we will release v6.0.0.12. We may need 2-3 days from your “go ahead” in order to perform the release.
It will be good to resolve this issue and move on. We are working full speed to incorporate many other items of functionality into the product. And yes this means multiple registrations, early media, REFER/NOTIFY call forwarding and quite a few other capabilities. We can talk more later.
Thanks Fitz,
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 14 2009 at 4:05pm | IP Logged
|
|
|
We have run some additional tests. Initial results were very positive.
Continued observation (see recordings on ftp) tend to be mixed.
The first recording "20090514143835" was with setting '3' the latter recording "20090514145407" was with setting '4'.
For the most part all calls I observed personally yesterday with setting '4' were acceptable as far as communication goes. Some were crystal clear, some had an odd sound to them, but didn't necessarily seem to have the issues we're dealing with. Today however, it has proved non-static.
It appears that during the course of the day we have had to fluctuate between these two values to "fix" the audio problem.
We are working on some additional tests and I will ping you once we have some more information.
Nonetheless we would like a full release version of 6.0.0.12 when it is available.
Thanks,
Fitz
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 15 2009 at 5:52pm | IP Logged
|
|
|
Update
Our tests, with the help of LS, have proven quite successful. We believe we have found the proper settings to compensate for any audio problems we have encountered.
Note: We are still on the quest to nail down exactly the cause of the audio problem diligently. As you said it is odd and very obscure.
Thanks again and again, awesome work guys,
Fitz
P.S. Just so you know, the powers that be are aware the audio issue is not induced by LS, but LS has compensated even for this scenario.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: May 18 2009 at 1:59pm | IP Logged
|
|
|
Hi Fitz,
Good update.
I checked the audio in the two AVI files you uploaded. If you have to use a play out buffering setting of 4, that is perfectly OK. AVI file “20090514143835” was OK and “20090514145407” definitely better (shows no signs of play out timing issues or discontinuous tx audio). This is good and is consistent with what we would expect.
At this point I think we have solved the play out issue for the call audio. There is however another noise issue that remains. There appears to be distortion in the tx audio of your agent station operator’s voice. This sounds like a typical clipping issue.
I took AVI file “20090514145407” and split out the audio into a separate wave file. I then analyzed the resulting audio. The audio shows clipping symmetrically around PCM sample values of about 22,000. A raw PCM sample value of 22,000 is valid but something in the tx audio path is saturating or causing clipping and thus the ‘scratchy” occurrences of the agent station’s voice. The agent station voice to the customer who called in should be very clear and not contain this noise.
Now the question is – where is this noise coming from? I would look at the input mic gain and input levels that are set using Windows mixer and determine if lowering the mic input gain removes the distortion. It should. It may also be possible that your media engine phone line volume is set too high and is possibly causing clipping. These are only educated guesses though.
With the play out audio issue solved, we need to remove this clipping issue so customers can understand the agent station operators each and every time. We can continue to work together and enable other capabilities in the media engine that will help us determine where this noise is coming from.
I will be out of the office for the rest of today but will be back Tuesday morning. We are in the process of readying v6.0.0.12. We still have time for additional testing and you should test as much as you can with the media engine v6.0.0.12 engineering image you have.
Thanks also for the p.s. from your previous post. That means a lot to us.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: May 19 2009 at 6:05pm | IP Logged
|
|
|
Update
Excellent feedback Randal. We have taken the mic volume into consideration while doing our tests.
To date we have completely wiped a station from scratch. Installed only the bare minimum:
* Fresh OS
* Installed our components w/ LS 6.0.0.7
Setup
NO AV (Anti-Virus) no updates (for now). We have tested with two different headsets the systems we listed earlier in this thread.
When we went through these steps and tested till late in the evening we had no problems with the USB headset. Once we reduced the volume of the mic to 22000 we did not experience any problems with echo nor with clipped audio.
Moving forward we used the analog headset "solution" to the echo issue and experienced some minor problems with the on board audio device. After adjusting the audio we actually seemed to get that garbled/jittered audio sound we sent in the original recordings.
However we were unsuccessful in duplicating that effect again so it could have been a fluke. During that call we were not able to reset any settings to return to a clear call. Nonetheless we quickly got the settings adjusted where the audio is of a good quality.
This is my presumption:
I believe the problem arose from a corrupted system image. That and/or bad settings for the audio device or corrupt/poorly written drivers.
Back to the Subject
I believe we personally prefer the USB solution as the agent was more crisp and clear with it than the analog headset.
side note: something I just recently found out, that analog headset is actually powered by a wall adapter.
We have literally placed hundreds of test calls and we have not experienced the "audio issue." Further evidence to anyone thinking LS had any part in creating this issue.
We will continue testing as we add AV and Windows updates to ensure we have created a stable, reliable and quality system for our production environment.
Once the new version of LS is available we should be very happy to put that on our production floor so that in that "fluke" case we may recover flawlessly.
Thanks again for a robust product, the insight, suggestions, advice and speculation. They have all been key in tracking this problem down and if not finding out exactly what caused it, to give us the tools and knowledge to keep it from happening again.
fitz
Let me know if you wish to be kept up to date as we move forward.
P.S. Is this about the longest thread ever on this forum?
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Botched Mic Audio
