Poor Sound Quality With Asterisk Background() and Playback()

Excellent, good plan.

I have emailed them over to you.  I will await your findings.

Thanks for your help.

I'll give them a test when i get into work in the morning (about 12 hours time).

Awesome, thanks in advance for your help.

I have tested the files and they sound fine on my system.

Did you manually install asterisk or are you using a distribution like trixbox or asterisknow?

If you manually installed it have you also installed zaptel?

Wow, interesting find.  Ok so we can rule out any issues with the recording studio.

This is a stock install of Asterisk that I built from source, no trixbox etc.

Yes zaptel is built and installed as we using ztdummy.  There is no digium card or the like in the system.

Thanks again for your assistance with this.

Is there a way that I can listen to how it sounds on your system?

Sorry for the delay replying. My email provider is having network issues at the moment causing me difficulty in getting to my email.

Sure not a problem.  I have emailed you the phone number.

Thanks for your continued assistance.

I tried phoning the number in 3 ways.

1) VoIP to the office and then out their PRI/E1 line and making an international call.
The sound quality was fine and was identical to playing the sound back on our pbx across the voip line.

2) Called from home via desk voip phone and then out my analogue phone line.
It again sounded fine but part of the word 'transport' was silent but I believe this is due to the echo training I have configured.

3) Just to test the previous theory I called using a analogue phone at home and this sounded fine aswell.


Maybe the quality is not quite as good but that would be impossible for me to tell since international calls do have lower quality anyway. It is certenly acceptible though.



I do have a couple of suggestions though.

1) Add a 'Wait(1)' between answering the call and starting to playback the message. This gives a little bit of time for the voice circuit to be established and stops the dialer hearing the ringing done directly followed by the audio. It just makes it easier on the ear.

2) How does the volume level of the message compare to when you are speaking to someone?
You might want to reduce the volume of the recording if it is louder.


I am probably testing at a very quiet time for you. It may be there are CPU spikes on the box occuring at peak times causing the playback problems. If you experience the problem more at certain times then let me know.

Are you sure it is just the playback routines that are causing poor sound and not normal voice aswell?
If it is affecting normal voice then it could be jitter or packet loss over the internet.

I tried the alternative number that you have and that did sound very poor but the previous one still sounds fine.

Do both numbers come in over the same voip provider?

Thanks for your followup.

1) Currently there is a Background(silence/1) - shall I swap that out in favor of the Wait(1) ?

2) The volume sounds pretty close to the same.  Curious though, what would reducing the volume do?

With regard to when your testing date or time does not seem to matter it does the same no matter what time of day or server load.

Its actually Background where i notice the sound quality as thats whats used during IVR prompts, normal calls are fine i don't experience this issue when talking to someone live.

PS: I sent another phone number you can try and hear the sound issues.  Please let me know how it sounds to you.

Thanks again for your continued assistance with this.  

1) Background() probably wont do any good as it will immediatly go onto the next step and start playing the other background message instead.

2) Just to make sure the recording isnt any louder than a normal conversation. You dont want people turning down a volume and then not being able to hear a person when the call gets put though.

Hi

The recording volume seems to be okay, its pretty well at par with a regular conversation.

Where you able to try out the other number I emailed to you?  I would really like to get to the bottom of the sound issue - I am at a loss as to whats causing it.

Thanks again

Yes I did. I think you probably missed my earlier post as it was just a minute before yours :-

"I tried the alternative number that you have and that did sound very poor but the previous one still sounds fine.

Do both numbers come in over the same voip provider?"

Yes, both sounds from exact same voip provider and on the same server from the voip provider.

Strange indeed......

Sorry your right, I did miss that previous post.  Sorry about that haha!

Sorry I am out of ideas as to what could cause it. Possibly something to do with the timing source. I think the background function uses it but I cannot see anything specifically saying it.

What version of asterisk and zaptel are you running?

Can you try out the meetme conference system. If it is a timing problem then that should be affected aswell.

Hello

I haveasterisk 1.2.24 and zaptel 1.2.21 installed, MeetMe seems to work with out issue.  I think the problem is related to how Asterisk is reading these files, almost like its trying to trans code it or something?  MeetMe seems to be fine so does paging.

This sure is frustrating i would love to find out why this this is happening - I cant see any reason that this should be happening.....  Thanks again for your continued help I hope we can get to the bottom of this.....

Can you email me the audio file you had playing in the background in the 2nd number you gave me?
I'll convert it to a g711 format gsm file to see if that makes any difference.

Ok its been sent.

Thanks alot for your help.

What was the one playing in the background on the 2nd number you sent me?
I'll concentrate on that one as the others seemed to work fine for me as you were using the playback command.

Do you mean which sound file of the ones i sent you were playing on the second number?

If so all of them, they are played in sequence.

Did I understand your question properly?

Thanks

