Is it possible to adjust the recording level in 3CX VM?

[Halea]

Greetings All:
Lately, I've been relying quite a bit on VM message forwarding through email attachment. The system works fine although there are some delays in getting the VM kick in etc., but what I need to address first is the audio recording level issue; it's relatively low, in a noisy environment it's hard to understand the content of the audio message. I tried to playback the wav file on several computers, they all required that I turned the volume to the maximum, yet the volume wasn't sufficiently loud.
I thought that there may be a difference whether the call came infrom a VOIP phone or over FXS; VOIP is only slightly better, so I guess the issue is in the conversion of the compressed incoming stream int a wave file. I may be mistaken, frankly I didn't think about all the steps.
I hope one of you has tackled this issue.
Thanks for any feedback.
Halea

 

[wisecomputers]

my question is how can you put a wave file into someones voicemail. I would like to see you be able to upload a wav file for use in voicemail. At the time it looks like you have to call the extension, and record it thru a phone. If we could upload one we could give a vbetter voice quility.

 

[archie]

The solution: there needs to be a way to adjust the gain when recording vm's sent as email.

Almost any PSTN gateway has an ability to auto adjust gain.
Question: have you ever tried it?

 

[SY]

Stepan,
You didn't answer my question about who does the format conversion. My question about the wave stream's format was just to illustrate my point that somehow, someone, somewhere defines which parameters to use.

"route" of "vm" audio signal delivered by email. "Green part" is a work of PBX.
Microphone->analogsignal->preamplifier/amplifier->ADC->PCMdata1->coder->transport->decoder->PCMdata2->wav_file->email->wavfilereader->PCMdata2->DirectShowFilters->PCMdata3->DAC->analogsignal->preamplifier/aplifier->speaker

PCMdata1 is provided by external source
PCMdata2 is data received by PBX and PBX delivers it by email.

format of PCMdata1 and format of PCMdata2 is the same - PCM, 8kHz, 16 bit, mono. Spectral characteristic of audio signal represented by PCMdata1 and PCMdata2 is not the same. "recording level" is the same. (to be more precise, it is almost the same because spectral charasteristic is modified by codec).

I hope, I have answered your question and passed your test...

Two more questions to you:
1- Are you a software engineer?

It is very difficult to provide answer for this question.

2- Are you a native speaker of the english language?
Halea

No, I'm not a native speaker of the english language. Sorry for inconveniences...

Regards

 

[SY]

Let's draw an analogy with common recorders:
1. Source of signal (volume adjustable)
2. Receiver of signal (recording level is adjustable)
3. recording device
First 2 entities adjust parameters of signal which come to entity 3.

I my country, that technology works different:

