Dovid Bender
2016-Mar-16 20:37 UTC
[asterisk-users] Using Asterisk to play Icecast streams
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160316/a8c06d3f/attachment.html>
John Kiniston
2016-Mar-16 20:54 UTC
[asterisk-users] Using Asterisk to play Icecast streams
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160316/08e1dcf5/attachment.html>
Dovid Bender
2016-Mar-16 21:25 UTC
[asterisk-users] Using Asterisk to play Icecast streams
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>