The stream usually starts pretty much instantly. I did refine my scripts a
little. I now have a script, stream-mp3 that takes the URL as a parameter. I
also found that I did not need to specify the bit rate of the input, sox
seams to figure that out. So the script now looks like...
stream-mp3
#!/bin/bash
wget -q -O - ${1} | sox -t mp3 - -t ul -r 8000 -c 1 -
And then in musiconhold.conf:
[streamwnycfm]
mode = custom
format = ulaw
application = /bin/bash /usr/bin/stream-mp3 http://wnycfm.streamguys.com:80/
For the application line I am not sure whether the /bin/bash is actually
required or not. It is possible that if I gave the script file a .sh tail,
then it would automatically use bash.
Now, the biggest problem I have is that after a steam starts, if a call
disconnects and then another call comes in later... the stream may no longer
be "live" because sox buffered up a lot of it that asterisk did not read.
See:
http://lists.digium.com/pipermail/asterisk-users/2008-January/204255.html
A hack was suggested that basically kept the stream live all the time, see
http://lists.digium.com/pipermail/asterisk-users/2008-January/204258.html
and
http://lists.digium.com/pipermail/asterisk-users/2008-January/204263.html
I didn't like the hack suggested because keeping the stream live all the
time would soak up CPU and network bandwidth. On my ALIX 2C3 the sox MP3 to
ulaw decode consumes about 15% to 18% of the CPU (see the linux "top"
command). But one of these posts made me go look and see how much i/o
buffering is going on in sox....
I found in ./build_i586/sox-12.17.9/src/stio.c the following line...
if (setvbuf (ft->fp, NULL, _IOFBF, sizeof(char)*ST_BUFSIZ))
This is setting the outbut buffer for sox to 64 KBytes (ST_BUFSIZ is defined
in st_i.h as 8192). For a ulaw stream at 8000 bits per second this works
out to approx 65 seconds of buffering, which is petty much what I was
experiencing... connecting to the stream got a minute of non-live stream,
then a second or two of silence, then a live stream started. So last night
I changed the line in stio.c to...
if (setvbuf (ft->fp, NULL, _IONBF, sizeof(char)*ST_BUFSIZ))
yes, just the change to _IONBF turns off output buffering)
I recompiled (just ran make in the sox-12.19.7 directory) and moved the
resulting sox executable to my astlinux system. This shortened the non-live
portion, but did not eliminate it. Possibly there is buffering at the
output from wget, but I have not looked into that yet.
David
On Thu, Sep 25, 2008 at 9:53 PM, Mark Phillips <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> How long does this stream take to arrive when you put a caller on hold?
>
> In a similar vain I was thinking about Video on Hold. It occurs to me
> that if there was a video file captured into someone's VM account we'd
> be able to migrate it over the the MOH and thus callers would hear the
> audio part and see the video part.
>
> This certainly works where a video VM message is left for a non video
> user.
>
> Mark
>
>
> On Mon, 2008-09-22 at 22:29 -0400, David Kerr wrote:
> > I thought report success in my attempt to use live streaming MP3 as a
> > music on hold source, in case anyone else is interested. Here is what
> > I did...
> >
> > First, create a bash script. For example, /home/stream-wnyc-fm.sh with
> > the following two lines.
> >
> > #!/bin/bash
> > wget -q -O - http://wnycfm.streamguys.com:80/ | sox -t mp3 -r 32000 -
> > -t ul -r 8000 -c 1 -
> >
> > Explanation... use wget to pull the raw MP3 stream from a URL, send
> > result to stdout. Pipe this into sox indicating source is of type mp3,
> > sampled at 32kbps from stdin send output of type ulaw sampled at 8kbps
> > with one channel (mono) to stdout.
> >
> > Now edit your Asterisk musiconhold.conf file and create a new context
> > (or change your default) to the following...
> >
> > [streamwnycfm]
> > mode=custom
> > format=ulaw
> > application=/bin/bash /home/stream-wnyc-fm.sh
> >
> > And there you have it. I have this working on an ALIX 2C3 board
> > running latest 0.6 branch.
> >
> > David
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________ Astlinux-users mailing
> list [email protected]
> https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to
> support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED]
> --
>
>
>
> Mark Phillips, G7LTT/NI2O
> Randolph, NJ
>
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to [EMAIL
PROTECTED]
