asterisk users - Jan 2006 - distorted native music on hold

Louis-David and list,

We were having the exact same issue using mpg123: distorted sound, clicks, 
etc.

First, we are using Gentoo, and didn't realise the ztdummy.ko module
wasn't
loaded by default. This is required for the timing.

mpg123 still refused to work correctly (sounds like 2-bit audio -- yuck!), but 
the following script did:

---

#!/bin/bash
kill `pidof -x -o %PPID asterixmohplay sox`
while [ -n "$1" ]; do
    sox -t mp3 "$1" -r 8000 -c 1 -w -s -v 0.5 -t wav -A -V - rate 
2> /var/lib/asterisk/mohmp3/sox.err
    # festival "(SayText \"$1\")\n(quit)\n"
    # say "$1"
    # echo -- "$1" | text2wave -F 8000

    shift
done

--

Save the script somewhere. Place link to script in musiconhold.conf instead of 
mpg123, and without any options.

Use example of "custom", but call it "default". I.e.:

[default]
mode=custom
directory=/var/lib/asterisk/mohmp3
;application=/usr/bin/mpg123 -q -r 8000 -f 512 -b 2048 -m -s <-- commented
application=/usr/local/bin/asterixmohplay

All of a sudden, everything worked *perfectly*. Sox used about 5-6% CPU and 
0.5% RAM on a PIII 900MHz / 256MB RAM.

Hope this helps,

Graeme and Michael
mageit.com


P.S. psytrance through Snom 360 kicks!

On Mon, 16 Jan 2006 09:27 pm, Louis-David Mitterrand
wrote:
> Hello,
>
> Using asterisk-1.2.1 I am trying to convert my music-on-hold files from
> .wav to alaw:
>
> 	% sox moh.wav -r 8000 -c 1 moh.al resample -ql
>
> The file sounds fine when listened with:
>
> 	% sox mox.al -t ossdsp /dev/dsp
>
> But when listened through asterisk with an alaw SIP phone the sound is
> clicky and too fast.
>
> Did I forget something in my conversion command?

Hello,

Using asterisk-1.2.1 I am trying to convert my music-on-hold files from
.wav to alaw:

	% sox moh.wav -r 8000 -c 1 moh.al resample -ql

The file sounds fine when listened with:

	% sox mox.al -t ossdsp /dev/dsp

But when listened through asterisk with an alaw SIP phone the sound is
clicky and too fast.

Did I forget something in my conversion command?

-- 
ldm@apartia.fr

Hi,

On Mon, Jan 16 2006 Louis-David Mitterrand wrote:
> Hello,
> 
> Using asterisk-1.2.1 I am trying to convert my music-on-hold files from
> .wav to alaw:
> 
> 	% sox moh.wav -r 8000 -c 1 moh.al resample -ql
> 
> The file sounds fine when listened with:
> 
> 	% sox mox.al -t ossdsp /dev/dsp
> 
> But when listened through asterisk with an alaw SIP phone the sound is
> clicky and too fast.
> 
> Did I forget something in my conversion command?
Are You using bristuff 0.3.0-PRE-1f? I've had the same issue. Dan Austin
wrote a notice in a mail on this list, which solved the problem.

Configure the following lines in /etc/asterisk/asterisk.conf:

[options]
silence_suppression=yes

The bristuff seems to include an additional patch, which isn't stable
enough.

HTH,
Karsten

> Karsten wrote
> On Mon, Jan 16 2006 Louis-David Mitterrand wrote:
>> Hello,
>> 
>> Using asterisk-1.2.1 I am trying to convert my music-on-hold files
from
>> .wav to alaw:
>> 
>> 	% sox moh.wav -r 8000 -c 1 moh.al resample -ql
>> 
>> The file sounds fine when listened with:
>> 
>> 	% sox mox.al -t ossdsp /dev/dsp
>> 
>> But when listened through asterisk with an alaw SIP phone the sound
is
>> clicky and too fast.
>> 
>> Did I forget something in my conversion command?
> Are You using bristuff 0.3.0-PRE-1f? I've had the same issue. Dan
Austin
> wrote a notice in a mail on this list, which solved the problem.
> Configure the following lines in /etc/asterisk/asterisk.conf:
> [options]
> silence_suppression=yes
> The bristuff seems to include an additional patch, which isn't stable
> enough.
Just a small point of clarification, with silence_suppression disabled
there is/should be no difference between 1.2.X without the patch and
with it.  What it does, and maybe silence_suppression is not a good
name for the option, is optionally use a timing source for sending
packets instead of using an incomming stream for timing.

Why this is a good thing-
1.  Muted far-end, so no packets to base the timing on
2.  Fax/Modem with the bulk of the audio being transmit

In a SIP-SIP call with one end on hold, there might not be enough
packets to properly time the streaming MoH.  If that is the case,
then 1.2.X without this patch would have the same problem.  At 
least in theory.  

It would be interesting to see if a vanilla 1.2.1 behaved the 
same way for your installation.

Dan
> HTH,
> Karsten