Just mailed you back some converted files. In order to use them you will need to move the .wav files somewhere else and then put either the .sln or the .gsm files into the directory where you had the wav files.

.sln is asterisks native format. It is practically the same format as the wav file.
.gsm is a gsm compressed file. It uses higher compression.

Give them both a go and see if the audio quality is any better with either of them. If they are both better then the .sln files would be the best to use.

Very interesting - we are onto something here!!!

While you were converting etc, I had the recording studio send me the files encoded as ULAW (.ulaw) - so I have all the files in ULAW format.  I then went into my iax.conf and changed the contexts from:

[context]
blah
blah
blah
disallow=all
allow=gsm
allow=ulaw

to
[context]
blah
blah
blah
disallow=all
allow=ulaw

Notice the removal of the "allow=gsm".  As soon as I did that the files stop doing that terrible jitter sound we heard when calling the number.   So it seem the quality of the call is much better with the files as ULAW, and allow=gsm removed.  Does this make any sense to you?

Also, I tried the files you sent - they too sound much better now with the allow=gsm line removed.  Does asterisk not natively try to play the file with codec that the channel is using?

If you call the second number again can you verity the sound is better for you as well?

I was not aware of the native asterisk format.  Can you please let me know how you converted these files?  I think you likely used sox, can you show me the commands you used if that is infact what you used?

I think its probably a good idea to have these sounds in all formats - what is you opinion on this?

So looks like we are finally onto the possible culprit of this thanks for your help, look forward to your response.

I would not have expected the 'allow=gsm' to have caused the problem. However having that line first would have meant that any calls would be using that codec in preference which is not really a good idea as it is fairly low quality.

I tried the number and the quality is much better but there is something strange going on. The first thing I hear is "ing" and then the "thanks for calling..." and then the "first..." recording. Between all these recordings I hear a very brief burst of noise.

Asterisk will convert the audio to the required format on the fly. It is therefore a good idea to have the audio recorded in different formats as asterisk will pick the one which best matches the codec that is being used.
Use the .gsm files for gsm compression and for ulaw there is no format so best to use wav or sln.
ulaw is basically wav but the resolution is converted from 16 down to 8 bits using a logarithmic scale so doesnt take much cpu.

This URL gives the commands for converting the files using sox
http://www.voip-info.org/tiki-index.php?page=Convert+WAV+audio+files+for+use+in+Asterisk

Hi Thanks again for your post.

Yes I hear the burst of noise between the recordings as well - I am having the recording studio check on this.

They sent me these ULAW encoded files as a .wav, but when I put them in Asterisk as a .wav it will not play them.  It sais could not find a file in any format on the CLI.  Yet if I rename them to .ulaw they play.

Do you know why this is happening?

Thanks again!

WAV is really just a container and can support multiple formats within it. Although the data inside is ULAW encoded Asterisk itself only supports WAV files containing pcm data. Thats probably why you are hearing the noise as it is playing the wav header information as if it is part of the ulaw audio.

That is really strange.....

Those original recordings that you listened to were PCM WAV files and they sounded really bad.  Those were the ones that sounded jittery.

About that noise we here now.....you may be right about it playing the headers.  Hrm.... not sure what to do.... guess we cant record in ULAW.

I am going to ask the recording studio to redo the sound files as just PCM WAV files and to lower the volume on the recordings a bit.

Perhaps with that and the removal of the allow=gsm line it will solve the problem.....

Even still though, why the removal of allow=gsm makes any changes puzzles me, I did notice that it would have given gsm priority as it was the first allow statement, but since the call is ULAW wouldn't it have skipped that?  Or do you think Asterisk was trans coding the channel so that Playback was indeed playing in GSM even though the format was ULAW?

thanks again

It depends on the direction of the call and the codecs supported by the provovider. For calls received by asterisk the codec being used will be the first one the provider prefers which is supported by asterisk. This should be ulaw.
For outgoing calls if the provider supported gsm then the could would have been in gsm format.

Did the .sln file work ok?
If it did then I would just use thats. Its basically pcm but without the .wav headers.

Thanks again for your follow up.

I am going to wait to get the new recordings from the recording studio as the current ones are way too loud.

Once they send the new WAV files I will try those.  If still have problem I will convert to .sln as you suggested.

Will Asterisk play a file with that extension?  Or do I need to name it back to .wav?

Also, the removal of the wav headers, will that make a difference to Asterisk?

Thanks again for your help with this, I fell like we are onto a solution here :)

My apologies for getting back to so slowly.

Looks like we have nailed the problem, I had the recording studio re-do the sound files with a lower volume and just wav pcm format as you mentioned previously.  Now if you call the second number the sound quality is excellent, a night and day improvement over what was there before. :) :)

About that "glitch" noise we heard previously, yes that was Asterisk trying to play the ULAW headers you were infact correct on this.

I cant thank-you enough for your time and efforts on this, I really appreciate it and am glad there is now a working solution.

Cheers!