1. Source of signal (Emits sound/pressure waves. Volume MAYBE "adjustable", but I can't make the birds in the trees sing louder!?)
2. Receiver of signal (Converts sound waves into electrical signal, e.g.: Microphone - usually NOT adjustable)
3. Recording device (Transcribes electrical signal onto store media, converting it to magnetic field, light signal, etc. Has "recording volume" control!)

The only item that has a recording volume control (or has an "automatic" level control that boosts recording level for quiet input!) is the THIRD entity, which is what 3CX is missing.

:idea: Now I understand why you are having such a hard time relating to this request. It appears in your country, the birds have little "dials" to make them sing louder. The tiny microphones have built in amplifiers and slider controls that boost electrical output - and that's why they build your recording devices without any adjustments or automatic recording levels.

Nice post, and especially "idea".
I hope, You can find more information about my country in the answer to Halea's post (see above)

Regards

 

[nb]

You know - we can close this case once and for all :

Give me a number where I can call and we will see how the voicemail is played. Forward this number to an extension and set to receive an email notification. I will be calling from overseas. Ill be the bird - fair enough?
You can send me your number by private message.

I am going to use a phone at random - I can do it over a voip provider and over PSTN.
Another thing you can do is the following - to rule out 3CX.

Get someone to call you using your voip provider, but before go into the PROVIDERS account settings and set voicemail answer machine so that the provider stores and sends the message for you not 3CX. Comparing internal VM to external VM is not accurate. VP have this function. Then forward the voicemail to your email. The Provider must forward this not 3CX again. Have you tried this? This is the first thing I would do. In PSTN by doing this you will be eliminating the gateway too so it is not recommended. However as archie said, you can increase Gain. This is different per gateway.

Another thing guys - you cannot expect to have the same quality when you are leaving a message from internal extension to internal extension compared to a message passing from triple the hops and devices - let us be reasonable. There is the user (or the bird) that maybe is not shouting enough ... or maybe has a low mike, or maybe he/she is located in one of the "countries" referred to in this post. Then there is the provider, followed by the PSTN gateway, 3cx... The scenario is totally different. Nonetheless I leave VM from every possible scenario - I always get them right. The only times when they are not understandable for me is when I try to play a file over RDP. Or when I am on a slow connection - but in that case I get broken audio.

In situations like these for me to put up the volume to hear a message is pretty acceptable. OR and there is a BIG OR. Change media player pls. What Media player are you using?
I played the attached files on my machine. They played well for me. Understandable. Yes the landline VM was lower than the other. Test : Get the attached files and play them with Media player first. They try using VLC player. You will see the difference.
Media player full sound and VLC half way have the same audio. This means that Media player needs the boost ... for voicemails. Or the Bird...

 

[Andy Schmidt]

Give me a number where I can call and we will see how the voicemail is played. Forward this number to an extension and set to receive an email notification. I will be calling from overseas. Ill be the bird - fair enough?
You can send me your number by private message.

201-934-3414, Ext. 20

 

[fjkeith]

We have experienced this problem as well. Our system is V5.1, inbound SIP trunk provided by nexVortex, phones are Polycom 600 SIP phones with default audio settings (Polycom recommends not tinkering with these).

When I call from my old desk phone (1980's vintage analog PBX) to my direct dial number (678-264-2730) and leave a message I get the following results:

1. My voice volume was "moderate", along the lines of speaking reasonably loudly, but not so much as to disturb someone in an adjacent cubicle.

2. Playback on the PC is VERY low, much lower than any commercial MP3's or Windows built-in sounds

3. Playback via the Polycom 600 phone is weak, much softer than the built-in 3CX system prompts. Polycom phone volume is set at mid-level.

If anyone wants to ring my direct number above and leave a message, I will ZIP and post to the forum for users to review. If you leave a message, please indicate the equipment used (i.e., your phone) and your "path" to the phone network (PSTN, analog/VOIP, etc.). Please speaking using moderate volume tone (don't whisper, don't shout).

We are still in a test mode with our 3CX installation due to the low volume levels and the fact that one cannot hit a keypress to bail out of the voicemail system and reach a live human. I think V6 makes some progress on the VM front (I hope!), but the audio levels are still an issue.

Since my configuration uses a SIP trunk on the inbound side, I cannot tweak any gain settings there. nV assures me that THEIR system conforms to all relevant standards in terms of audio levels, gain controls, etc.

Tests I ran:
Calling OUT from 3CX system via nV SIP trunk, INTO my legacy system VM - audio levels fine fine on legacy PBX
Calling OUT from 3CX via Linksys SPA400 gateway to PSTN line, INTO legacy VM - audio levels fine on legacy PBX
Calling OUT from 3CX via nV back INTO 3CX via nV - audio levels weak (WAV file attached)
Calling OUT from legacy system INTO 3CX via nV - audio levels VERY weak (WAV file attached)

I do not have an inbound gateway-PSTN line that I can use for testing.

Bottom line: audio levels at phone during normal conversations are acceptable, volume levels in recorded WAV files are way down. I will do a VU test on my WAV files later (at home tonight), or maybe someone else can analyze my attachment and post a result here?

To Halea's point above, there probably are embedded gain settings in most audio processing library code chunks. Determining if this is the source of the problem might be tricky (for me anyway, since Pascal (!) was my last experience with "real" programming back in the - gasp - 80's).

cheers,
Joe

 

[fjkeith]

Andy, thanks for the test calls!

As you suspected, the final call (via VOIP provider) was the loudest on playback. Verizon cell was in the middle, PSTN call was weakest. All calls in attached ZIP file.

This whole thing is vexing!

cheers,
Joe

P.S. The forum system tells me that my ZIP file is too big (exceeds 256k, mine is 9xxkb with three WAV files). Grump.

 

[Andy Schmidt]

Dear Joe:

thanks for your interest in this issue. I have left three voice mails on that number. One from a Verizon Wireless cell phone, one over a PSTN land line and one over a VOIP provider.

I'm glad to see that customers who are knowledgable about sound processing are starting to chime in.

I fully understand that this is NOT a bug in 3CX, but 3CX is the one location where all these different sound source come together and thus is the logical place where an "gain equalization" (and/or automatic gain) would be implemented. I also did notice that the 3CX prompts are extremely loud... (which by itself is not a bad thing, it improves the signal/noise ratio). It's just that they need to bring the voice mails to that same gain level.

 

[fjkeith]

file #1

 

[fjkeith]

file #2 and #3 are each over 256KB. If anyone wants the combined file via email let me know.
Joe

 

[SY]

...
Bottom line: audio levels at phone during normal conversations are acceptable, volume levels in recorded WAV files are way down. I will do a VU test on my WAV files later (at home tonight), or maybe someone else can analyze my attachment and post a result here?
...

Hi Joe,

path of audio is:
Source->(1)->PBX->provider->(2)->PBX->file

(1), (2) and file are checkpoints.

Please perform VU tests for all three points. is there any differences?

Thanks

 

[fjkeith]

OK, here's an additional angle to consider.

Generally, the recorded levels of voicemail in the 3CX system are MUCH lower than the recorded level of standard prompts. Compare the volume levels of the VM and prompts in the attached ZIP file. The voicemail (which is louder than many I get) peaks at about -11 dbFS, the prompts peak at about -4 dbFS (decibals Full Scale, 0 dbFS = max volume, or all 1's in a digital audio file).

Based on the test messages that Andy left me, there is definitely some variability between the volume levels encountered from various sources (cell phone, PSTN call, VOIP call). I have NEVER had a situation where the VM was "too loud".

So, here are my suggestions:

1. Implement an AGC (automatic gain control) algorithm for recorded VM messages that, in essence, sweeps each recorded file for its peak dbFS, and then re-records the file with enough gain adjustment to set this found peak at -4 to -3 dbFS. This will calibrate the VM recordings to be approximately the same volume as the 3CX prompts.

2. Give the same treatment to recorded prompts (i.e., my recording of "You have reached the voicemail box of Joe Keith", etc.). That way, the volume of my voice prompt presented to callers will match the volume of the "beep" and other system sounds.

One big issue here is that most analog PBX systems implement AGC (which is trivial on an ANALOG signal), and I suspect, they implement some degree of signal compression as well, which reduces the dynamic range of the audio signal in an advantageous way. This "improved" audio experience is the competition! It may not have the features and capabilities of a VOIP system, but it SOUNDS BETTER. I don't think there is much that can be done about adjusting the gain of a live packet stream (except maybe in the phone). If the "PBX delivers audio" setting is checked, the latency introduced is intolerable. But, MAYBE, if 3CX could add an option where the audio is a straight pass through the server (minimal latency) EXCEPT that a free-running AGC algorithm increases/decreases the gain of the digital signal, we might be onto something. Pure digital gain adjustments should be very low delay on the packet stream.

The bottom line for me is that my users will mutiny if I force them onto the "too quiet to hear" system. I have already purchased a license (last December), but I still have not rolled out because of the low audio volume problem and the "can't escape VM by pressing 0" problem.

Implementing AGC for VM recordings should be child's play, and a little extra latency does not affect quality. Implementing AGC on live calls is trickier, but I suspect still doable.

#CX support, please try repeating the test I ran in the ZIP file (leave yourself a VM message to your extension, then compare the playback volume with the playback volume of the system prompts). These should be the same, or nearly so, for an acceptable user experience.

thanks!
Joe

 

[fjkeith]

Some useful links:

http://www.sencore.com/newsletter/Oct06/MeasDigAudLvls.htm
http://homerecording.com/bbs/showthread.php?t=204358
http://www.moultonlabs.com/more/bits_really_bits/
http://www.nvision.tv/newsletters/Dec_2007/dec_news_tips.html

Takes me back to my circuit design days! ;-)

 

[SY]

Some useful links:

http://www.sencore.com/newsletter/Oct06/MeasDigAudLvls.htm
http://homerecording.com/bbs/showthread.php?t=204358
http://www.moultonlabs.com/more/bits_really_bits/
http://www.nvision.tv/newsletters/Dec_2007/dec_news_tips.html

Takes me back to my circuit design days! ;-)

