asterisk users - Jan 2009 - Problems With Playback of Audio On SIP Only System

I have been installing Asterisk as a SIP only system (no Digium Hardware)
for demonstration purposes. SIP users can connect to menus and voicemail
fine but the audio quality is terrible. The stock voicemail problems are bad
but basically understandable - voice menus recorded through the
asterisk-gui-2.0 are difficult to even understand.

The phone I am testing with is a Polycom SountPoint IP 430 SIP. I have
configured the phone for ulaw to be it primary codec and set disallow all
and allow ulaw in the users.conf.

When that did not work I guessed that something was wrong with dahdi_dummy
but dahdi_test is showing results around 99.987%.

Here are the details of what software I have been using:
asterisk-1.4 (r168975)
dahdi-linux-complete 2.1.0 (r 5662)
asterisk-gui-2.0 (r4446)

The linux kernel is 2.6.24.6 built with 1000 Hz timer.

Thank you for your help, I am a stumped.

-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20090119/c762f362/attachment.htm

Brian Alexander wrote:
> I have been installing Asterisk as a SIP only system (no Digium 
> Hardware) for demonstration purposes. SIP users can connect to menus and 
> voicemail fine but the audio quality is terrible. The stock voicemail 
> problems are bad but basically understandable - voice menus recorded 
> through the asterisk-gui-2.0 are difficult to even understand.
> 
> The phone I am testing with is a Polycom SountPoint IP 430 SIP. I have 
> configured the phone for ulaw to be it primary codec and set disallow 
> all and allow ulaw in the users.conf.
> 
> When that did not work I guessed that something was wrong with 
> dahdi_dummy but dahdi_test is showing results around 99.987%.
> 
> Here are the details of what software I have been using:
> asterisk-1.4 (r168975)
> dahdi-linux-complete 2.1.0 (r 5662)
> asterisk-gui-2.0 (r4446)
> 
> The linux kernel is 2.6.24.6 built with 1000 Hz timer.
> 
> Thank you for your help, I am a stumped.
> 
> -Brian
If you are using gsm prompts and gcc version 4.2 or higher, then you may be 
experiencing the optimizer bug that gcc has with gsm audio. The workarounds for 
this are to use a different format for sounds or to set the DONT_OPTIMIZE flag 
in menuselect. If you want an optimized build and gsm formatted sounds, then you
could always attempt downgrading your gcc version to 4.1 or earlier.

Mark Michelson

Mark,

Thanks - that was the problem I was having. Is there somewhere I could have
looked to have discovered the problem on my own? I would never have guessed
that on my own and my searches had not found it either.

Thanks again,
-Brian


On Mon, Jan 19, 2009 at 7:00 PM, Mark Michelson <mmichelson at
digium.com>wrote:
> Brian Alexander wrote:
> > I have been installing Asterisk as a SIP only system (no Digium
> > Hardware) for demonstration purposes. SIP users can connect to menus
and
> > voicemail fine but the audio quality is terrible. The stock voicemail
> > problems are bad but basically understandable - voice menus recorded
> > through the asterisk-gui-2.0 are difficult to even understand.
> >
> > The phone I am testing with is a Polycom SountPoint IP 430 SIP. I have
> > configured the phone for ulaw to be it primary codec and set disallow
> > all and allow ulaw in the users.conf.
> >
> > When that did not work I guessed that something was wrong with
> > dahdi_dummy but dahdi_test is showing results around 99.987%.
> >
> > Here are the details of what software I have been using:
> > asterisk-1.4 (r168975)
> > dahdi-linux-complete 2.1.0 (r 5662)
> > asterisk-gui-2.0 (r4446)
> >
> > The linux kernel is 2.6.24.6 built with 1000 Hz timer.
> >
> > Thank you for your help, I am a stumped.
> >
> > -Brian
>
> If you are using gsm prompts and gcc version 4.2 or higher, then you may be
> experiencing the optimizer bug that gcc has with gsm audio. The workarounds
> for
> this are to use a different format for sounds or to set the DONT_OPTIMIZE
> flag
> in menuselect. If you want an optimized build and gsm formatted sounds,
> then you
> could always attempt downgrading your gcc version to 4.1 or earlier.
>
> Mark Michelson
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20090119/e51906d2/attachment.htm

Mark Michelson wrote:
> If you are using gsm prompts and gcc version 4.2 or higher, then you may be
> experiencing the optimizer bug that gcc has with gsm audio. The workarounds
for
> this are to use a different format for sounds or to set the DONT_OPTIMIZE
flag
> in menuselect. If you want an optimized build and gsm formatted sounds,
then you
> could always attempt downgrading your gcc version to 4.1 or earlier.
This is affecting users frequently enough that we probably need to
engineer some sort of configure-script test to check for this problem at
build time.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org

On Tuesday 20 January 2009 06:31:51 Kevin P. Fleming
wrote:
> Mark Michelson wrote:
> > If you are using gsm prompts and gcc version 4.2 or higher, then you
may
> > be experiencing the optimizer bug that gcc has with gsm audio. The
> > workarounds for this are to use a different format for sounds or to
set
> > the DONT_OPTIMIZE flag in menuselect. If you want an optimized build
and
> > gsm formatted sounds, then you could always attempt downgrading your
gcc
> > version to 4.1 or earlier.
>
> This is affecting users frequently enough that we probably need to
> engineer some sort of configure-script test to check for this problem at
> build time.
Actually, this problem should already be fixed.  It was a case of optimization
with assembly code.  Adding the noclobber option to the assembly should have
fixed this.

-- 
Tilghman