[asterisk-users] Using Asterisk to play Icecast streams

Wed Mar 16 16:25:21 CDT 2016

John,

I don't care about the bandwidth. My issue is with the cost of running
madplay each instance of madplay. If we have 1000 possible streams and
madplay using 0.3 of a core per CPU is 3 full cores just to pull the
streams. What I am looking for a is a hybrid where we use the behavior of
cachertclasses=no but if there are more than one people on hold we use the
same "pull" so we aren't invoking madplay over and over.

Another option would be to create a revert ices to play a stream from an
icecast server. Again my goal is to cut down on CPU usage where possible.

On Wed, Mar 16, 2016 at 4:54 PM, John Kiniston <johnkiniston at gmail.com>
wrote:

> Could you setup a local instance of Icecast and point your PBX to it?
>
> It's been years since I did any streaming but I recall my icecast relay
> would only consume bandwith when it had listeners connected to it.
>
> Then you wouldn't have to worry about how many people were listening to a
> single channel as it'd only use the one incoming stream to icecast.
>
> On Wed, Mar 16, 2016 at 1:37 PM, Dovid Bender <dovid at telecurve.com> wrote:
>
>> Steve,
>>
>> These are live streams of events so I can't simply rip the audio. As I
>> mentioned at the end of my email putting in a sleep did help a bit however
>> there are only so many streams Asterisk will grab nicely at once with out
>> spiking the CPU. I also tinkered a bit with real time here is what I found:
>> 1) If we have cachertclasses=no then Asterisk will only pull the stream
>> if some one is listening to that particular class. the upside of this is
>> that we only pull a stream if we need it. The down side is if say there are
>> four people listening to StreamX then we have four separate connections to
>> StreamX.
>> 2) If we have cachertclasses=yes set then Asterisk then we have the
>> opposite of #1. The stream will be pulled if some one starts listening to
>> it. If anyone hangs up then we still keep pulling the stream so over time
>> if every stream is touched then we will over load the CPU.
>>
>> I guess I am trying to find a match between the two. Only pull the stream
>> if some one is invoking MOH for this moh class and if there is no one else
>> on hold to kill it. If this is not available yet we are willing to pay for
>> a patch.
>>
>>
>> On Wed, Mar 16, 2016 at 4:03 PM, Steve Edwards <asterisk.org at sedwards.com
>> > wrote:
>>
>>> On Wed, 16 Mar 2016, Dovid Bender wrote:
>>>
>>> 1) I want to be able to add a few hundred streams per box. Not all
>>>> streams are being listed to at once. Once you add a MOH class to
>>>> musiconhold.conf it stays up forever (which I can understand why). When
>>>> trying realtime madplay wont be loaded until it's called in the dial plan.
>>>> After that it is in Asterisk until I restart asterisk. If we have 20-30
>>>> streams it's OK but once that grows it can bog down the machine.
>>>>
>>>
>>> 2) I found that it for some reason the stream returns a 404 (it goes off
>>>> line etc.) then 10-15% of one core gets locked up until the stream comes
>>>> back online. The issue is that if a few  streams have an issue then I am
>>>> locking up one care.
>>>>
>>>
>>> For these and other reasons, I think streaming is dumb (in most cases).
>>>
>>> I have a client that wanted to allow his customers to enter URLs for
>>> their moh. Bad idea. They kept entering invalid URLs which would cause bits
>>> to crash. Further, we started getting complaints from URL providers as to
>>> why we were streaming 24x7 and from our colo about the bandwidth.
>>>
>>> My solution* (which the customers either haven't figured out yet or
>>> don't mind) was:
>>>
>>> 1) Customers submit URLs to my client.
>>>
>>> 2) Once entered into the system, the customer can select the 'station'
>>> from a web page.
>>>
>>> 3) I record 24 hours of the stream and then use sox to break into
>>> separate files on the silence between songs.
>>>
>>> 4) I create a moh class that random plays the files.
>>>
>>> *) My client approved the solution which may be of questionable legality
>>> depending on the stream.
>>>
>>> --
>>> Thanks in advance,
>>> -------------------------------------------------------------------------
>>> Steve Edwards       sedwards at sedwards.com      Voice: +1-760-468-3867
>>> PST
>>>             https://www.linkedin.com/in/steve-edwards-4244281
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>>                http://www.asterisk.org/hello
>>>
>>> asterisk-users mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>>
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>                http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
>
>
> --
> A human being should be able to change a diaper, plan an invasion, butcher
> a hog, conn a ship, design a building, write a sonnet, balance accounts,
> build a wall, set a bone, comfort the dying, take orders, give orders,
> cooperate, act alone, solve equations, analyze a new problem, pitch manure,
> program a computer, cook a tasty meal, fight efficiently, die gallantly.
> Specialization is for insects.
> ---Heinlein
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> 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/20160316/50e9917b/attachment.html>