similar to: Source Dropouts - More info

Thanks everyone! I will answer your questions regarding the AudioPump Web Encoder (http://demo.audiopump.co:3000/): *> Can you please explain the process exactly? what is the encoding server?* There is a server built on Node.js that receives audio data, control data, and metadata from the client over a binary websocket. All of these are multiplexed down the same connection. When the server

html5/js source client? (Xabier Oneca -- xOneca) 2014-05-04 21:00 GMT+02:00 <icecast-request at xiph.org>: > Send Icecast mailing list submissions to > icecast at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/icecast > or, via email, send a message with subject or body 'help' to

Hey, Something about streaming. Live streams are not live, they can be up to 15 to 20 sec off original encoding. This is to to overhead on both the server and client for encoding/decoding the stream, Any trans coding, and and buffering that has to be done on a "slow" connection. Unless the client decoder has some way to sync the stream, this delay will grow tell icecast

Thanks, Brad -- I first turned to VLC but my stream-client device is a Raspberry Pi 3, and there doesn't seem to be a build for the device. That said, I just stumbled across mpg123, a command-line mp3/stream player that has audio buffer and timeout setting which so far looks quite robust. For Icecast2 content, when Icecast kicks a client off for being "too far behind" -- what

"Live streams are not live, they can be up to 15 to 20 sec off original encoding." Something you become aware of very quickly when you're announcing into a mic and have to wait to hear your words! We do a bit of pre-show calibration with folks at the station to determine how long the delay ("latency" in digital-speak) is at the start of the remote broadcast, and start

Thomas, Do you by chance know which players are ignoring the content-type headers? I have done quite a bit of testing for that exact issue but haven't ran into any problems. Perhaps I am testing the wrong players. Thanks, Brad Isbell brad at musatcha.com http://www.musatcha.com On Fri, Nov 21, 2014 at 7:49 AM, "Thomas B. R?cker" <thomas at ruecker.fi> wrote: > On

I have built a web-based source client using the Web Audio API and getUserMedia, called the AudioPump Web Encoder. It uses the SHOUTcast source protocol for now, but I have the code nearly ready for the Icecast source protocol for when someone needs it. You can see a demo here: http://demo.audiopump.co:3000/ The Web Encoder is built with a jQuery Mobile UI optimized for mobile devices at the

Simply use VLC and put it on repeat. If a connection is lost during playback, it will reconnect and pick up in the current live position, like you have suggested, without stopping. If it cannot reconnect after 3 times, it goes to the next playlist item. If the playlist is on repeat, it runs indefinitely. Brad Isbell brad at musatcha.com http://www.musatcha.com On Wed, Apr 26, 2017 at 1:58 PM,

This project appears to be a fork of my Canvas Streaming Example project for Facebook: https://github.com/fbsamples/Canvas-Streaming-Example <https://l.facebook.com/l.php?u=https%3A%2F%2Fgithub.com%2Ffbsamples%2FCanvas-Streaming-Example&h=ATMcDwZSpl5j0Yw_EH8uhG4JciG9nHmZRTEYJBxZVjYA4B3UI3T5_3gYZFMANr4Lkon7gUmRpcsnKkiHZ6AWeU6JKoP4rrYXu4FSJbOfdEHTn2YNkya0wOZM1i1XVD7x1Q> I would recommend

Daniel, I won't make any points regarding DASH's fit with Icecast, but I wanted to address your statement that there is no purpose for adaptive streaming. Cell phone connections are fairly terrible and inconsistent. Even if you have a solid signal on a 4G technology, you could walk around a corner and it will disappear. What works at 3mbit/s one minute might be 10kbit/s the next.

There should be no issue with the varying bit rate. For an MP3 stream, you can change bit rates mid-stream all you want as long as you keep the sample rate and channel counts the same. If you check chrome://media-internals, you'll see that you're getting a PIPELINE_ERROR_DECODE. Since Chrome v64, it has been a lot more picky about the streams it accepts. I suspect that Icecast is

Hello, Are you saying I should be rounding to the nearest second rather than measuring in milliseconds? My current approach is to calculate the track lengths by dividing the number of samples by the samplerate, resulting in a value measured in seconds with at least 8 decimal places. Nevertheless, for some reason a shoutcast + sc_trans setup handles this flawlessly. With Icecast + Ices, data is

2014-05-03 18:40 GMT+02:00 Brad Isbell <brad at musatcha.com>: > The general idea was to make a really simple source client that could be > launched with a single click (such as from a hosting provider's admin > panel). The client accepts parameters on the query-string for configuring > so that in a real-world environment, the user would not have to configure > anything.

On 08/05/2014 01:47 PM, Dean Sauer wrote: > On Tue, 29 Jul 2014 16:21:04 +0000, Thomas B. R?cker wrote: > > >> Which version of Icecast is this? >> I'm not quite sure how to read the above. > That decodes as 2.3.2 or 2.3.3 > > Right now I use 2.3.2 on *buntu based 12.04 > > The 2.3.3 version was on a centos6 box, but will be decommissioned > shortly as

There is a plugin for Nagios called check_ice that you can also just compile and run standalone. See: https://github.com/pozar/check_ice On Sun, Apr 12, 2015 at 7:50 PM, Dean Sauer <wemanageitfl at gmail.com> wrote: > On Sat, 11 Apr 2015 07:03:16 +0000, Philipp Schafft wrote: > > > You can request /admin/stats.xml. That file will return the overall > > server status

Here can take a look other alternative: https://github.com/cdgraff/icecast-mon We base our solution in avprobe/ffprobe, this test like a real listener. Feedback is welcome! this is just first release, but we use on production. Regards, Alejandro 2015-04-12 22:26 GMT-03:00 Dave Pascoe <davekm3t at gmail.com>: > There is a plugin for Nagios called check_ice that you can also just >

The server doesn't control the rate, the source does. Provided you aren't getting corrupt stream data (and it doesn't sound like you are), you don't have a server bug in this case. At a basic level, the server level takes the data that comes in from the source, buffers it, and sends it right back out the door at the rate at which it came in. It isn't entirely clear to me

On 09/30/2014 10:15 PM, Dean Sauer wrote: > On Tue, 05 Aug 2014 21:14:51 +0000, Thomas B. R?cker wrote: > >> Please note that 2.3.2 has an enormous amount of known bugs and some >> security issues. I do not know which patches are applied by the >> distributions to potentially mitigate some of the security issues. > Don't know, but I've not had issues with 2.3.2

Howdy all... When making SIP calls through my X100P from X-Lite to the PSTN I'm getting 3-5 second dropouts in both directions. I've tried ulaw and GSM, but that doesn't seem to make a difference, and the * box is on my local net. Here's my hardware: Celeron 2.4GHz, 512MB, Slackware 9.1, 2 X100P, 1 T100P. Any ideas what could be happening, or pointers as to how to shoot this