Unity 3.1(3) messages with brief periods of silence

[doug.skinner]

This sounds a little like a couple of other problems posted here. We have a Unity 3.1(3) box, with exch. 5.5 on the box. Greetings and Unity prompts sound fine, but some voice mail messages end up with "holes" in them, or just brief periods of silence, where the callers voice is lost for just a syllable or two. I have a TAC case in on it now. It is intermittant, but fairly common. After doing some testing, it APPEARS that it may happen just as another call is answered by Unity. Every time Unity answers a call, the CPU util jumps to about 30-40%, just for a moment. For 3 or 4 test calls I've made so far, the "holes" seem to correlate to these CPU hits. The box is a 7837, with 1.2G ram, "clean" 3.1(3) install. Anyone experienced anything like it???

[doug.skinner]

OK, let me add a little more information, and another question:

Maybe it's not a CPU issue, or maybe there is more than one problem. It now seems like we could have an issue when the volume of the incoming audio drops below a certain point, and is 'interpreted' as silence. Prior to AGC, the customer always complained about the volume being too low with Unity, and that was with everything cranked up to the verge of causing distortion.

Question: Understanding that the documentation advises leaving WaveDBGainRecord set at 0 when using AGC, in an extremely low volume scenario, what would be the effect of bumping it up a couple db, while using AGC? Has anyone done this?

[lindborg]

I would advice not messing with the DBGainRecord setting at all - honest. You can play with the playback volume a bit but having two seperate parties fiddling with the volume level on an inbound stream is a seriously bad idea and wont likely solve your problem.

If you have inbound streams varying so wildly in inbound volume like this you have other problems external to Unity at play that need a closer look.

The AGC in 3.1(4) and later is much smarter, by the way... it wont try to boost silence, has limits on how low something is before it'll try to boost it etc... however AGC would not be inserting silence into you messages I wouldn't think. I strongly suspect you have something external to the Unity record process in play here.

[doug.skinner]

In general, the volume level is not varying very wildly at all. It's just all very low. The few that are too low, seem to have more problems. On the system, IP phone to IP phone is great. IP phone to PSTN is great. Unity system prompts and recorded names are great. But voice mail messages are quiet. When these drop-outs occur, they are recorded that way. Whenever and however you play them back, at whatever volume, they are the same. I'm not convinced that the volume issues are what cause the message drop-outs, but is does seem very possible. The CPU util. peaks mentioned above also seem like they could be related. At this point I'm working with TAC, working it by myself, asking here, etc., looking for any advice on what could be causing this. We're planning to ugprade Unity, but are also looking for some reason to think that this is going to help.

[lindborg]