Thanks a lot for your suggestions and links.
Could you please answer my question (regarding VU test at all three points)

Thanks

 

[fjkeith]

I do not have the ability to check at point (1). Point (2) is a digital signal, internal to 3CX (my provider is nexVortex, and the signal path from nV to PBX is pure digital).

At point (3) (the WAV files) I get:

"end of messges" WAV file (peak) = -5dbFS, +2.4VU
recorded VM WAVE file (peak) = -11 dbFS, -6.8VU

Because VU is an averaging algorithm, the VU difference is about 2/3 of the peak dbFS difference.

Ultimately, for user acceptance, the audio properties of our new phone system need to be as good as our old system (vintage 1990). This includes the ability to deal gracefully with varying audio signal levels presented by foreign systems and the PSTN. If the new system is "sensitive" to such variations (which will happen, and are unavoidable), then it will not be accepted. It does not really matter if the true "fault" lies somewhere other than with the 3CX implementation. If the real world is going to continue to throw varying signal levels at the 3CX system, then the 3CX system needs to be able to compensate for these at least as well as "old" systems do.

thanks!
Joe

 

[SY]

I do not have the ability to check at point (1). Point (2) is a digital signal, internal to 3CX (my provider is nexVortex, and the signal path from nV to PBX is pure digital).

