| Summary: | ASTERISK-01996: [request] Add channel-specific VM gain parameter | ||
| Reporter: | radamson (radamson) | Labels: | |
| Date Opened: | 2004-07-12 10:48:14 | Date Closed: | 2011-06-07 14:05:27 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | pstn->* calls will always record VM at much lower volume then local channels, and pstn loss is determinable. Retreiving VM via pstn adds additional loss making VM difficult to hear at best. Add a parameter like pstnVMgain=5 to specific pstn channels to compensate (somewhat) for the asterisk-to-pstn loss. ****** ADDITIONAL INFORMATION ****** Telephone->pstn(5db loss)->CO->pstn(5db loss)->asterisk This VM record path has 10db loss. When VM retreived via pstn, an additional 10db of loss is incurred (now -20db audio). Adding such a parameter would remove 10db of that loss (or whatever the user specified). Adding to Zap/1 (pstn interface) as an example, anytime VM-app is playing/recording to/from this channel, increase the gain by this static amount. (This VM level issue has been noted by multiple * users, and is supported by those users. The actual gain to be applied is highly dependent upon how far the * server is from the CO, as well as other factors.) Since VM is basically a half-duplex channel, echo should not be a factor, whereas adjusting zapata.conf gain settings will result in echo. | ||
| Comments: | By: frank (frank) 2004-07-17 09:29:08 I tested this with the telco T1 connection we have (thinking there should be little or no db loss. we are a stones throw from the CO). Calling into one of our SIP phones from the telco T1 produces no noticable loss and sounds fine. Calling into our VM from a SIP phone produces no volume loss. Now, Calling into our VM from the T1 telco and leaving message produces significant loss. The volume of the recorded message sounds the same regardless of listening/playback on a SIP phone or on a connection through the telco T1. Seems it is only a recording problem of voicemail messages that come through zap drivers. By: frank (frank) 2004-07-22 22:11:48 At the suggestion of John@Digium, confirmed we were running the latest code (7/19/04). Same results. Then changed the format to gsm in voicemail.conf. Confirmed gsm files were being left. Same results. Volume of messages coming in over TE405 from PSTN are very very soft and much much softer than messages left from a SIP phone. By: frank (frank) 2004-07-25 14:07:54 Does this really constitute a Feature Request? My testing has shown this to be behavior that makes the VM application unusable because the volume is so low the VM subscriber cannot hear the message at all. I recently spent an hour or more on the phone and on the test system with James@Digium support trying to determine what is causing this. He was stumped. My guess is that this is more than a Feature request and possibly a severe bug. OEJ, Am I way off base? By: radamson (radamson) 2004-07-25 14:47:10 When I opened this, I opened two bugs: 1)VM recorded at -10db via TDM & X100P cards (to me that IS a bug) when gains were at 0 db, and, 2) a feature request to set the gain by interface (this one). Twisted decided they were the same and closed the first one. I tried calling my VM from a cell phone (business) and could not hear; and to wait till I was back in the office to listen to it via a sip phone. When playing back the VM, I actually verified with a transmission test set the audio was now -20db from any remote site. (The further * is from the CO, the worst the problem.) Rich (radamson@routers.com) By: bfranks (bfranks) 2004-08-04 08:24:26 We have the same issue. Our setup is as follows: 5 Analog FXO Lines from Verizon Adtran Channel Bank --> T100P. We use all Sip Phones. Volume on all calls is fine, however users dialing into our IVR and leaving a message come across at a very low volume. SIP Phones can barely here there messages left for them in their inbox. If a user tries to call in to here there messages from home (using the PSTN) they can't really here it at all. Uping the volume (on phone & Zapata) settings has an adverse effect on call quality to PSTN (call is very loud). By: frank (frank) 2004-08-04 09:55:23 our initial testing (we have an pstn t1 connected to *) show that our ivr app using record() and then playback() show that only VM seems to be affected by the problem we see. record() and then playback() appears to have the correct volume. but recordings made to VM are very, very low. further testing done by raising rxgain up to 6 helped the VM low volume recordings. But it did not seem to make the record()/playback() tests any louder. it appeared that the record/playback volume was unchanged. almost as though there was some gain normilization already built into record(). ?? By: kb1_kanobe2 (kb1_kanobe2) 2004-08-06 05:02:59 There was a comment in the July 2004 thread on this topic about a fixed gain tweak or even level compressor tool being a more useful if implemented outside of voicemail as a generic applicatication - I would second that thought. I have a couple of Nortel Norstar systems which are networked using E&M trunks via Asterisk servers. The Norstar provides a site paging feature using the speakers in the sets. Paging can be peformed into remote sites using DISA access codes, however Nortel make careful note in the manual of 'low volume levels' being an issue when using such features remotely - thus people have to remember to almost SHOUT into their handset... If it were feasable to insert a call to app_gain or app_compressor in the portion of the dialplan used for bridging calls into the remote DISA feature set then Asterisk would be able to correct Nortels shortcoming in this area. Likely use could also be made of these applications (particularly a compressor) when connecting to other unconventional hardware, such as Radio/PSTN bridges. By: Mark Spencer (markster) 2004-08-06 10:20:23 Clearly the same mechanisms used by Record/Playback are used within voicemail. What format did you use with Record/Playback? Perhaps we should experiment with your using precisely the same format (and only that format) with your voicemail as well. By: frank (frank) 2004-08-06 10:37:16 only gsm everywhere. under the voicemail directory, there are only gsm files. no wav files anywhere. all voicemails and greetings use gsm. with record, we were using :gsm so, i think we already have gotten that far. By: twisted (twisted) 2004-08-24 13:25:33 Status request? /* Housekeeping */ By: patrickdk (patrickdk) 2004-08-24 17:43:40 Hmm, a just a though, dunno when I might have time to try it out. Instead of playing with Gain settings, that change per channge, and can be alittle difficult to setup and get correct. How about using a normalization on recordered or played back messages. That way you wouldn't have to play with the gain, since it would autoadjust based on the either peak/average sound level it detects. By: radamson (radamson) 2004-08-27 15:34:28 The notes attached to this bug (2023) primarily apply to bug 2022, but since 2022 was closed (earlier, and then reopened by me), the notes are kind of intermingled. Talked to James in support today (8-27-04) and sent him an email showing how to recreate and measure the problem. This bug (feature request) should be oriented towards adding a per-channel-parameter to adjust gain based on the pstn loss "from" the central office. Eg, the further * is away from an analog central office, the lower the volume for VM messages. Others have suggested this same parameter is needed for other * services as well. Bug 2022 should be used to record notes relative to the ~10db of loss specifically measured when using VM. By: Mark Spencer (markster) 2004-08-28 13:44:19 You can already adjust the gain on a per-channel basis with zap, what am I missing? By: bfranks (bfranks) 2004-08-28 15:31:14 Mark, In our setup with Polycom iP500 SIP phones, phone calls to the PSTN using the ZAP channels are at the correct volume. However, people that leave messages in a mailbox, which are later retrieved using the same sip phones sound like they are recorded at an extremely low volume. It is very very hard to hear the messages. Additionally, when a user on our phone system calls in from home to check their voicemail using the same phone lines that people leave messages on, it is almost unusable becuase the messages are recorded at such a low voulem. They system prompts however sound fine (they are loud enough) By: Mark Spencer (markster) 2004-08-28 15:39:44 There is no path in which leaving voicemail via an FXO interface (not in wav linear) and then checking via a SIP phone can possibly have a different level than the FXO interface talking directly to the SIP phone. It's simply *not* possible. There is no path for adjusting the gain beyond that of the zap device. SIP does not support gain, none of the formats support the gain. By: bfranks (bfranks) 2004-08-28 15:56:56 Maybe people are just talking to quiet then. Maybe our users are telling people to speak louder if they can't hear a person? - Brent By: radamson (radamson) 2004-08-28 17:41:12 I hear what you are saying Mark, and that is exactly "why" I went through all the trouble to document ~10db of loss with "voicemail and x100p/tdm" interfaces using quality transmission test equipment. The loss is an absolute fact without a single shadow of a doubt, and can be recreated time after time. Since I'm not a programmer I can't tell what the problem is, but with 20+ years of professional telephony transmission engineering experience, I can assure you there "is" a 10db loss. There is only a ~1db loss when doing the same test using an ata-186 and the same test equipment. The tests confirm what the ear is hearing. So, there is a major difference for a fact. Adjusting rxgain/txgain is not a solution as that negatively impacts the echo problem with these same digium cards, and the audio level for normal pstn conversations, callerid, and dtmf. The VM transmission loss is not seen via Mediatrix gateway, sip calls of any sort, iax2 calls, or anything else that I can find. Only with the x100p and tdm cards. (Others might know of some other path, I don't.) We all know fairly well there are still issues with those cards and echo, etc, that "appear" to have some dependency on interrupt latency and/or pci controllers (motherboards) that have not yet been addressed. Work arounds have significantly reduced the impact, but the issues are still there. Is there a possibility the two are related? (eg, could there be motherboard specific issues that drop the most significant bit, word alignment, or some other weird thing, that impacts these things? I'd have to guess there is since callerid using x100p/tdm cards is not as reliable as a cheap analog phone, swapping motherboards is known now to significantly impact tdm echo problems, VM levels are low, etc. If James _can't_ recreate the VM problem in the lab, then I think that proves there are some unknown x100p/tdm motherboard/system dependencies impacting these things. If that turns out to be the case, I can certainly make my * system (2.4ghz) available to recreate the problem, as can many others.) By: Mark Spencer (markster) 2004-08-28 17:44:25 One would certainly imagine something like that. Like I said, there is simply no path for the gain to be adjusted along that line. You should be able to measure it. By: Mark Spencer (markster) 2004-08-28 17:48:41 I do not contest that there could be a gain or a loss from the telco. I do contest that there can be a gain which somehow only affects leaving a voicemail. By: radamson (radamson) 2004-08-28 18:49:22 To ensure no misunderstanding here, this is not a telco/pstn loss we're talking about. This is a 0dm 1004hz tone injected at the x100p/tdm rj11 jack that gets recorded via VM at a 10db loss. I'm not sure what you mean by "you should be able to measure it" as that's exactly what I've done in 2022 & 2023, and we're now waiting for problem recreation and a fix. Since Frank mentioned the same problem with a T1, it sounds like the issue is within the zap software, and/or possibly how it relates to the motherboard/system. Without more specific direction from someone, I've gone as far as I know how to document the problem. By: Brian West (bkw918) 2004-08-29 00:55:33 By chance what format are you saving your voicemail in? Paste the format= line from voicemail.conf please. bkw By: frank (frank) 2004-08-29 07:55:34 bkw, when we tested this using a TE405 card (noted in bugnote), we were only using gsm. format=gsm. in fact, we deleted anything that was not *.gsm in the spool directory and rerecorded all of our greetings. and as i have documented, i makes not difference on the problem. as a pretty weak workaround for now, we had to add rxgain=10.0 to the zapata telco sections. but then we had to turn down the volume on all the phones. it is still a bit soft on the VM now but usable, if only barely. however, any fax calls that come in now and are switched out to another channel on a different T1 port end up at a much higher volume. we are montoring our fax failure rate to see if this high volume is having any adverse impact on echo/noise on recvd faxes. By: Tony Mountifield (softins) 2004-08-29 12:35:02 Interesting problem! Having looked at the code, I'd like to suggest a couple of things to check/try that haven't already been mentioned: 1. Try recording VM from SIP and Zap with both zero and non-zero values for maxsilence in voicemail.conf. If maxsilence is >0, it sets the read format on the channel to SLINEAR. If maxsilence is 0, it doesn't. This may have an effect. 2. The Telco PSTN channels will be ULAW encoded. What codec(s) have been tried for SIP? By: radamson (radamson) 2004-08-29 12:43:40 I'm using: [general] format=gsm but have also tested levels against wav and wav49. Same issue. In my case, the VM problem happens with x100p and tdm cards, and Frank's with a T1 card. Probably safe to suggest all 'zaptel' are impacted. I'll test the maxsilence suggestion later today and report back. radamson@routers.com By: radamson (radamson) 2004-08-29 13:44:53 Completed tests with maxsilence=0 and 10; the two calls from an outside pstn line via tdm fxo were identical levels. (Actually did a stop now, and safe_asterisk start when changing maxsilence.) Did the same for sip to sip call (on the same wire) leaving vm, both calls were identical levels but very noticably higher audio levels for both sip calls. In other words, maxsilence had no impact on the level problem for zap or sip calls. VM gsm only. TDM04b (fxo) as no codec specification in zapata.conf. For the record, this test was on CVS-HEAD-08/28/04-23:53:24 CDT. radamson@routers.com 700-434-5395 By: Mark Spencer (markster) 2004-08-29 21:53:49 I've added app_test with the assistance of Russell Bryant to help diagnose these sorts of situations. I can definitely measure a surprising mismatch between FXS -> FXO and FXO -> FXS paths using this tool, but it certainly provides no explanation as to why on a T1 one would still have a problem. It would, however, be possible to use this on a T1 performing a round trip test. By: bfranks (bfranks) 2004-08-29 22:38:56 We have this problem on FXO interfaces. Our setup is * -> T100P -> Adtran TA 750 -> FXO Modules -> Verizon Analog POTS lines. If thats of any help. - Brent By: richard (richard) 2004-09-06 18:34:13 In light of Marks measurements just above, is there any chance the FXS-> FXO and FXO -> FXS level discrepancies can be addressed? This would seem to be more of a bug than a feature request, as this is currently classified. By: maasj (maasj) 2004-09-15 09:45:18 To add a data point I'm a relatively new Asterisk user (small office setup with ~10 users) and we're seeing this problem with low volume voicemails as well. The voicemails are practically useless when attached to email or checked via the PSTN. We're using a TDM400P card with FXO modules to interface with phone lines from the local telco. Any status update on this problem, or a workaround using 'sox' to bump up the volume of the voicemail file? By: radamson (radamson) 2004-09-25 09:48:18 Any status update on digium's ability to replicate/lab the problem? (See ASTERISK-1995 notes from Aug 27, 2004). Problem still exists as of Sep 25th. By: mlittle (mlittle) 2004-10-11 12:55:54 Anyone have an update to this problem/bug? I am experiencing the same problems. I have all my voicemails emailed to me in a wav format. I have to crank my speaks all the way up, but the voicemail is still extremely difficult to understand. Since I am leaving the voicemails, I know that they are a decent volume when I am recording them. Does anyone have any recommendations on what to modify to make the voicemails record louder? By: twisted (twisted) 2004-11-14 21:18:04.000-0600 This has been dormant for a month. It's time to give it a "shock". Any updates? --housekeeping By: bfranks (bfranks) 2004-11-14 21:22:33.000-0600 Still same problem here. I think ultimately what it comes down to is we just need a way to record at a higher volume if we want for voicemails. By: radamson (radamson) 2004-11-14 21:37:31.000-0600 Its been dormant since it was reported for all practical purposes. Lots of "me to" additions. Sure wish these TDM card problems would get some attention and resolution. I now have more invested in digium cards then if I would have purchased an external gateway in the first place. By: sprior (sprior) 2004-11-22 20:41:43.000-0600 Hate to be nothing more than a "me to", but I've got the same problem and it makes voicemail and my TDM22B unusable. I think it's a major problem that this bug has a status of "feedback" when not fixing it could very well result in my having no choice but to return the card for a refund and giving up on this platform which I have spent a lot of time getting up to speed on. All the cute features in the world are great, but I can't live without a usable voicemail. Like the others I have NO problems with volume problems with calls through the FXO interface when I'm talking with a phone attached to the FXS interface, but as soon as voicemail is left through that same interface the volume on the recording is too low to understand. The problem is in the recording, checking the VM through SIP, FXS attached phone, or emailed WAV file make no difference, they're all too low. Leaving a message from a phone attached to the FXS interface results in a perfectly fine recording volume. This bug really needs a status change and a higher level of activity. By: Brian West (bkw918) 2004-11-22 21:39:36.000-0600 Did you make sure your jacks are not wired backwards? By: sprior (sprior) 2004-11-22 21:46:37.000-0600 I plugged a phone line polarity tester into the same jack I plugged the TDM100P card into and confirmed that it was wired properly. Has this been a cause for the other folks who were reporting this problem? By: sprior (sprior) 2004-11-22 23:36:14.000-0600 One thing I noticed is that the voicemail function uses the ast_play_and_record(...) in app.c and that the record application in apps/app_record.c use similar but not common code. Unless I'm missing something (very possible), if the low volume problem exists in one of these functions it should happen in both (they both do eventually call ast_writestream in file.c). I haven't tried it yet - can anyone confirm (or deny) that the low volume problem not only exists with voicemail, but the record app as well? I don't see any special gain normalization code in the record app done as a post process that would account for the results being different. By: radamson (radamson) 2004-11-23 06:18:03.000-0600 Would someone _please_ change this bug status. It is _not_ waiting for feedback and it _is_ a real problem when using digium hardware (or zaptel at least). The bug has been around since July, specific steps documented to recreate the problem provided to Mark for "lab'ing it up" (see bug 2022 doc), and has gone nowhere. There is no more feedback that can be provided. At least one of us has gone through _all_ of the stock responses including: a) reverse tip/ring (old issue associated with the x100p, not the tdm04b), b) rx/tx gain settings, c) various different recording formats (gsm, wav, etc), d) try the latest cvs head, etc. If this can't be fixed or no one wants to take ownership, then lets say so and we'll remove the digium hardware from the system, let the world know this stuff is not acceptable for production use, and move on. (I'm a non-programmer and don't have any other resolution choices, period. Obviously, becoming very frustrated with this bug.) If someone with the skills to ID the bug needs access to a system with the tdm04b card installed (and with the problem), I can arrange that in a very short period of time, and can work with that person to test fix attempts, etc. By: gjunker (gjunker) 2004-11-27 23:08:01.000-0600 This is not limited to Zap channels. I have a test setup using a SPA3K into Asterisk via SIP. I have received VMs on that channel, and have left test VMs, and the GSM prompt files are just fine. I can't listen to the GSM VMs, but the different between the WAV and WAV49 is significant (I can hear the WAVs relatively fine, but even if I crank up everything on the PC, the WAV49 file is just a whisper). This is not via phone, of any sort. This is copying the voice capture files from the server to my PC running XP, and listening to them in WMP. By: khb (khb) 2004-11-28 01:09:45.000-0600 Well, all I can say at this point is "ME TOO". The new site is using 2 TDM400 cards w/ FXO ports. By: Brian West (bkw918) 2004-11-28 01:18:49.000-0600 FYI uppercase WAV and lower case "wav" are diffrent. wav49 and WAV are the same. By: Brian West (bkw918) 2004-11-28 01:19:29.000-0600 Everyone post your motherboard and processer info because this is 100% hardware related. It has to be. bkw edited on: 11-28-04 01:28 By: Brian West (bkw918) 2004-11-28 01:29:03.000-0600 has anyone tried "raw" as the format for voicemail? By: gjunker (gjunker) 2004-11-28 02:33:13.000-0600 bkw, it's nothing to do with hardware since my experience was completely software-based (SIP softphone, SIP setup, email attachments). Yes, I know (more than you can possibly imagine) the difference between the PCM and MS-GSM WAV formats. And the .wav (case important) files *are* PCM (uncompressed...in other words, raw) audio data. I appreciate the effort there, but throwing stuff against the wall and hoping it sticks hardly qualifies as "scientific method". By: radamson (radamson) 2004-11-28 08:19:37.000-0600 I believe this bug ASTERISK-1996 is now incorporating two "different" problems. The original bug involves recording of voicemail messages via digium cards (x100p, tdm04b, T1 cards) at very low volumes regardless of the format in which the voicemails are recorded (been there and tried various formats). Now, folks are adding bug notes relating to gsm/wav/wav49 levels with sip-only (non-digium cards), which is very likely a different issue from the original bug. The focus of ASTERISK-1996 is pstn calls arriving via digium cards are VM recorded at such low volumes that it is almost impossible to listen to them. (See all notes from 2022 and 2023.) We've all been through the rx/tx gains, dedicated interrupts, formats, etc, etc, many times. Professional transmission measurements accurately measured a recorded 1khz tone at -20db via VM, but audio levels are very good when the call is answered (not VM) from a sip phone (7960) as one example. If the recorded VM is listened to from a sip phone, the volume is very very low. The issue "seems to be"... when a voicemail is left by a pstn inbound call using digium hardware, the "recorded" volume is always extremely low. Its consistent and can be replicated 100% of the time with all cvs-heads since July 2004 (including current). If a VM is left by any other source (eg, sip, iax2, etc), volume is always excellent, period. Hardware: 2.2 ghz celery, 380m ram, RHv9, tdm04b (rev E/F), single call being processed by *, 100meg full duplex, no other pci cards in system, cpu running close to 0% most of the time, any sip phone (7960, IP500, Snom200, xlite, etc), zttest is consistent at 99.987793%, four pstn lines from two central offices all the same. System uses only registered IP and can be made available to anyone that has the skills to ID the problem. Full RHv9 installation. (Note: x100p, tdm04b, T1 cards all exhibit the exact same problem!) Contact: radamson@routers.com By: gjunker (gjunker) 2004-11-28 11:03:23.000-0600 "If a VM is left by any other source (eg, sip, iax2, etc), volume is always excellent, period." That's the point...this is not true, which indicates that no matter how the VM comes in, it is being recorded incorrectly. By: radamson (radamson) 2004-11-28 11:50:50.000-0600 I honestly believe we are combining two problems into this bug record. Bug 2023 (and 2022) original Test Points: #1. 3M 965 Test Set -> ATA186(sip) -> asterisk #2. 3M 965 Test Set on pstn line -> tdm04b -> asterisk #3. IAX2 link -> asterisk In point #1 test set sends 1khz 0db tone to VM. Receives VM msg at -1db In point #2 test set sends same, retreive via sip at -20db (10db is pstn) In point #2 test set sends same, retrieve via pstn at -30db (20db is pstn) In point #3 test set sends same across iax2 link, retreive at ~-.5db All VM recorded in format=gsm. Mark asked me to repeat the test using wav format and got the same results. End result: all VM calls recorded via tdm card is consistently -10db (exluding pstn losses), while all sip VM calls were consistently 0db loss (excluding -1.0db in ata186). Also, at leasst some others are having the same issue with tdm04b and T1 cards (see Mark's note from 8/29). Did not have the same problem with Mediatrix 1204 sip gateway on same pstn lines with exact same asterisk system. What you describe sounds like another problem/issue, but as a non-programmer I guess they could be related somehow. By: gjunker (gjunker) 2004-11-28 14:08:40.000-0600 Rich Is there a dev list thread in which we could continue this? By: Olle Johansson (oej) 2004-12-13 01:47:14.000-0600 Any updates, any code? This bug is a sleeping beauty. --Housekeeping By: vester (vester) 2004-12-16 17:22:37.000-0600 Have the same bug with VM. However, also noticed that an FXO call answered on an extension (in this case FXS) when doing a supervised transfer to a SIP extension will result in low audio levels also! Level degredation seems to track that found in VM. edited on: 12-16-04 17:42 By: alric (alric) 2005-01-04 18:49:50.000-0600 Any more updates or activity? --Housekeeping By: radamson (radamson) 2005-01-04 19:13:05.000-0600 For future housekeeping, please ask Mark as to the status of this. See his comments from 8/29/04. I don't know of anything more that I (or anyone) can possibly provide. The problem is well documented and digium was provided a detailed "how to" for recreating the problem at Mark's request. We are all waiting for someone with programming skills to ID the issue and provide some sort of resolution. If someone with those skills needs access to a system with the problem, please contact me (radamson@routers.com). By: twisted (twisted) 2005-01-28 19:47:59.000-0600 Not sure where digium is on this, but I'm just resurfacing it so that it gets noticed again. By: jzeeff (jzeeff) 2005-02-07 15:54:00.000-0600 Can someone up the priority on this and change it from a feature request? This is a serious bug that makes VM hard to use. Voicemail needs to be unity gain - level out should be equal to level in. Thought: could it be that the RX gain in zapata.conf isn't getting applied to the stored file? By: Mark Spencer (markster) 2005-02-07 16:15:37.000-0600 There is no gain adjustment within voicemail, if you had actually read the comments above it. It's a feature request because the desire is to *add* a gain to voicemail that is not there for a normal call. By: sprior (sprior) 2005-02-07 16:52:33.000-0600 Markster, with all due respect that's not entirely accurate. The original intention of this big is to fix a severe bug with using voicemail which does not seem to affect normal conversations over that zap channel. The proposed solution is to add a channel specific gain parameter, but I bet a lot of us would be completely satisfied if we could actually hear voicemails left on asterisk. For me at least this one problem has prevented me from progressing in the deployment of my asterisk system. By: jzeeff (jzeeff) 2005-02-07 17:37:20.000-0600 I agree, I don't need a gain adjustment, I just need the system to play back voicemails at the same volume they came in at. Anything else seems like a bug to me. Part of the problem here is that too many things have been discussed and it seems to be getting in the way of fixing the non unity gain bug. edited on: 02-07-05 17:38 By: radamson (radamson) 2005-02-07 18:00:28.000-0600 This was originally opened as bug 2022 but some decide 2022 and 2023 were duplicates. As far as I'm concerned, this is still a BUG and can be easily recreated, measured and qantified in no uncertain terms. I don't know why (as a non-programmer) VM would be recorded with an additional 10db of loss (absolutely proven without a shadow of a doubt), but it is, and that is a problem (I'll choose to call it a bug, others can call it whatever they feel comfortable with). I've volunteered an Internet accessible system with four pstn lines to aid in diagnosing the bug, but no one seems to want to chase after this one. The scope of the problem has not changed at all in seven months and seems to only exist when using Digium pstn cards. Exactly the same problem as was originally documented; even with current cvs head. 2023 was only opened as a suggestion/enhancement to compensate for telco loss when an asterisk box is located a fair distance from the telco, but 2023 was opened knowing full well that 2022 described the original 10db loss BUG. For those that truly understand telco engineering and plant loss, separating 2022 and 2023 makes all the sense in the world. By: Kevin P. Fleming (kpfleming) 2005-03-09 01:10:04.000-0600 Please produce your test recorded messages as before, except store them in sln (raw mode). Then take the files produced and use sox to determine their peak/average levels. This will allow us to conclusively determine whether the problem is occurring at recording time or playback time. By: Brian West (bkw918) 2005-03-17 21:46:56.000-0600 Please someone on this bug TRY what kevin says ... I think plenty of people are having this issue and could collect the files in sln mode and test it. /b By: radamson (radamson) 2005-03-19 12:08:07.000-0600 See http://www.routers.com/asteriskprob/asterisk-config.htm for a detailed description and the availability of a system to replicate whatever testing anyone wants to complete. Rich ( radamson@routers.com ) By: jzeeff (jzeeff) 2005-03-19 18:06:24.000-0600 radamson9 has done a great job of documenting the problem. Now we just need someone to point out where the bug is in the code. The response to this bug has been terrible. In response to that, I say that for now, if you want to use asterisk VM, don't use Digicom cards. That's right, bugs in asterisk and/or the cards cause VM to not work right. Use external SIP adapters instead - Sipura 3000, etc. On another subject, what's wrong with the echo cancellation such that one can't set gains to cancel out the PSTN losses? Adjusting the system for unity gain seems logical to me. By: radamson (radamson) 2005-03-19 18:36:19.000-0600 Reference to jzeeff's comment on unity gain; its not possible without significantly impacting echo. In the case noted, rxgain and txgain would need to be set to 5.6db, which cases echo and an unusable tdm-fxo-pstn session. Let's keep the bug comments oriented around the 10db loss associated with the x100p & tdm04b cards and voicemail, and its one year anniversary. By: trevarthan (trevarthan) 2005-03-22 14:42:00.000-0600 I'm getting this same issue on my X100P at home. The machine exhibited this behavior under FreeBSD 5.3, and still exhibits this behavior now that I've changed hard disks and operating systems to Gentoo Linux and a 2.6.11 kernel. I see two problems with this bug listing: 1.) For some reason it's still listed as just a feature request. As a programmer, I know that the chance of getting someone to spend programming time on this bug is extremely LOW unless we can bump it up to a CRITICAL BUG. Does anyone disagree? 2.) Judging from the previous comments, the only people capable of quickly addressing this bug are blowing it off as an "impossibility" or as some weird hardware issue. I'm guessing this is because they can't reproduce it locally. Fine. Fair enough. However, I experience this problem, as do many others, so I think we can all agree that it is a real problem, regardless of the theoretical improbability. I propose we focus on either troubleshooting the problem, working around it, or both. Now, judging from the previous comments, it seems that we have general losses when going from PSTN to Zap channels, but this VM issue seems to be either different, or a compounding of that problem and something else. Also, we've seen reports that the volume losses happen regardless of using Zap hardware or not, so my best first guess is that it's tied to or triggered by the VM code. Has anyone tried poking around in there yet? If not, I'm game. Asterisk isn't any good to me unless the VMs are understandable. Tell me where to look and I'll do my best. At worst, we should be able to implement some sort of amplification code to work around the problem and normalize the voicemail files AFTER they've been written to disk, right? Or maybe a script hook to do the same? By: jzeeff (jzeeff) 2005-03-24 08:19:09.000-0600 One could hack in a call to sox to adjust the gain, but this is very much the wrong fix. Someone needs to use a debugger and get a list of all the routines that are called and then add some debugging code to figure out what the volume is at various points. This take time and concentration and preferably an in-depth knowledge of the code. In looking at the VM code, I don't see anything that would effect gain (ie, I suspect the zaptel code on the recording side). Perhaps this issue needs a bounty on it to get it fixed? By: trevarthan (trevarthan) 2005-03-24 08:35:16.000-0600 Well, I just changed my recording format from wav49 to just wav, and the volume is now consistently noticably louder. So I'm thinking it has something to do with the actual encoding algorithm. Of course, I too can hear the decibel drop from the phone line across the X100p, so I think it's a combination of the two issues. But at least if we add a gain or normalization per encoding algorithm then we can workaround the problem until it gets properly fixed. After all, if this bug has been around for a year, I doubt anyone has plans of fixing it properly right now. And it still needs a higher priority! By: dbrodbeck (dbrodbeck) 2005-03-24 11:44:42.000-0600 At this point I'd settle for the hacked-in normalization fix, since it looks like the only fix we're likely to get -- especially with this still listed as a "feature request". I'm about to deploy an Asterisk voice mail system and I know my users are going to complain. I'd like to be able to give them some reassurance that it'll be fixed soon. A normalization option in voicemail would be a good idea in general -- even if this specific bug were fixed properly, normalization would still help with the problem of people talking too quietly when recording messages, which always crops up. By: dbrodbeck (dbrodbeck) 2005-03-24 12:23:35.000-0600 I think the people who are saying there's more than one issue being conflated here are probably right. - There's radamson9's well-documented -10 dB issue. He's done the work to verify this, so it clearly exists. - There's also an encoder-based issue. I copied the wav49 and wav versions of a recording to my desktop and played them both. The wav49 copy is noticably quieter. (I would have checked GSM, too, but I don't have a program on my desktop that plays it.) Other people have also noted that switching to "wav" helps. Perhaps these should be refiled as seperate bugs, if we can keep them from being marked simply as duplicates of this one. By: Kevin P. Fleming (kpfleming) 2005-03-25 18:25:48.000-0600 OK, I'm going to add my voice to the fray here... I'm on site, setting an Asterisk system (CVS STABLE) with a TDM400B card (3 FXO & 1 FXS). We have two Qwest analog lines plugged into the FXO cards, and while normal calls work just fine, voicemail left via the analog lines (played back via either PSTN or SIP) is very low volume (still usable, but very low volume). This site is _quite_ far from the CO, so I'm sure there is a significant amount of PSTN loss; however, that loss is also present during a live conversation, and doesn't seem to be causing an issue. I've tried recording in both pcm (G.711 ulaw) and sln, there is no difference. I can even call in to the same FXO interface and run Echo() and it seems fine. By: trevarthan (trevarthan) 2005-03-28 15:02:50.000-0600 OK, I've been doing some basic code reading in app_voicemail.c, app.c, and format_wav_gsm.c. I've also been researching the possibility of using the normalize program to provide volume adjustment for voicemail boxes. Please see below for my findings. Using the 'normalize' command, from here: http://www1.cs.columbia.edu/~cvaill/normalize/ Note that 'normalize' can't handle wav49 or GSM, so I am first converting from the specified formats to normal wav using sox, like so: sox msg0001.WAV -u msg0001-2.wav Then I'm running 'normalize' on each file in --no-adjust mode (doesn't modify the original file) to get an idea what the average volume is with each format: normalize -nv msg0001-2.wav Please see below for the outputs. Normal wav: level peak gain -24.1133dBFS -0.0008dBFS 12.1133dB msg0001.wav wav49: level peak gain -39.9539dBFS -12.3255dBFS 27.9539dB msg0001-2.wav GSM: level peak gain -39.0781dBFS -12.5336dBFS 27.0781dB msg0001-3.wav GSM from record(): level peak gain -35.6903dBFS -20.4924dBFS 23.6903dB asterisk-recording.wav 'wav49' is clearly the quietest, with 'GSM', then 'GSM from record()' following close behind. 'Normal WAV' may be too quiet for the hearing impaired, but I find it quite comfortable, so I'm making it my target volume. Both 'wav49' and 'GSM' are way too quiet. There is at least a 10dBFS difference between the normal wav format and the GSM format, and roughly a 15dBFS difference between normal wav and wav49! Note: The file used as the base for the 'Normal wav', 'wav49', and 'GSM' tests all came from the same voicemail recording. The 'GSM from record()' file was a different recording, so I think the discrepancy between 'GSM' and 'GSM from record()' is simply due to a different recording. Basically, my conclusion at this point, and after looking at the code, is that the wav49 and GSM formats within asterisk simply record at a lower base volume than the normal wav format. So, to me at least, it looks like some work needs to be done normalizing the format encoding algorithms themselves. The X100P 10db line drop issue is likely a separate issue entirely. I'm not an audio programmer. I can handle logic, but I've never written a codec. Is anyone else here capable of fixing the audio discrepancy *BUG* between the various recording formats? And can we please promote this to an actual bug instead of a feature request? I'm not opposed to opening a new bug. By: Kevin P. Fleming (kpfleming) 2005-03-28 15:28:49.000-0600 Would you please re-run that test as well, with voicemail configured to record in ulaw, alaw and raw (sln) modes in addition to the others you tested? sox supports all of these, so you should be able to get volume level readings from each format. By: trevarthan (trevarthan) 2005-03-28 17:53:37.000-0600 Can you give me the exact arguments to sox for playing these formats? I'm not having much luck with it. For U-Law and A-Law this makes some understandable but horrible sounding output: cp msg0003.alaw msg0003-3.raw artsdsp play -r 8000 -u -b -c 1 msg0003-3.raw What am I doing wrong? By: Kevin P. Fleming (kpfleming) 2005-03-28 20:05:02.000-0600 On my system, sox understands '.ul' and '.al' to be the standard extensions for these formats, and it needs no additional arguments. By: trevarthan (trevarthan) 2005-03-29 07:11:16.000-0600 OK. I converted the sln format using this: sox -r 8000 -s -w msg0003-4.raw -u msg0003-4.wav And A-Law and U-Law using this: sox msg0003-3.al -u msg0003-3.wav sox msg0003-2.ul -u msg0003-2.wav I get similar "normalize" results with a-law, u-law, and sln formats: SLN: level peak gain -29.4319dBFS -7.2875dBFS 17.4319dB msg0003-4.wav A-Law: level peak gain -29.3310dBFS -7.2688dBFS 17.3310dB msg0003-3.wav U-Law: level peak gain -29.3762dBFS -7.4282dBFS 17.3762dB msg0003-2.wav And finally, normal wav (PCM): level peak gain -17.6266dBFS 0.0000dBFS 5.6266dB msg0003.wav As you can see, normal wav (PCM) is obviously louder. This fact, coupled with the fact that I ONLY see GAIN statements in format_wav.c and not the other format C files leads me to believe that wav49, sln, pcm, ulaw, etc... are the norm, and wav is louder by default because it was coded that way. I might be wrong though. I've only just started reading about the wav format and reading the formatting code in asterisk. By: jgoerzen2 (jgoerzen2) 2005-04-13 13:51:04 Here's a weird thing: I'm seeing the same problem, but my PSTN line enters Asterisk via a Sipura SPA-3000, not a Digium card! I have the SPA-3000 answering and then directing all calls into Asterisk. This setup is working fine for everything except voicemail. Most, about 2/3 or so, of messages left come across very quiet when the voicemail is played back. A regular conversation with these people, regardless of the phone used on my end, works just fine. By: trevarthan (trevarthan) 2005-04-13 14:40:16 Well, that's what I was trying to say with my codec average amplitude tests. I think it's a problem with the codecs, not with the cards. Sure, there's a drop when doing the analog to digital conversion from a digium or other line card into asterisk itself, but I think that is a separate issue. I think the major issue we're seeing here (the issue that involves normal WAV being consistently louder than WAV49 for voicemail recordings) is that the codecs themselves don't have any gain/volume/amplitude adjustments. The normal WAV codec seems to be the exception to this. It has GAIN statements, and therefore it's louder. But the other codecs don't have gain statements. Still, this is all just my theory. I could be wrong. I've looked at the code, and I'm basing my findings on the code, but I didn't write it, and I'm not an audio programmer, so there's a chance I have no idea what I'm talking about. Still, so far, the numbers seem to support my theory. WAV is louder. What's a good solution? Well, I considered writing some code that would run the `normalize` command on any voicemail files AFTER they had already been created, but this would be a massive ugly hack for four reasons: 1.) The `normalize` command doesn't ship with asterisk. 2.) The `normalize` command only operates on uncompressed WAV files. wav49, gsm, etc... would all have to be converted to WAV, normalized, then converted BACK to the original format using `sox`. This is MASSIVELY inefficient and ugly. 3.) It wouldn't solve the underlying problems: 3a.) There is no way to control the volume of an asterisk channel. 3b.) The codecs themselves aren't normalized. The WAV codec produces louder audio than the wav49 codec. 4.) It still wouldn't allow a voicemail user to adjust the playback volume on the fly. So, IMO (if my previous assumptions about the codecs being at the root of the problem are correct) the only real solution is to do both of the following: 1.) Normalize the audio codecs so that they always produce the same average volume. Or at least rip out or adjust the GAIN statements in the WAV codec so it produces the same volume as the other codecs. 2.) Implement amplitude/gaim/volume control inside the asterisk channels, so volume can be adjusted on the fly in real time. But again, I'm no audio programmer, so not only do I not know if the above is accurate, I'm not capable of implementing it without spending a TON of time on it. Perhaps we need the following: 1.) File this as something other than a feature request. 2.) Create a bounty to compensate/motivate anyone who might be capable of doing the work. By: Brian West (bkw918) 2005-04-13 15:32:26 Its very simple to raise the volume on playback if you have it in sln. We currently do this in app_confcall (internal appliaction) You can see us demo this every week at the dev meetings. /b By: Michael Jerris (mikej) 2005-04-13 22:40:52 just to be clear, you are talking about formats (wAV, wav49), not codecs (gsm, ilbc, ulaw) as the root of the problem, correct? By: trevarthan (trevarthan) 2005-04-14 08:55:16 Yes: formats, not codecs. Sorry for the confusion. By: Michael Jerris (mikej) 2005-05-23 23:47:58 Ok, somone put up a bounty for this or get a patch on here or there is really no point it keeping this open. Adding the code to raise the record volume on the other couple formats should be easy enough. Are we also seeing another issue here than the difference between the different formats still? By: Michael Jerris (mikej) 2005-05-30 10:24:40 Ok, it seems no one is interested enough in this to fund the work. If anyone wants this to get resolved, please create a bounty on the wiki or contact an asterisk consultant to perform the work. This may be re-opened when there is a patch to review. By: Digium Subversion (svnbot) 2008-01-15 15:48:17.000-0600 Repository: asterisk Revision: 6595 U trunk/apps/app_voicemail.c ------------------------------------------------------------------------ r6595 | kpfleming | 2008-01-15 15:48:16 -0600 (Tue, 15 Jan 2008) | 2 lines allow channel receive gain to be adjusted while recording messages/greetings in voicemail (workaround for issue ASTERISK-1996 from the ancient past) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6595 | ||