Can you post what all your AGC settings are (you'll find them in HKLM\Software\Active Voice\MIU\1.0\Initalization\). Also, what the settings for the TSP playback/record boosts are.

This is for ALL recorded messages regarldess of if they're coming in on the PSTN or originating on an IP phone?

[doug.skinner]

AGCgainThreshold = 5

AGCminimumThreshold = 55 (decimal) (SEE NOTE BELOW)

AGCsampleSize = 8000 (decimal)

AGCtargetDB = 0xffffffe6 (or -26db as set with Advanced Settings Tool)

AGCuseCompression = 1

WaveDBGainPlayback = 0

WaveDBGainRecord = 0 (SEE NOTE)

NOTES: This was a clean 3.1(3) install. These settings were NOT all like this to begin with. They were set to these values with the Advanced Settings Tool. AGCgainThreshold was originally 40, and AGCsampleSize was 20000. This caused the bad "hiss" during silence that has been talked about elsewhere on this board. AGCminimumThreshold was not present, and I don't think it does me any good with 3.1(3). Both WaveDBGain settings were, and have been left at, 0, until last night after hours, when I did some testing with WaveDBGainRecord =2. It actually sounded pretty good, understanding that typical usage during the day is the only good test, and I don't know what else may have been effected negatively. That was the reason for my question on that particular setting. I also wonder, knowing that the settings were originally not set to what are now considerred good defaults, what else may not be set to optimum values.

One more note: The TAC engineer has asked about the \HKLM\SYSTEM\ControllSet002\Services\avaudio\Parameters\InsertSilenceThreshold setting. He hasn't elaborated yet, so I don't know why he wanted to know, or what is... (it's 3 by the way...)

[oliviers]

The reason why TAC probably asked about that setting was because of CSCdx41866. That setting could possibly affect how recorded audio sounds, but it is only used by TSP 6.0.2 and up.

[lindborg]

Rather than seting the DBGainRecord boost to 2, what happens when you change the AGC target DB to, say, -22 or the like? They should have the same effect, more or less...

The settings you applied are what ships with 3.1(4) and later - the AGCMinimuthreshold value wasn't introduced until 3.1(4), it serves no purpose in 3.1(3). This is the value where it'll "leave it alone" if it's quiter- this keeps it from trying to boost background hiss to -26 db which causes some odd sounding recordings and can introduce "pops".

[doug.skinner]

Update, and Question:

Update: We just upgraded to 3.1(5) in hopes of resolving the issue. (per TAC) It did not resolve it.

Question: When this system was first setup, long ago with Unity 2.4(5) and CM 3.0(9), it was configured to use a 30ms sample rate rather than the default of 20ms. (for all G.729 calls, and most G.711 calls) (This was done for some complicated reasons involving bandwidth, and CM bandwidth calculation/reservation which are now basically irrelevant.) We're now wondering, and taking steps to determine, if this could be causing out intermittent voice dropouts. Does anyone have any experience with changing the sample rate, and/or have any insight to what it might cause with Unity 3.x?

[oliviers]

From the first description that was given, it sure sounds like an issue where the wav driver is inserting silence into a recorded audio stream because it did not receive an RTP packet within the threshhold it had expected.

From the Regsitry setting mentioned earlier....

\HKLM\SYSTEM\ControlSet002\Services\avaudio\Parameters\InsertSilenceThreshold

I think the better key to check would be....

\HKLM\SYSTEM\CurrentControlSet\Services\avaudio\Parameters\InsertSilenceThreshold

That key (which is likely to contain the same value) is a pointer to the ControlSet00X that is currently being used by the system. Now, the reason why this setting was checked is because it reflects how much time (take the value of the key and muliply it by 20ms) the wav driver will allow to go by if it has not received a RTP packet. If a RTP packet is not received by this time, it will insert silence into the recorded audio stream.

It's possible that the problem isn't caused by 3.1.5 or the sampling rate, but by the change in the wav driver between 2.4.5 and 3.1.5 (the wav driver is installed/upgraded by a TSP installation rather than the Unity installation).

If...

\HKLM\SYSTEM\CurrentControlSet\Services\avaudio\Parameters\InsertSilenceThreshold=3

then, that seems like a reasonable setting (60ms of time where no RTP packets were receieve would have to go by before the wav driver inserts silence). This may or may not be a timing issue (if there really is a 60ms+ latency issue in RTP packets, there's other issues at hand!). Here are some ways to determine if it is a timing issue:

1. Bump the InsertSilenceThreshold setting to something ridiculously high like 10 and see if the problem continues (I wouldn't say that's a fix, just a troubleshooting step).

2. Run a sniff on a port that's span'd to the Unity net connection and measure the arrival time deltas of RTP packets.

3. Analyze one of the recorded messages to see if the silence has the "footprint" of the wav driver inserted silence.

Option 1 is pretty simple to try, although it requires a Unity restart. Option 2 is a pain (especially if the problem is intermittent and not readily reproducible). However option 2 can be a way to conclusively determine root cause. Option 3 is likely something TAC would have to assist on.

Maybe it already has been done, but it would be nice to rule out a possible timing issue.

[doug.skinner]

(been off-line for a while...)

In working with TAC, we've tried bumping the InsertSilenceThreshold up to 6, but not higher, and it did not help.

We have not run an actual packet sniffer yet, but instead have setup a 3rd party app on a spanned switch port, and recorded audio going to the Unity server. Yes, it was a pain, but we finally located a problematic message, recorded on Unity AND the 3rt party app. Unity recorded the "gaps," but the other app recorded the message correctly.

TAC has analyzed a recorded .WAV file with the error, and while they haven't told me the exact results regarding the "footprint of the wav driver inserted silence," based on their analysis, they've recommended swapping the NIC, and they're talking about a possible Compaq NIC driver problem, about which I have no further details as of yet. I think we're on the right track, but this one's being a real pain to fight. We'll be luckyif we still have a customer once we're done...

[jchorlton]

I think I have the same problem.

My Unity (3.1.5) when Recording also seems to skip when another call is answered.

The only difference seems to be Exchange 2000 and slightly less memory.

Have you made any progress with this annoying issue?

Thanks

John