At point (3) (the WAV files) I get:

"end of messges" WAV file (peak) = -5dbFS, +2.4VU
recorded VM WAVE file (peak) = -11 dbFS, -6.8VU

Because VU is an averaging algorithm, the VU difference is about 2/3 of the peak dbFS difference.

Ultimately, for user acceptance, the audio properties of our new phone system need to be as good as our old system (vintage 1990). This includes the ability to deal gracefully with varying audio signal levels presented by foreign systems and the PSTN. If the new system is "sensitive" to such variations (which will happen, and are unavoidable), then it will not be accepted. It does not really matter if the true "fault" lies somewhere other than with the 3CX implementation. If the real world is going to continue to throw varying signal levels at the 3CX system, then the 3CX system needs to be able to compensate for these at least as well as "old" systems do.

thanks!
Joe

Where is an "end of messges" in schema which is described in my post? Why the "(2)" is "a digital signal, internal to 3CX"(in schema which is described in my post)?
thanks

 

[fjkeith]

...
Bottom line: audio levels at phone during normal conversations are acceptable, volume levels in recorded WAV files are way down. I will do a VU test on my WAV files later (at home tonight), or maybe someone else can analyze my attachment and post a result here?
...

Hi Joe,

path of audio is:
Source->(1)->PBX->provider->(2)->PBX->file

(1), (2) and file are checkpoints.

Please perform VU tests for all three points. is there any differences?

Thanks

In the diagram above (which I understood as referring to an external call coming into my 3CX system from an outside caller, the original Source is someone else's phone, point (1) is the analog connection to THEIR PBX, the "provider" is the "network", point (2) is the connection from the provider (nV in my case) to the 3CX PBX (this is a digital connection with IP packets flowing), and the file is the WAV file.

Since I have no way of measuring the original signal levels for Andy's test calls from New Jersey since I live in Georgia, I elected to run a more controlled test: I simply called my OWN voice mail box from the SIP phone on my desk (Polycom 600 with all audio settings at defaults). Thus, my setup goes:

DeskPhone->(4)->G711u->3CX_PBX->WAV_file(5)

I am not setup to measure the signal levels at point (4) (the analog signal strength internal to the phone prior to the analog-to-digital conversion in the phone itself). My reported results above are for the analyzed WAV file. For purposes of comparison, I also analyzed the properties of a representative pre-recorded 3CX prompt. The voicemail file produced by my informal test is much softer than the pre-recorded prompt.

Stepan, can you run this informal test on your in-house system at the 3CX office and post your WAV files to the forum? I'll be happy to download them and run them through my analysis SW. For the VM recording, please use a normal speaking volume that would not disturb an associate in an adjacent cubicle. Also, please note in your posting which SIP phone you are using, and whether or not any of the phone audio properties are changed from their factory defaults.

thanks!
Joe

 

[fjkeith]

Stepan,

Have you had a chance to compare the playback levels of typical VM messages vs. the system prompts provided with the 3CX system?

thanks!
Joe