From aham.brahmasmi at gmx.com  Mon Sep  7 15:36:26 2015
From: aham.brahmasmi at gmx.com (Aham Brahmasmi)
Date: Mon, 7 Sep 2015 17:36:26 +0200
Subject: [Icecast] Request for Icecast-libshout 2.3.2 Release Date
References: <trinity-d07b1200-eb5e-4c36-966c-7ec530a519e5-1438317420554@3capp-mailcom-bs03>
Message-ID: <trinity-55af21a2-6ee0-45a7-ad3b-a70dcff3d482-1441640186656@3capp-mailcom-bs11>

Hi,

I would appreciate it if someone could please throw some light on our plan to release icecast-libshout 2.3.2.

In case this is the incorrect list, could I be directed to the relevant list?

Thanks,
ab




Sent:?Friday, July 31, 2015 at 10:07 AM
From:?"Aham Brahmasmi" <aham.brahmasmi at gmx.com>
To:?icecast at xiph.org
Subject:?Request for Icecast-libshout 2.3.2 Release Date
(Resending because previous message got scrubbed)

Hi,

I was wondering if we have an approximate release date/horizon for Icecast-libshout 2.3.2. The last release was 2.3.1 on 20120525 and the 2.3.2 release would contain some very useful features (https://git.xiph.org/?p=icecast-libshout.git;a=blob;f=NEWS).

In case this is the incorrect list for this question, I apologize.

Thanks,
ab


From jeremiahzrogers at gmail.com  Tue Sep  8 01:19:49 2015
From: jeremiahzrogers at gmail.com (Jeremiah Rogers)
Date: Mon, 7 Sep 2015 21:19:49 -0400
Subject: [Icecast] Winamp Shoutcast DSP to Icecast?
Message-ID: <55EE37B5.9020208@gmail.com>

Hello. I'd like to broadcast my Winamp audio via the Shoutcast DSP to my 
Icecast server. According to all i've read, this can be done and should 
be simple, but I can't get it to work. Here are details for how my 
server is set up. Anyone spot anything obvious?

The Icecast version is 2.4.2 on Windows 8.1
I have only the default listen socket defined.
     <listen-socket>
         <port>8000</port>
         <!-- <bind-address>127.0.0.1</bind-address> -->
         <!-- <shoutcast-mount>/jzr</shoutcast-mount> -->
     </listen-socket>

I presume that, because <shoutcast-mount> is commented out, I should be 
able to connect using the default of /stream
Aside from this connection, I have the server relaying 1-2 others at any 
one time via the same config file, and those work just fine. The limits 
section is as follows.
     <limits>
         <clients>32</clients>
         <sources>16</sources>
         <queue-size>1048576</queue-size>
         <client-timeout>30</client-timeout>
         <header-timeout>15</header-timeout>
         <source-timeout>60</source-timeout>
         <burst-on-connect>1</burst-on-connect>
         <burst-size>65535</burst-size>
     </limits>

When I try to connect via Shoutcast DSP, I'm entering the IP of my 
Icecast server, port 8000, the username source, and the password 
specified in <source-password>. I also tried without any username 
specified, and tried both username/password scenarios with the legacy 
checkbox checked and unchecked.

I also tried adding a second listen socket, using port 7000, but that 
made no difference. Thanks in advance for the help.


-- 
Jeremiah Rogers
Mobile (Voice/Text): 704-996-5334
Email: jeremiahzrogers at gmail.com
Facebook/Twitter: /jzrogers



From lion at lion.leolix.org  Tue Sep  8 01:42:37 2015
From: lion at lion.leolix.org (Philipp Schafft)
Date: Tue, 08 Sep 2015 01:42:37 +0000
Subject: [Icecast] Winamp Shoutcast DSP to Icecast?
In-Reply-To: <55EE37B5.9020208@gmail.com>
References: <55EE37B5.9020208@gmail.com>
Message-ID: <20150908014241.3F899128C6@grassland.keep-cool.org>

Good very late night everyone,

On Mon, 2015-09-07 at 21:19 -0400, Jeremiah Rogers wrote:
> The Icecast version is 2.4.2 on Windows 8.1
> I have only the default listen socket defined.
>      <listen-socket>
>          <port>8000</port>
>          <!-- <bind-address>127.0.0.1</bind-address> -->
>          <!-- <shoutcast-mount>/jzr</shoutcast-mount> -->
>      </listen-socket>
> 
> I presume that, because <shoutcast-mount> is commented out, I should
> be 
> able to connect using the default of /stream

The default is /none/. If you do not configure the mount Icecast will
not open the socket for shoutcast's insanity.

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150908/f107229d/attachment.sig>

From jeremiahzrogers at gmail.com  Tue Sep  8 12:48:30 2015
From: jeremiahzrogers at gmail.com (Jeremiah Rogers)
Date: Tue, 8 Sep 2015 08:48:30 -0400
Subject: [Icecast] Winamp Shoutcast DSP to Icecast?
In-Reply-To: <20150908014241.3F899128C6@grassland.keep-cool.org>
References: <55EE37B5.9020208@gmail.com>
	<20150908014241.3F899128C6@grassland.keep-cool.org>
Message-ID: <55EED91E.2060502@gmail.com>

Thanks for the quick response, Philipp. I'll specify the mount and see 
if that fixes my problem. For what it's worth, the following appears in 
the icecast.xml which came with my download of 2.4.2 just beneath the 
authentication section. Is there help I can offer in removing this 
section from, or correcting it in, the file for future packages?

set the mountpoint for a shoutcast source to use, the default if not 
specified is /stream but you can change it here if an alternative is 
wanted or an extension is required

On 9/7/2015 21:42, Philipp Schafft wrote:
> Good very late night everyone,
>
> On Mon, 2015-09-07 at 21:19 -0400, Jeremiah Rogers wrote:
>> The Icecast version is 2.4.2 on Windows 8.1
>> I have only the default listen socket defined.
>>       <listen-socket>
>>           <port>8000</port>
>>           <!-- <bind-address>127.0.0.1</bind-address> -->
>>           <!-- <shoutcast-mount>/jzr</shoutcast-mount> -->
>>       </listen-socket>
>>
>> I presume that, because <shoutcast-mount> is commented out, I should
>> be
>> able to connect using the default of /stream
> The default is /none/. If you do not configure the mount Icecast will
> not open the socket for shoutcast's insanity.
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-- 
Jeremiah Rogers
Mobile (Voice/Text): 704-996-5334
Email: jeremiahzrogers at gmail.com
Facebook/Twitter: /jzrogers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150908/86ba6873/attachment.htm>

From mh747 at outlook.com  Wed Sep  9 22:16:01 2015
From: mh747 at outlook.com (M M)
Date: Wed, 9 Sep 2015 15:16:01 -0700
Subject: [Icecast] Tips for AAC streams and Windows Media Player?
Message-ID: <BLU179-W245970E4ED81EBBA000505ED520@phx.gbl>

We're on Icecast 2.4.2 and stream as MP3. ?We want to move to AAC. ?However, we can't get AAC streams to reliably work in Windows Media Player 12, which comes with Windows 7. ?Many of our listeners are on that client.

Any tips on getting this to work?

We found a stream which works. ?It's http://air.radiorecord.ru:8100/rr_aac. ?Most streams fail though, for example: http://streaming14.tdiradio.com:8000/radiojat. ?We can't figure out the difference between those two streams.

Also, when an AAC stream fails to play in WMP, we can sometimes get it to play by putting WMP into "Now Playing" mode and then clicking the timeline. ?This starts playing content from the beginning of the buffer.


 		 	   		  

From mh747 at outlook.com  Wed Sep  9 23:55:10 2015
From: mh747 at outlook.com (M M)
Date: Wed, 9 Sep 2015 16:55:10 -0700
Subject: [Icecast] Tips for AAC streams and Windows Media Player?
In-Reply-To: <BLU179-W245970E4ED81EBBA000505ED520@phx.gbl>
References: <BLU179-W245970E4ED81EBBA000505ED520@phx.gbl>
Message-ID: <BLU179-W226B8D9F17CEAD96EC9923ED520@phx.gbl>

> From: mh747 at outlook.com
> To: icecast at xiph.org
> Date: Wed, 9 Sep 2015 15:16:01 -0700
> Subject: [Icecast] Tips for AAC streams and Windows Media Player?
> 
> We're on Icecast 2.4.2 and stream as MP3.  We want to move to AAC.  However, we can't get AAC streams to reliably work in Windows Media Player 12, which comes with Windows 7.  Many of our listeners are on that client.


More info: our input source is Darkice.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150909/435551d3/attachment.htm>

From greg at indexcom.com  Thu Sep 10 04:40:46 2015
From: greg at indexcom.com (Greg Ogonowski)
Date: Wed, 9 Sep 2015 21:40:46 -0700
Subject: [Icecast] Tips for AAC streams and Windows Media Player?
In-Reply-To: <BLU179-W245970E4ED81EBBA000505ED520@phx.gbl>
References: <BLU179-W245970E4ED81EBBA000505ED520@phx.gbl>
Message-ID: <365701d0eb82$dc631060$95293120$@indexcom.com>

This is buggy Windows Media Player that we have been trying to get Microsoft
to fix for many years now.
Windows Media Player doesn't seem to have any product management these days.
The last time we submitted a detailed bug report with sample streams, they
can back and stated there was something wrong with our web server, because
it would only download at 32kbps! At that point, we gave up, since it was
pretty obvious that it was hopeless, in that they didn't understand the
difference between streaming and downloading.
This is exactly one of the many reasons why Microsoft is finishing last.
They can't even get over 10-year technology to work!

If anyone is interested in the detailed Bug Report with captures, I still
have the .pdf.
We attempted to work around this with the KH Build of Icecast2 Server, but
then it was broken again in different ways in Windows 8.0, 8.1 and now 10.

>From the guys that brought HE-AAC streaming to the Internet back in 2003,
with Orban Opticodec-PC, now StreamS Live Encoder.
/greg ogonowski.


-----Original Message-----
From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of M M
Sent: Wednesday, 09 September, 2015 15:16
To: icecast at xiph.org
Subject: [Icecast] Tips for AAC streams and Windows Media Player?

We're on Icecast 2.4.2 and stream as MP3. ?We want to move to AAC. ?However,
we can't get AAC streams to reliably work in Windows Media Player 12, which
comes with Windows 7. ?Many of our listeners are on that client.

Any tips on getting this to work?

We found a stream which works. ?It's http://air.radiorecord.ru:8100/rr_aac.
?Most streams fail though, for example:
http://streaming14.tdiradio.com:8000/radiojat. ?We can't figure out the
difference between those two streams.

Also, when an AAC stream fails to play in WMP, we can sometimes get it to
play by putting WMP into "Now Playing" mode and then clicking the timeline.
?This starts playing content from the beginning of the buffer.


 		 	   		  
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast



From lion at lion.leolix.org  Thu Sep 10 14:57:10 2015
From: lion at lion.leolix.org (Philipp Schafft)
Date: Thu, 10 Sep 2015 14:57:10 +0000
Subject: [Icecast] Winamp Shoutcast DSP to Icecast?
In-Reply-To: <55EED91E.2060502@gmail.com>
References: <55EE37B5.9020208@gmail.com>
	<20150908014241.3F899128C6@grassland.keep-cool.org>
	<55EED91E.2060502@gmail.com>
Message-ID: <20150910145712.5DB6C128F4@grassland.keep-cool.org>

Good afternoon!

On Tue, 2015-09-08 at 08:48 -0400, Jeremiah Rogers wrote:
> Thanks for the quick response, Philipp. I'll specify the mount and see
> if that fixes my problem. For what it's worth, the following appears
> in the icecast.xml which came with my download of 2.4.2 just beneath
> the authentication section. Is there help I can offer in removing this
> section from, or correcting it in, the file for future packages?
> 
> set the mountpoint for a shoutcast source to use, the default if not
> specified is /stream but you can change it here if an alternative is
> wanted or an extension is required

Thank you for the hint. I just fixed the comment (after I found it ;).

If there is any problem left, please let us know!

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150910/4c8e20b4/attachment.sig>

From nick at 4points.ca  Tue Sep 15 16:23:27 2015
From: nick at 4points.ca (Nick D'Angelo)
Date: Tue, 15 Sep 2015 12:23:27 -0400
Subject: [Icecast] Best source for creating multiple streams
In-Reply-To: <91715D141FAEB90B.1-800b6976-8ed8-4722-aee2-bca88452832b@mail.outlook.com>
References: <CAKsaqBDe6FqK1R_B3KmkbM5xvAGC1MqEXZr27uRCfJSVHkEsaA@mail.gmail.com>
	<91715D141FAEB90B.1-800b6976-8ed8-4722-aee2-bca88452832b@mail.outlook.com>
Message-ID: <001f01d0efd2$da0e1130$8e2a3390$@ca>

How do you create different logs files for each stream?

 

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Camara, Carlos
Sent: Saturday, August 22, 2015 12:43 AM
To: icecast at xiph.org; icecast at xiph.org
Subject: Re: [Icecast] Best source for creating multiple streams

 

With IceS2 this is easily accomplished by copying the 'ices-playlist.XML'
file (I have 3 copies in the same directory with different names). Then
define a new mount point in the xml file and point  to a different play list
file within the XML ( random can be enabled in the xml).  Once this is
complete, in terminal start ices2 with each xml.

~ $ sudo ices2 /media/music/ices-playlist_s.XML
~ $ sudo ices2 /media/music/ices-playlist_mylist.XML
~ $ sudo ices2 /media/music/ices-playlist_classic.XML

I also define different log files for each stream.

Carl

Sent From My Android

From: Spam Catcher
Sent: Saturday, August 22, 12:01 AM
Subject: [Icecast] Best source for creating multiple streams
To: Icecast streaming server user discussions

Hi there. I'm trying to find a way to create multiple streams with one
source client. Each of the streams should read from a different playlist
file and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I don't see
a way to specify different playlists for each mountpoint. I was wondering if
anyone had any suggestions for a source I could use to do this? Thanks
_______________________________________________ Icecast mailing list
Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast 





On Fri, Aug 21, 2015 at 9:01 PM -0700, "Spam Catcher"
<spamcatcher447 at gmail.com> wrote:

Hi there.

  I'm trying to find a way to create multiple streams with one source
client. Each of the streams should read from a different playlist file
and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I
don't see a way to specify different playlists for each mountpoint. I
was wondering if anyone had any suggestions for a source I could use
to do this?

  Thanks
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150915/fafcbdf9/attachment.htm>

From Carlos.Camara at Staples.com  Tue Sep 15 20:53:55 2015
From: Carlos.Camara at Staples.com (Camara, Carlos)
Date: Tue, 15 Sep 2015 20:53:55 +0000
Subject: [Icecast] Best source for creating multiple streams
In-Reply-To: <001f01d0efd2$da0e1130$8e2a3390$@ca>
References: <CAKsaqBDe6FqK1R_B3KmkbM5xvAGC1MqEXZr27uRCfJSVHkEsaA@mail.gmail.com>
	<91715D141FAEB90B.1-800b6976-8ed8-4722-aee2-bca88452832b@mail.outlook.com>
	<001f01d0efd2$da0e1130$8e2a3390$@ca>
Message-ID: <E70D746245373E47BD88E6D4024C357F40BFC1B2@nedexmb102.staplesams.com>

In the ices-playlist.XML file there are two tags <logpath>/pathtofile</logpath> and <logfile>ices.log</logfile>

You can choose a different name for each instance/stream: <logfile>mylist.log</logfile>
Or you can change the path for the each instance/stream: <logpath/media/music/</logpath><logfile>ices.log</logfile>
Just be sure the account that the instance runs under has write to that directory.

<logpath>/tmp</logpath>
<!--  where logs, etc go.  -->
<logfile>ices.log</logfile>

Carl

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf Of Nick D'Angelo
Sent: Tuesday, September 15, 2015 12:23 PM
To: 'Icecast streaming server user discussions'
Subject: Re: [Icecast] Best source for creating multiple streams

How do you create different logs files for each stream?

From: icecast-bounces at xiph.org<mailto:icecast-bounces at xiph.org> [mailto:icecast-bounces at xiph.org] On Behalf Of Camara, Carlos
Sent: Saturday, August 22, 2015 12:43 AM
To: icecast at xiph.org<mailto:icecast at xiph.org>; icecast at xiph.org<mailto:icecast at xiph.org>
Subject: Re: [Icecast] Best source for creating multiple streams


With IceS2 this is easily accomplished by copying the 'ices-playlist.XML' file (I have 3 copies in the same directory with different names). Then define a new mount point in the xml file and point  to a different play list file within the XML ( random can be enabled in the xml).  Once this is complete, in terminal start ices2 with each xml.

~ $ sudo ices2 /media/music/ices-playlist_s.XML
~ $ sudo ices2 /media/music/ices-playlist_mylist.XML
~ $ sudo ices2 /media/music/ices-playlist_classic.XML

I also define different log files for each stream.

Carl

Sent From My Android

From: Spam Catcher
Sent: Saturday, August 22, 12:01 AM
Subject: [Icecast] Best source for creating multiple streams
To: Icecast streaming server user discussions

Hi there. I'm trying to find a way to create multiple streams with one source client. Each of the streams should read from a different playlist file and randomly pull and play songs from the file. I know how to do this with a single stream with clients such as IceS and Ezstream, but I don't see a way to specify different playlists for each mountpoint. I was wondering if anyone had any suggestions for a source I could use to do this? Thanks _______________________________________________ Icecast mailing list Icecast at xiph.org<mailto:Icecast at xiph.org> http://lists.xiph.org/mailman/listinfo/icecast

On Fri, Aug 21, 2015 at 9:01 PM -0700, "Spam Catcher" <spamcatcher447 at gmail.com<mailto:spamcatcher447 at gmail.com>> wrote:
Hi there.

  I'm trying to find a way to create multiple streams with one source
client. Each of the streams should read from a different playlist file
and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I
don't see a way to specify different playlists for each mountpoint. I
was wondering if anyone had any suggestions for a source I could use
to do this?

  Thanks
_______________________________________________
Icecast mailing list
Icecast at xiph.org<mailto:Icecast at xiph.org>
http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150915/7c380783/attachment.htm>

From jeremiahzrogers at gmail.com  Wed Sep 16 00:45:32 2015
From: jeremiahzrogers at gmail.com (Jeremiah Rogers)
Date: Tue, 15 Sep 2015 20:45:32 -0400
Subject: [Icecast] Winamp Shoutcast DSP to Icecast?
In-Reply-To: <55EED91E.2060502@gmail.com>
References: <55EE37B5.9020208@gmail.com>
	<20150908014241.3F899128C6@grassland.keep-cool.org>
	<55EED91E.2060502@gmail.com>
Message-ID: <63575444-DCFB-4B6C-B143-D349410203FE@gmail.com>

I still can't get my Shoutcast DSP to connect to my Icecast 2.4.2. Is there someone who can help me offlist, or is there someone who has this working and can provide a config file? Thanks!

Jeremiah Rogers
Cell: 704-996-5334
Email: jeremiahzrogers at gmail.com
Social Networking: /jzrogers


> On Sep 8, 2015, at 08:48, Jeremiah Rogers <jeremiahzrogers at gmail.com> wrote:
> 
> Thanks for the quick response, Philipp. I'll specify the mount and see if that fixes my problem. For what it's worth, the following appears in the icecast.xml which came with my download of 2.4.2 just beneath the authentication section. Is there help I can offer in removing this section from, or correcting it in, the file for future packages?
> 
> set the mountpoint for a shoutcast source to use, the default if not specified is /stream but you can change it here if an alternative is wanted or an extension is required
> 
>> On 9/7/2015 21:42, Philipp Schafft wrote:
>> Good very late night everyone,
>> 
>> On Mon, 2015-09-07 at 21:19 -0400, Jeremiah Rogers wrote:
>>> The Icecast version is 2.4.2 on Windows 8.1
>>> I have only the default listen socket defined.
>>>      <listen-socket>
>>>          <port>8000</port>
>>>          <!-- <bind-address>127.0.0.1</bind-address> -->
>>>          <!-- <shoutcast-mount>/jzr</shoutcast-mount> -->
>>>      </listen-socket>
>>> 
>>> I presume that, because <shoutcast-mount> is commented out, I should
>>> be 
>>> able to connect using the default of /stream
>> The default is /none/. If you do not configure the mount Icecast will
>> not open the socket for shoutcast's insanity.
>> 
>> 
>> 
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
> 
> -- 
> Jeremiah Rogers
> Mobile (Voice/Text): 704-996-5334
> Email: jeremiahzrogers at gmail.com
> Facebook/Twitter: /jzrogers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150915/2d790614/attachment.htm>

From lion at lion.leolix.org  Wed Sep 16 07:20:54 2015
From: lion at lion.leolix.org (Philipp Schafft)
Date: Wed, 16 Sep 2015 07:20:54 +0000
Subject: [Icecast] Winamp Shoutcast DSP to Icecast?
In-Reply-To: <63575444-DCFB-4B6C-B143-D349410203FE@gmail.com>
References: <55EE37B5.9020208@gmail.com>
	<20150908014241.3F899128C6@grassland.keep-cool.org>
	<55EED91E.2060502@gmail.com>
	<63575444-DCFB-4B6C-B143-D349410203FE@gmail.com>
Message-ID: <20150916072056.D6ACE128F5@grassland.keep-cool.org>

Good morning!

On Tue, 2015-09-15 at 20:45 -0400, Jeremiah Rogers wrote:
> I still can't get my Shoutcast DSP to connect to my Icecast 2.4.2. Is
> there someone who can help me offlist, or is there someone who has
> this working and can provide a config file? Thanks!

This is strange.
You can always try to get some help on our IRC channel on Freenode
(irc.freenode.org), #icecast

It's best to try it while the sun touches central Europe.

Have a nice day!


> Jeremiah Rogers
> Cell: 704-996-5334
> Email: jeremiahzrogers at gmail.com
> Social Networking: /jzrogers
> 
> 
> 
> On Sep 8, 2015, at 08:48, Jeremiah Rogers <jeremiahzrogers at gmail.com>
> wrote:
> 
> 
> > Thanks for the quick response, Philipp. I'll specify the mount and
> > see if that fixes my problem. For what it's worth, the following
> > appears in the icecast.xml which came with my download of 2.4.2 just
> > beneath the authentication section. Is there help I can offer in
> > removing this section from, or correcting it in, the file for future
> > packages?
> > 
> > set the mountpoint for a shoutcast source to use, the default if not
> > specified is /stream but you can change it here if an alternative is
> > wanted or an extension is required
> > 
> > On 9/7/2015 21:42, Philipp Schafft wrote:
> > 
> > > Good very late night everyone,
> > > 
> > > On Mon, 2015-09-07 at 21:19 -0400, Jeremiah Rogers wrote:
> > > > The Icecast version is 2.4.2 on Windows 8.1
> > > > I have only the default listen socket defined.
> > > >      <listen-socket>
> > > >          <port>8000</port>
> > > >          <!-- <bind-address>127.0.0.1</bind-address> -->
> > > >          <!-- <shoutcast-mount>/jzr</shoutcast-mount> -->
> > > >      </listen-socket>
> > > > 
> > > > I presume that, because <shoutcast-mount> is commented out, I should
> > > > be 
> > > > able to connect using the default of /stream
> > > The default is /none/. If you do not configure the mount Icecast will
> > > not open the socket for shoutcast's insanity.
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Icecast mailing list
> > > Icecast at xiph.org
> > > http://lists.xiph.org/mailman/listinfo/icecast
> > 
> > -- 
> > Jeremiah Rogers
> > Mobile (Voice/Text): 704-996-5334
> > Email: jeremiahzrogers at gmail.com
> > Facebook/Twitter: /jzrogers
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150916/4d64b1c9/attachment.sig>

From nick at 4points.ca  Thu Sep 17 16:10:58 2015
From: nick at 4points.ca (Nick D'Angelo)
Date: Thu, 17 Sep 2015 12:10:58 -0400
Subject: [Icecast] Best source for creating multiple streams
In-Reply-To: <E70D746245373E47BD88E6D4024C357F40BFC1B2@nedexmb102.staplesams.com>
References: <CAKsaqBDe6FqK1R_B3KmkbM5xvAGC1MqEXZr27uRCfJSVHkEsaA@mail.gmail.com>	<91715D141FAEB90B.1-800b6976-8ed8-4722-aee2-bca88452832b@mail.outlook.com>	<001f01d0efd2$da0e1130$8e2a3390$@ca>
	<E70D746245373E47BD88E6D4024C357F40BFC1B2@nedexmb102.staplesams.com>
Message-ID: <002101d0f163$70b8f410$522adc30$@ca>

Is Ices2 the same as icecast2?

 

 

Nick D'Angelo

4Points.ca Inc

President/CEO

 <http://www.4points.ca/> http://www.4points.ca

 

T: 1-855-275-9713

 

NOTE: You can request an account on the 4Points.ca site and you can
collaborate on future enhancements and upgrades.  Visit
<http://www.4points.ca/> 4Points.ca and request an account at the top right
corner.

 

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Camara, Carlos
Sent: Tuesday, September 15, 2015 4:54 PM
To: Icecast streaming server user discussions
Subject: Re: [Icecast] Best source for creating multiple streams

 

In the ices-playlist.XML file there are two tags
<logpath>/pathtofile</logpath> and <logfile>ices.log</logfile>

 

You can choose a different name for each instance/stream:
<logfile>mylist.log</logfile>

Or you can change the path for the each instance/stream:
<logpath/media/music/</logpath><logfile>ices.log</logfile>

Just be sure the account that the instance runs under has write to that
directory.

 

<logpath>/tmp</logpath>

<!--  where logs, etc go.  -->

<logfile>ices.log</logfile>

 

Carl

 

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Nick D'Angelo
Sent: Tuesday, September 15, 2015 12:23 PM
To: 'Icecast streaming server user discussions'
Subject: Re: [Icecast] Best source for creating multiple streams

 

How do you create different logs files for each stream?

 

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Camara, Carlos
Sent: Saturday, August 22, 2015 12:43 AM
To: icecast at xiph.org; icecast at xiph.org
Subject: Re: [Icecast] Best source for creating multiple streams

 

With IceS2 this is easily accomplished by copying the 'ices-playlist.XML'
file (I have 3 copies in the same directory with different names). Then
define a new mount point in the xml file and point  to a different play list
file within the XML ( random can be enabled in the xml).  Once this is
complete, in terminal start ices2 with each xml.

~ $ sudo ices2 /media/music/ices-playlist_s.XML
~ $ sudo ices2 /media/music/ices-playlist_mylist.XML
~ $ sudo ices2 /media/music/ices-playlist_classic.XML

I also define different log files for each stream.

Carl

Sent From My Android

From: Spam Catcher
Sent: Saturday, August 22, 12:01 AM
Subject: [Icecast] Best source for creating multiple streams
To: Icecast streaming server user discussions

Hi there. I'm trying to find a way to create multiple streams with one
source client. Each of the streams should read from a different playlist
file and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I don't see
a way to specify different playlists for each mountpoint. I was wondering if
anyone had any suggestions for a source I could use to do this? Thanks
_______________________________________________ Icecast mailing list
Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast 

 

On Fri, Aug 21, 2015 at 9:01 PM -0700, "Spam Catcher"
<spamcatcher447 at gmail.com> wrote:

Hi there.

  I'm trying to find a way to create multiple streams with one source
client. Each of the streams should read from a different playlist file
and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I
don't see a way to specify different playlists for each mountpoint. I
was wondering if anyone had any suggestions for a source I could use
to do this?

  Thanks
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150917/23300387/attachment.htm>

From nick at 4points.ca  Thu Sep 17 16:56:55 2015
From: nick at 4points.ca (Nick D'Angelo)
Date: Thu, 17 Sep 2015 12:56:55 -0400
Subject: [Icecast] Best source for creating multiple streams
In-Reply-To: <E70D746245373E47BD88E6D4024C357F40BFC1B2@nedexmb102.staplesams.com>
References: <CAKsaqBDe6FqK1R_B3KmkbM5xvAGC1MqEXZr27uRCfJSVHkEsaA@mail.gmail.com>	<91715D141FAEB90B.1-800b6976-8ed8-4722-aee2-bca88452832b@mail.outlook.com>	<001f01d0efd2$da0e1130$8e2a3390$@ca>
	<E70D746245373E47BD88E6D4024C357F40BFC1B2@nedexmb102.staplesams.com>
Message-ID: <003b01d0f169$dc2e3420$948a9c60$@ca>

Carl, are you saying that I need ices2 for two mount points?

 

I don't have an ices-playlist.xml file, I only have an
/etc/icecast2/Icecast.xml file.

 

Nick D'Angelo

4Points.ca Inc

President/CEO

 <http://www.4points.ca/> http://www.4points.ca

 

T: 1-855-275-9713

 

NOTE: You can request an account on the 4Points.ca site and you can
collaborate on future enhancements and upgrades.  Visit
<http://www.4points.ca/> 4Points.ca and request an account at the top right
corner.

 

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Camara, Carlos
Sent: Tuesday, September 15, 2015 4:54 PM
To: Icecast streaming server user discussions
Subject: Re: [Icecast] Best source for creating multiple streams

 

In the ices-playlist.XML file there are two tags
<logpath>/pathtofile</logpath> and <logfile>ices.log</logfile>

 

You can choose a different name for each instance/stream:
<logfile>mylist.log</logfile>

Or you can change the path for the each instance/stream:
<logpath/media/music/</logpath><logfile>ices.log</logfile>

Just be sure the account that the instance runs under has write to that
directory.

 

<logpath>/tmp</logpath>

<!--  where logs, etc go.  -->

<logfile>ices.log</logfile>

 

Carl

 

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Nick D'Angelo
Sent: Tuesday, September 15, 2015 12:23 PM
To: 'Icecast streaming server user discussions'
Subject: Re: [Icecast] Best source for creating multiple streams

 

How do you create different logs files for each stream?

 

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf
Of Camara, Carlos
Sent: Saturday, August 22, 2015 12:43 AM
To: icecast at xiph.org; icecast at xiph.org
Subject: Re: [Icecast] Best source for creating multiple streams

 

With IceS2 this is easily accomplished by copying the 'ices-playlist.XML'
file (I have 3 copies in the same directory with different names). Then
define a new mount point in the xml file and point  to a different play list
file within the XML ( random can be enabled in the xml).  Once this is
complete, in terminal start ices2 with each xml.

~ $ sudo ices2 /media/music/ices-playlist_s.XML
~ $ sudo ices2 /media/music/ices-playlist_mylist.XML
~ $ sudo ices2 /media/music/ices-playlist_classic.XML

I also define different log files for each stream.

Carl

Sent From My Android

From: Spam Catcher
Sent: Saturday, August 22, 12:01 AM
Subject: [Icecast] Best source for creating multiple streams
To: Icecast streaming server user discussions

Hi there. I'm trying to find a way to create multiple streams with one
source client. Each of the streams should read from a different playlist
file and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I don't see
a way to specify different playlists for each mountpoint. I was wondering if
anyone had any suggestions for a source I could use to do this? Thanks
_______________________________________________ Icecast mailing list
Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast 

 

On Fri, Aug 21, 2015 at 9:01 PM -0700, "Spam Catcher"
<spamcatcher447 at gmail.com> wrote:

Hi there.

  I'm trying to find a way to create multiple streams with one source
client. Each of the streams should read from a different playlist file
and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I
don't see a way to specify different playlists for each mountpoint. I
was wondering if anyone had any suggestions for a source I could use
to do this?

  Thanks
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150917/5b9e34b6/attachment.htm>

From Carlos.Camara at Staples.com  Thu Sep 17 17:13:05 2015
From: Carlos.Camara at Staples.com (Camara, Carlos)
Date: Thu, 17 Sep 2015 17:13:05 +0000
Subject: [Icecast] Best source for creating multiple streams
In-Reply-To: <003b01d0f169$dc2e3420$948a9c60$@ca>
References: <CAKsaqBDe6FqK1R_B3KmkbM5xvAGC1MqEXZr27uRCfJSVHkEsaA@mail.gmail.com>
	<91715D141FAEB90B.1-800b6976-8ed8-4722-aee2-bca88452832b@mail.outlook.com>
	<001f01d0efd2$da0e1130$8e2a3390$@ca>
	<E70D746245373E47BD88E6D4024C357F40BFC1B2@nedexmb102.staplesams.com>
	<003b01d0f169$dc2e3420$948a9c60$@ca>
Message-ID: <E70D746245373E47BD88E6D4024C357F40BFEC99@nedexmb102.staplesams.com>

Yes.

Icecast2 is the server that sends streams out to the internet for users/players to consume.

Ices2 is the source client that provides the streams to the server (icecast2).
There are other source clients out there but a source client and a server are both required for a stream to reach the internet.
The server and source client can run on the same computer or on separate computer.

For multiple streams you will need multiple mount points (provided by the source client) but only one server (icecast2)

Carl

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On Behalf Of Nick D'Angelo
Sent: Thursday, September 17, 2015 12:57 PM
To: 'Icecast streaming server user discussions'
Subject: Re: [Icecast] Best source for creating multiple streams

Carl, are you saying that I need ices2 for two mount points?

I don't have an ices-playlist.xml file, I only have an /etc/icecast2/Icecast.xml file.

Nick D'Angelo
4Points.ca Inc
President/CEO
http://www.4points.ca<http://www.4points.ca/>

T: 1-855-275-9713

NOTE: You can request an account on the 4Points.ca site and you can collaborate on future enhancements and upgrades.  Visit 4Points.ca<http://www.4points.ca/> and request an account at the top right corner.

From: icecast-bounces at xiph.org<mailto:icecast-bounces at xiph.org> [mailto:icecast-bounces at xiph.org] On Behalf Of Camara, Carlos
Sent: Tuesday, September 15, 2015 4:54 PM
To: Icecast streaming server user discussions
Subject: Re: [Icecast] Best source for creating multiple streams

In the ices-playlist.XML file there are two tags <logpath>/pathtofile</logpath> and <logfile>ices.log</logfile>

You can choose a different name for each instance/stream: <logfile>mylist.log</logfile>
Or you can change the path for the each instance/stream: <logpath/media/music/</logpath><logfile>ices.log</logfile>
Just be sure the account that the instance runs under has write to that directory.

<logpath>/tmp</logpath>
<!--  where logs, etc go.  -->
<logfile>ices.log</logfile>

Carl

From: icecast-bounces at xiph.org<mailto:icecast-bounces at xiph.org> [mailto:icecast-bounces at xiph.org] On Behalf Of Nick D'Angelo
Sent: Tuesday, September 15, 2015 12:23 PM
To: 'Icecast streaming server user discussions'
Subject: Re: [Icecast] Best source for creating multiple streams

How do you create different logs files for each stream?

From: icecast-bounces at xiph.org<mailto:icecast-bounces at xiph.org> [mailto:icecast-bounces at xiph.org] On Behalf Of Camara, Carlos
Sent: Saturday, August 22, 2015 12:43 AM
To: icecast at xiph.org<mailto:icecast at xiph.org>; icecast at xiph.org<mailto:icecast at xiph.org>
Subject: Re: [Icecast] Best source for creating multiple streams


With IceS2 this is easily accomplished by copying the 'ices-playlist.XML' file (I have 3 copies in the same directory with different names). Then define a new mount point in the xml file and point  to a different play list file within the XML ( random can be enabled in the xml).  Once this is complete, in terminal start ices2 with each xml.

~ $ sudo ices2 /media/music/ices-playlist_s.XML
~ $ sudo ices2 /media/music/ices-playlist_mylist.XML
~ $ sudo ices2 /media/music/ices-playlist_classic.XML

I also define different log files for each stream.

Carl

Sent From My Android

From: Spam Catcher
Sent: Saturday, August 22, 12:01 AM
Subject: [Icecast] Best source for creating multiple streams
To: Icecast streaming server user discussions

Hi there. I'm trying to find a way to create multiple streams with one source client. Each of the streams should read from a different playlist file and randomly pull and play songs from the file. I know how to do this with a single stream with clients such as IceS and Ezstream, but I don't see a way to specify different playlists for each mountpoint. I was wondering if anyone had any suggestions for a source I could use to do this? Thanks _______________________________________________ Icecast mailing list Icecast at xiph.org<mailto:Icecast at xiph.org> http://lists.xiph.org/mailman/listinfo/icecast

On Fri, Aug 21, 2015 at 9:01 PM -0700, "Spam Catcher" <spamcatcher447 at gmail.com<mailto:spamcatcher447 at gmail.com>> wrote:
Hi there.

  I'm trying to find a way to create multiple streams with one source
client. Each of the streams should read from a different playlist file
and randomly pull and play songs from the file. I know how to do this
with a single stream with clients such as IceS and Ezstream, but I
don't see a way to specify different playlists for each mountpoint. I
was wondering if anyone had any suggestions for a source I could use
to do this?

  Thanks
_______________________________________________
Icecast mailing list
Icecast at xiph.org<mailto:Icecast at xiph.org>
http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150917/2a65c460/attachment.htm>

From orionjensen at clearlaunch.com  Fri Sep 18 21:31:24 2015
From: orionjensen at clearlaunch.com (Orion Jensen)
Date: Fri, 18 Sep 2015 16:31:24 -0500
Subject: [Icecast] Use case question
Message-ID: <CAO+4TYydS_oVnOYOmyB-mcG=+q-Hh+UVJS=VRnWN0_4mPatM8Q@mail.gmail.com>

I'm investigating the build out of a Push to Talk server with multiple
subscribers as part of a mobile app.

Has anyone seen this usecase with Icecast?

Any suggestions or places to look.

Thanks,



*Orion Jensen*
CEO  | ClearLaunch
1408 East 13th Street | Austin, TX 78702
Skype: orion.jensen | Mobile: 1.512.270.3976
orionjensen at ClearLaunch.com <peyton at clearlaunch.com> | ClearLaunch.com
<http://t.sidekickopen09.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg64QWBnW3MPp-P64QZlKW7gbMDs56dTrtdrw25Y02?t=http%3A%2F%2Fwww.clearlaunch.com%2F&si=6552763575566336&pi=50aa7a1e-13c3-4b39-900f-aca4b1203a7e>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150918/c6506629/attachment.htm>

From epirat07 at gmail.com  Fri Sep 18 22:32:39 2015
From: epirat07 at gmail.com (Marvin Scholz)
Date: Sat, 19 Sep 2015 00:32:39 +0200
Subject: [Icecast] Use case question
In-Reply-To: <CAO+4TYydS_oVnOYOmyB-mcG=+q-Hh+UVJS=VRnWN0_4mPatM8Q@mail.gmail.com>
References: <CAO+4TYydS_oVnOYOmyB-mcG=+q-Hh+UVJS=VRnWN0_4mPatM8Q@mail.gmail.com>
Message-ID: <060EF53C-5B5A-4845-AEE4-AC3E7B0D02CF@gmail.com>

On 18 Sep 2015, at 23:31, Orion Jensen wrote:

> I'm investigating the build out of a Push to Talk server with multiple
> subscribers as part of a mobile app.

That most likely will not work with Icecast, you might want to check out 
alternatives. Icecast is a HTTP streaming server so there will be a 
quite noticeable "lag" of a few seconds (usually 5 to 10), which I guess 
is not desired for your usecase?


From dennis at heerema.net  Fri Sep 18 23:01:43 2015
From: dennis at heerema.net (Dennis Heerema)
Date: Sat, 19 Sep 2015 01:01:43 +0200
Subject: [Icecast] Use case question
In-Reply-To: <060EF53C-5B5A-4845-AEE4-AC3E7B0D02CF@gmail.com>
References: <CAO+4TYydS_oVnOYOmyB-mcG=+q-Hh+UVJS=VRnWN0_4mPatM8Q@mail.gmail.com>
	<060EF53C-5B5A-4845-AEE4-AC3E7B0D02CF@gmail.com>
Message-ID: <55FC97D7.2030206@heerema.net>

Use apps like mumble of Teamtalk, they are build to do what you want to do.

Kind regards,

Dennis

Op 19-9-2015 om 00:32 schreef Marvin Scholz:
> On 18 Sep 2015, at 23:31, Orion Jensen wrote:
>
>> I'm investigating the build out of a Push to Talk server with multiple
>> subscribers as part of a mobile app.
> That most likely will not work with Icecast, you might want to check out 
> alternatives. Icecast is a HTTP streaming server so there will be a 
> quite noticeable "lag" of a few seconds (usually 5 to 10), which I guess 
> is not desired for your usecase?
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150919/da1e093c/attachment.sig>

From orionjensen at clearlaunch.com  Fri Sep 18 23:37:18 2015
From: orionjensen at clearlaunch.com (Orion Jensen)
Date: Fri, 18 Sep 2015 18:37:18 -0500
Subject: [Icecast] Use case question
In-Reply-To: <55FC97D7.2030206@heerema.net>
References: <CAO+4TYydS_oVnOYOmyB-mcG=+q-Hh+UVJS=VRnWN0_4mPatM8Q@mail.gmail.com>
	<060EF53C-5B5A-4845-AEE4-AC3E7B0D02CF@gmail.com>
	<55FC97D7.2030206@heerema.net>
Message-ID: <CAO+4TYyiPHeBwwi3e9Bck1RRjOCDAvZ6J3uiGVxcOH5Ho-a9Cg@mail.gmail.com>

Thanks for the feedback and suggestions.

Dennis, any chance you have a link for mumble of Teamtalk.  I tried a few
searches and I don't think I'm finding the right thing.


Appreciate the help guys.




*Orion Jensen*
CEO  | ClearLaunch
1408 East 13th Street | Austin, TX 78702
Skype: orion.jensen | Mobile: 1.512.270.3976
orionjensen at ClearLaunch.com <peyton at clearlaunch.com> | ClearLaunch.com
<http://t.sidekickopen09.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg64QWBnW3MPp-P64QZlKW7gbMDs56dTrtdrw25Y02?t=http%3A%2F%2Fwww.clearlaunch.com%2F&si=6552763575566336&pi=50aa7a1e-13c3-4b39-900f-aca4b1203a7e>



On Fri, Sep 18, 2015 at 6:01 PM, Dennis Heerema <dennis at heerema.net> wrote:

> Use apps like mumble of Teamtalk, they are build to do what you want to do.
>
> Kind regards,
>
> Dennis
>
> Op 19-9-2015 om 00:32 schreef Marvin Scholz:
> > On 18 Sep 2015, at 23:31, Orion Jensen wrote:
> >
> >> I'm investigating the build out of a Push to Talk server with multiple
> >> subscribers as part of a mobile app.
> > That most likely will not work with Icecast, you might want to check out
> > alternatives. Icecast is a HTTP streaming server so there will be a
> > quite noticeable "lag" of a few seconds (usually 5 to 10), which I guess
> > is not desired for your usecase?
> > _______________________________________________
> > Icecast mailing list
> > Icecast at xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150918/137bc491/attachment.htm>

From orionjensen at clearlaunch.com  Wed Sep 23 20:26:51 2015
From: orionjensen at clearlaunch.com (Orion Jensen)
Date: Wed, 23 Sep 2015 15:26:51 -0500
Subject: [Icecast] Use case question
In-Reply-To: <060EF53C-5B5A-4845-AEE4-AC3E7B0D02CF@gmail.com>
References: <CAO+4TYydS_oVnOYOmyB-mcG=+q-Hh+UVJS=VRnWN0_4mPatM8Q@mail.gmail.com>
	<060EF53C-5B5A-4845-AEE4-AC3E7B0D02CF@gmail.com>
Message-ID: <CAO+4TYzveCNhHbuVrTP15i84egaqX-YeTAR2qj8bVW-+aPuGXw@mail.gmail.com>

Hi Guys,

Can anyone provide more details about where the lag would occur if I did
try to pursue a push to talk scenario with Icecast.  I'm not sure exactly
how it works now so I'll outline the two potential discussion flows I have
in mind.

Perhaps someone could elaborate on between which steps the 5-10 seconds of
lag would come into play.

Mumble does look like it might be a better fit for what I'm trying to do,
but I still am trying to get a rough understanding of the limitations of
the different options.


*Scenario 1*

   1. You record the message for 30 seconds (T0 to T30)
   2. They listen to your message (T30 to T60)
   3. They reply for 30 seconds (T60 to T90)
   4. You listen to their reply (T90 to T120).


*Scenario 2*

   1. You record the message for 30 seconds + they listen to your message
   (since it is streamed as soon as you speak, T0-T30)
   2. They reply for 30 seconds + you listen to their reply (same
   reasoning, T30-T60)


Thanks guys






*Orion Jensen*
CEO  | ClearLaunch
1408 East 13th Street | Austin, TX 78702
Skype: orion.jensen | Mobile: 1.512.270.3976
orionjensen at ClearLaunch.com <peyton at clearlaunch.com> | ClearLaunch.com
<http://t.sidekickopen09.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg64QWBnW3MPp-P64QZlKW7gbMDs56dTrtdrw25Y02?t=http%3A%2F%2Fwww.clearlaunch.com%2F&si=6552763575566336&pi=50aa7a1e-13c3-4b39-900f-aca4b1203a7e>



On Fri, Sep 18, 2015 at 5:32 PM, Marvin Scholz <epirat07 at gmail.com> wrote:

> On 18 Sep 2015, at 23:31, Orion Jensen wrote:
>
> > I'm investigating the build out of a Push to Talk server with multiple
> > subscribers as part of a mobile app.
>
> That most likely will not work with Icecast, you might want to check out
> alternatives. Icecast is a HTTP streaming server so there will be a
> quite noticeable "lag" of a few seconds (usually 5 to 10), which I guess
> is not desired for your usecase?
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150923/3cb0dcbb/attachment.htm>

From lion at lion.leolix.org  Thu Sep 24 09:40:56 2015
From: lion at lion.leolix.org (Philipp Schafft)
Date: Thu, 24 Sep 2015 09:40:56 +0000
Subject: [Icecast] Use case question
In-Reply-To: <CAO+4TYzveCNhHbuVrTP15i84egaqX-YeTAR2qj8bVW-+aPuGXw@mail.gmail.com>
References: <CAO+4TYydS_oVnOYOmyB-mcG=+q-Hh+UVJS=VRnWN0_4mPatM8Q@mail.gmail.com>
	<060EF53C-5B5A-4845-AEE4-AC3E7B0D02CF@gmail.com>
	<CAO+4TYzveCNhHbuVrTP15i84egaqX-YeTAR2qj8bVW-+aPuGXw@mail.gmail.com>
Message-ID: <20150924094128.037D5128F5@grassland.keep-cool.org>

Good morning,

On Wed, 2015-09-23 at 15:26 -0500, Orion Jensen wrote:
> Hi Guys,
> 
> 
> Can anyone provide more details about where the lag would occur if I
> did try to pursue a push to talk scenario with Icecast.  I'm not sure
> exactly how it works now so I'll outline the two potential discussion
> flows I have in mind.
> 
> 
> Perhaps someone could elaborate on between which steps the 5-10
> seconds of lag would come into play.
> 
> 
> Mumble does look like it might be a better fit for what I'm trying to
> do, but I still am trying to get a rough understanding of the
> limitations of the different options.

As this as well as similar questions are asked often let's take a little
bit of time to look into the difference and see why there is no
'universal' solution.

First have a look at a classical Icecast2 Setup:

[Signal Source] -*> [OS] -syscalls> [Encoder] -*> [libshout] -HTTP/TCP>
[Icecast2] -HTTP/TCP> [HTTP Engine] -*> [Player] -syscalls> [OS] -*>
[Signal Sink]

Connections marked '-*>' depend on the actual situation.

Here a [Signal Source] could be anything from a ADC (e.g. a sound/video
card) to a flat file. The signal source and the interface may have a
delay as well as a jitter. E.g. a soundcard may sample a given time span
and provide it as a block of data (RAM) to the OS. Also a file on a
harddisk does have this (as the disc is spinning at an finite speed it
needs time to read a block. jitter may e.g. be caused by seeking
(fragmentation or switching between files or just multiple access in
multi-tasking systems)). Depending on the Setup those times may be
within below one ms or well over a few hundred seconds.

The next part is the [OS]. The OS will also introduce delay and jitter.
E.g. it may change the buffers (such as by coping from IO space to
Userland space) and it may also be busy doing other tasks. Depending on
the OS and Hardware as well as configuration this may introduce delay
and jitter in the few-ms range.

The next block is the [Encoder]. It typically reads the data from the OS
via syscalls[0A]. For this little explanation we consider them to take
no time. The encoder introduces delay and jitter because of two reasons:
0) It will need CPU time to actually do the work. The time needed
   depends the data and
1) the used codec.
There are many codecs. Some target high quality and good compression and
therefore tend to have higher delay. Other target for less signal
quality and low delay. This is one of the main sources of delay and
jitter on the system. Codec specific encoding delay may be between a few
ms and many seconds. There is a nice chart on the delay of codecs
here[1].

Beside the codec there is another step within the encoder that
'amplifies' the codec specific delays and jitter: Muxing into the
container. The container is used to give meta information (such as:
which codec is used? What options are used? What time into the stream is
it?) and to add protection (Detection of transmission/storage errors).
Often several 'packets'[2A] from the encoder will be combined into
'frames'[2A] of the container before such a 'frame' is passed to the
next step. Thus also delay after this step may be a multiple of the
original delay of the encoder.

[libshout] is the reference implementation to send data to an Icecast2
server[3A]. It handles both the protocol (HTTP) as well as it takes care
of timing. libshout ensures that the stream is being send to the server
at the right speed. This helps to eliminate jitter from the
encoder/muxer and also allows streaming of files. To do so libshout has
a little buffer. This buffer is normally very small and should have
nearly no effect on the total delay if used correctly.

The next connection is a problem: the HTTP stream.
HTTP is a standard protocol as e.g. spoken by every web browser. It is
well developed and works fine for the tasks Icecast is made for. It adds
a little overhead at the start of the stream but that's about it.
However HTTP uses TCP as transport. TCP is a protocol that allows
continuous, ordered and protected streams of data. 'Raw' network is very
unreliable: packets may get lost or re-ordered or even duplicated. TCP
includes ways to eliminate this and allows us to use it as a smooth
stream of bytes without taking care of what is below. It also does this
very good[4A]. The problem is that to do this it needs... another buffer
and it may even go as far as re-requesting packets that have been lost.
So the performance of TCP highly depend on the physical link. It may add
a delay in the ms-range (e.g. local connections) to to several seconds
(just try a machine the other site of a uni campus) or even hundreds of
seconds (try a machine in a country with a bad connection to the world
wide backbone like St. Helena[6]).
This is another main source of latency. And it happens twice: to and
from Icecast2. See below.

Next we have [Icecast2] itself. Icecast2 does not really touch the data.
It just reads them off the source and distributes it to the listeners.
To do so it has a little buffer so it can deal with jitter on both ends.
As this buffer is a hybrid of fixed-bytes and fixed-time it's exact
parameters again depend on the used signal and encoder parameters. If
both the source and all clients write/read as expected the delay will
reduce nearly infinitely close to zero[5A].

Next we have the HTTP/TCP link between [Icecast2] and the [HTTP Engine].
This is about the same situation as above. The only real difference is
that from this point on each client has it's own path so it's own delay
and jitter. E.g. a close by (read: local) client may have close to no
extra delay and jitter from this point while a remote client (think
about St. Helena again) may have a significant delay jitter. So every
client may have another wall-clock time of arrival of a specific feature
of a stream[7].
Another interesting thing happens here: Up to [Icecast2] the source is
pushing data and the stream depends on the clock of the the source[8].
Icecast also tries to push the data to the client but that requires that
the client reads it as the TCP buffer is of limited size[10][11A].
The diagram for the influence of the clocks looks like this:
[Source Clock] -> [Icecast2]    ->  <- [Client Clock]
|Source Domain    | Icecast Domain |   Client Domain|


The next part is the [HTTP Engine]: It's basically the opposite of
[libshout] and also behaves very much the like. It usually holds a
little buffer to handle jitter on both ends and to provide a smooth
interface to the next part. If used correctly this adds close to zero
delay but helps with jitter.

The [Player] is the next part. It actually consists of several
components that are specific to and depending on what kind of software
is used. Normally it has a frontend buffer, a decoder and a backend
buffer. The frontend buffer is to eliminate most of the network and some
of the [Encoder] delay. Normally it's given in bytes. So again the delay
depend on the size and everything that is before that point (e.g. the
[Encoder] but also the actual network jitter).
The decoder the needs some CPU time to decode the signal.
Then the data is pushed to the backend buffer. The job of this buffer is
to provide a smooth stream to the [Signal Sink] as the decoder will work
in blocks (See 'packets' in [Encoder] details).

This is then passed using syscalls to the [Signal Sink] which behaves
exactly like the [Signal Source] in terms of delay and jitter.

So what have we got so far:
We got a streaming system that can handle bad links (mainly due to TCP
and the buffer in [Icecast2]) and can provide a bit perfect links in
those conditions and thus full quality. This happens at the expense of
delay.
What will the overall delay be like? Well, it depends on all those many
factors. On a typical Setup with first world networking between source,
[Icecast2] and sink you will end up with something <60s. There is
normally no problem of running at <30s. If you are in a very controlled
situation (like you control source, client and network as well as the
system [Icecast2] runs on) you may reach <3s. If you try that on 'the
wild internet' you will likely end up with some clients unable to
utilize your stream.


Ok, The good news: you are more than half thru my mail.

Now let's look at the typical VoIP Setup:

There is a wide range of different VoIP solutions. This is why I can
give only a rough explanation on how they work. It's not accurate and it
may be totally different for a specific solution. My intention here is
just to give you an rough idea on how that works to show the difference.

A typical VoIP Setup may look like this:
[Signal Source] -*> [OS] -syscalls> [Encoder] -*> [Protocol logic] -*>
[VoIP Network] -*> [Protocol logic] -*> [Decoder] -syscalls> [OS] -*>
[Signal Sink]

The following blocks are the same as above: [Signal Source], [Signal
Sink], [OS], [Encoder], [Decoder].

Also note that this is a unidirectional connection. VoIP applications
normally are bidirectional. So each client contains both source and the
sink components. They may interact with each other e.g. to optimize.
Here we keep it to the simple unidirectional case.

Ok, let's go from left to right again:

While the [Encoder] is the same as above there is some quantitative (not
qualitativ) difference: the selection of codecs and containers.
In a VoIP application no codecs and containers will be used that add
significant delay or jitter. Humans notice delay in a conversation very
early. A delay of only 20ms may be noticed. Over 200ms you will end up
with those calls you may know. They sound like two people constantly
asking 'Are you still on the line?'. So we need to limit the codecs top
those with only a few ms of delay.

The next step is the [Protocol logic] and the protocol used to
communicate with the [VoIP Network]. There is a wide range of protocols.
Typically those are implemented in a different ways than what we did
above with HTTP streaming. They split signalling and data apart.
Signalling is control traffic such as 'I want to call xyz.' or 'The
phone is ringing!'. The data traffic is send on it's own channel.
While the signalling needs some kind of reliability the data channel is
often used with nearly none. This means that if part of the signal is
lost on the network (packet lost) or is late or reaches the other site
multiple times it is ignored. This again requires a codec which can
handle holes in data.

What happens if data is lost? I'm sure you know that. It's a little
crackle or other distortion you can hear. As long as only a low number
of packets get lost there is no problem. Our speak contains more than
enough redundancy to compensate this.

What do we get for all this? We get a link that is very fast. The total
delay depends mostly on the distance between the two sites of the
communication. If you are lucky your link may be up to about c/3[12].
(If you want to reach a person on the other side of earth (20Mm) it will
take about 200ms for the packet to reach that point (This is the reason
why intercontinental calls are no fun).)

The next part is the [VoIP Network]:
This could be nothing to anything. Two such clients may communicate
directly or they may use several application layer routers (think:
proxy) to transport the signal from the source to the sink. Depending on
what is used here the delay and the jitter can vary in wide range.
Also note that if there are more than one such machines in between you
need to keep the distance and the link between them in mind as well.


So, what do we get in this Setup?
We get a much faster link. Normally well <1s. Even on intercontinental
connections we can easily reach <1s. Implementations are already close
to the limits of known laws of physic.
The price we need to pay for this is that we'll have a stream that may
not be of high quality and that it highly depends on the physical
position of all involved parties. It will of cause also depend on the
links and network quality (but there is no way around it anyway. How you
want to transmit a signal without a link between source and sink?).


Finally let's compare the two. I do it as a table to not stress you any
longer with my text:

What               | Icecast2               | VoIP
-------------------+------------------------+------------------------
Common delay       | <30s                   | <1s
-------------------+------------------------+------------------------
Bit perfection     | yes                    | no
Narrowband Audio   | yes                    | yes
Wideband Audio     | yes                    | maybe[13]
Superwideband Audio| yes                    | likely no[13]
-------------------+------------------------+------------------------
Handling of bad    | medium to good         | bad to good
 links             |                        |  depending on
                   |                        |  implementation.
Suitable for large | yes (>30000 per server)| no[15]
 number of clients |  [14]                  |
 per stream        |                        |
-------------------+------------------------+------------------------

Thank you for reading this long mail. I hope you got a pawful of useful
input. As I'm left out a lot and as I'm sure my texts is confusing in
some parts: Fell free to write and tell me your questions! (This is also
true for the readers of this email in the archive in many years. :)

And always keep in mind, the answer is 42!

Have a nice day.


Notes:
[1]   http://www.opus-codec.org/comparison/
[6]   A small island, part of the British Overseas Territory.
[7]   Most will have noticed that already: When there is a big sport
      event on TV some people in your street/block will shout 'Goal'
      earlier than others depending on if they are on analog/digital
     Terrestrial/Cable/Satellite.
[8]   E.g. the oscillator of the sound card or the RTC chip[9A] of the
      machine running libshout.
[10]  This is also why Icecast2 can detect clients not running fast
      enough.
[12]  speed of light/3 is about 99_930_819m/s.
[13]  This is slowly getting better. E.g. have a look at Opus in [1].
[14]  http://icecast.org/loadtest/
[15]  There are movements to implement it. Like WebRTC. 

Note for advanced readers:
[0A]  In case of memory mapped access consider traps 'indirect'
      syscalls.
[2A]  The terms used differ on used codec and container. I just tried to
      go with generic words.
[3A]  It also supports other protocols.
[4A]  normally...
[5A]  The main concern here is the OS of the server as well as the
      TCP connections.
[9A]  Or any other clock source provided by the OS.
[11A] I may write another one like this about clock desynchronization
      if there is interest.


-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150924/6b658369/attachment.sig>

From sm at noisynotes.com  Fri Sep 25 17:07:58 2015
From: sm at noisynotes.com (Steve Matzura)
Date: Fri, 25 Sep 2015 13:07:58 -0400
Subject: [Icecast] Icecast 2.4x Metadata doesn't clear if net file has
	none
In-Reply-To: <kt0nra11d0ques5tgc7kdatfi13ovsjr7l@4ax.com>
References: <kt0nra11d0ques5tgc7kdatfi13ovsjr7l@4ax.com>
Message-ID: <63qa0b9iojkqtn1uapmttsh13lmo1mu1nj@4ax.com>

Ya know, this happened to me as well, and I thought I was losing my
marbles!

On Fri, 31 Jul 2015 10:23:45 -0400, you wrote:

>I don't know if I have something set wrong in icecast.xml or not, but
>on my old server (version forgotten, installed 2009), if I streamed
>two files with the first one having metadata present but the second
>had none, Icecast wouldn't stream anything when the second file
>streamed. On my 4.21 server, when the second file streams, it shows
>metadata left over from the first file. I just finished looking
>through the documentation for 2.41 but cannot find any setting which
>controls this. Help appreciated. Meanwhile, of course I'll get the
>provider of the streamed file without any metadata to remedy that.
>_______________________________________________
>Icecast mailing list
>Icecast at xiph.org
>http://lists.xiph.org/mailman/listinfo/icecast


From mh747 at outlook.com  Tue Sep 29 21:13:01 2015
From: mh747 at outlook.com (M M)
Date: Tue, 29 Sep 2015 14:13:01 -0700
Subject: [Icecast] Delay playing some streams on Android
Message-ID: <BLU179-W41570B1E1613FA110D9298ED4E0@phx.gbl>


I'm writing an Android app to play streams. ?I use the standard Android "MediaPlayer" library to play streams. ?I've noticed that some streams start playing without much delay (MPR), but others take quite a while to start (WFMU). ?The only thing changing in my code is the URI of the Icecast mountpoint. ?My test device is a Nexus 5 running Android 5.1.1.

http://current.stream.publicradio.org/kcmp.mp3?starts playing in about 2 seconds. ?It's a 128 kbps stream from Minnesota Public Radio.

http://stream0.wfmu.org/freeform-128k?starts playing in about 9 seconds. ?It's a 128 kbps stream from WFMU.

The problem gets worse as the bitrate goes down. ?32 kbps streams take quite a while to start.

I don't notice this problem in iOS code I've written. ?I also don't notice it in VLC.

You can view the headers with:

curl -s -D - http://current.stream.publicradio.org/kcmp.mp3 -o /dev/null

StackOverflow has several posts about this. ?For example:?http://stackoverflow.com/questions/6582908/why-does-it-take-so-long-for-androids-mediaplayer-to-prepare-some-live-streams.

Any idea what's going on?


 		 	   		  

From purchasing.05 at multiparadigm.com  Tue Sep 29 21:25:46 2015
From: purchasing.05 at multiparadigm.com (MultiParadigm Corp.)
Date: Tue, 29 Sep 2015 14:25:46 -0700
Subject: [Icecast] Delay playing some streams on Android
Message-ID: <20150929142546.0e377ce7397666338d3aeed6efde40f2.ee2e8a92d9.wbe@email12.secureserver.net>

An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150929/b827191e/attachment.htm>

From mh747 at outlook.com  Tue Sep 29 21:31:26 2015
From: mh747 at outlook.com (M M)
Date: Tue, 29 Sep 2015 14:31:26 -0700
Subject: [Icecast] Delay playing some streams on Android
In-Reply-To: <BLU179-W41570B1E1613FA110D9298ED4E0@phx.gbl>
References: <BLU179-W41570B1E1613FA110D9298ED4E0@phx.gbl>
Message-ID: <BLU179-W22EB19EC8CF640A8B76207ED4E0@phx.gbl>


More data: the delay happens on a real Nexus 5, but not in a Nexus 5 emulator. ?No delays in the emulator.



----------------------------------------
> From: mh747 at outlook.com
> To: icecast at xiph.org
> Date: Tue, 29 Sep 2015 14:13:01 -0700
> Subject: [Icecast] Delay playing some streams on Android
>
>
> I'm writing an Android app to play streams. I use the standard Android "MediaPlayer" library to play streams. I've noticed that some streams start playing without much delay (MPR), but others take quite a while to start (WFMU). The only thing changing in my code is the URI of the Icecast mountpoint. My test device is a Nexus 5 running Android 5.1.1.
>
> http://current.stream.publicradio.org/kcmp.mp3 starts playing in about 2 seconds. It's a 128 kbps stream from Minnesota Public Radio.
>
> http://stream0.wfmu.org/freeform-128k starts playing in about 9 seconds. It's a 128 kbps stream from WFMU.
>
> The problem gets worse as the bitrate goes down. 32 kbps streams take quite a while to start.
>
> I don't notice this problem in iOS code I've written. I also don't notice it in VLC.
>
> You can view the headers with:
>
> curl -s -D - http://current.stream.publicradio.org/kcmp.mp3 -o /dev/null
>
> StackOverflow has several posts about this. For example: http://stackoverflow.com/questions/6582908/why-does-it-take-so-long-for-androids-mediaplayer-to-prepare-some-live-streams.
>
> Any idea what's going on?
>
>
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
 		 	   		  

From sm at noisynotes.com  Wed Sep 30 16:54:28 2015
From: sm at noisynotes.com (Steve Matzura)
Date: Wed, 30 Sep 2015 12:54:28 -0400
Subject: [Icecast] Replacement for Lidquidsoap
Message-ID: <6s4o0bdlr9mvmmiab9glopjstf8nhnk9no@4ax.com>

Can anyone recommend any program newer than the last release of
Liquidsoap, which, unless I misread the page, was in 2007?


From erm13martinez at gmail.com  Wed Sep 30 17:20:59 2015
From: erm13martinez at gmail.com (Eduardo Martinez)
Date: Wed, 30 Sep 2015 10:20:59 -0700
Subject: [Icecast] Replacement for Lidquidsoap
In-Reply-To: <6s4o0bdlr9mvmmiab9glopjstf8nhnk9no@4ax.com>
References: <6s4o0bdlr9mvmmiab9glopjstf8nhnk9no@4ax.com>
Message-ID: <CAJ8tkjjCz-o==OCfhrVSRVQVhTCuOfm3niTnERr-GNwSQZVgTQ@mail.gmail.com>

Steve,

The latest release of liquidsoap (1.1.1) was released on 2013-05-08.

http://sourceforge.net/projects/savonet/files/liquidsoap/1.1.1/liquidsoap-1.1.1-full.tar.gz/download


On Wed, Sep 30, 2015 at 9:54 AM, Steve Matzura <sm at noisynotes.com> wrote:

> Can anyone recommend any program newer than the last release of
> Liquidsoap, which, unless I misread the page, was in 2007?
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150930/7ce7eaa3/attachment.htm>

From dv.sorokins at googlemail.com  Wed Sep 30 18:56:47 2015
From: dv.sorokins at googlemail.com (Dmitrijs Sorokins)
Date: Wed, 30 Sep 2015 21:56:47 +0300
Subject: [Icecast] Replacement for Lidquidsoap
In-Reply-To: <6s4o0bdlr9mvmmiab9glopjstf8nhnk9no@4ax.com>
References: <6s4o0bdlr9mvmmiab9glopjstf8nhnk9no@4ax.com>
Message-ID: <560C306F.80400@gmail.com>

perhaps ices?
http://icecast.org/ices/

30.09.2015 19:54, Steve Matzura ?????:
> Can anyone recommend any program newer than the last release of
> Liquidsoap, which, unless I misread the page, was in 2007?
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast



From mh747 at outlook.com  Wed Sep 30 20:01:01 2015
From: mh747 at outlook.com (M M)
Date: Wed, 30 Sep 2015 13:01:01 -0700
Subject: [Icecast] Delay playing some streams on Android
In-Reply-To: <20150929142546.0e377ce7397666338d3aeed6efde40f2.ee2e8a92d9.wbe@email12.secureserver.net>
References: <20150929142546.0e377ce7397666338d3aeed6efde40f2.ee2e8a92d9.wbe@email12.secureserver.net>
Message-ID: <BLU179-W207A3F177B341E0154D444ED4D0@phx.gbl>


I suppose you were pointing me towards the "burst-size" setting, but it's not totally clear.  Please correct me if you meant something else.
I increased the burst-size to 131072 bytes, or 128 kibibytes.  My Android app now plays the stream without much delay.  I still don't know why I didn't notice this problem in an Android emulator.
Thanks for the pointer.


From: purchasing.05 at multiparadigm.com
To: icecast at xiph.org
Date: Tue, 29 Sep 2015 14:25:46 -0700
Subject: Re: [Icecast] Delay playing some streams on Android

The built in player (StageFright) uses a large buffer.  If the Icecast mount also uses a large  buffer, the buffer in the player can be filled quickly (on a fast connection), otherwise not.




-------- Original Message --------

Subject: [Icecast] Delay playing some streams on Android

From: M M <mh747 at outlook.com>

Date: Tue, September 29, 2015 4:13 pm

To: "icecast at xiph.org" <icecast at xiph.org>





I'm writing an Android app to play streams.  I use the standard Android "MediaPlayer" library to play streams.  I've noticed that some streams start playing without much delay (MPR), but others take quite a while to start (WFMU).  The only thing changing in my code is the URI of the Icecast mountpoint.  My test device is a Nexus 5 running Android 5.1.1.



http://current.stream.publicradio.org/kcmp.mp3 starts playing in about 2 seconds.  It's a 128 kbps stream from Minnesota Public Radio.



http://stream0.wfmu.org/freeform-128k starts playing in about 9 seconds.  It's a 128 kbps stream from WFMU.



The problem gets worse as the bitrate goes down.  32 kbps streams take quite a while to start.



I don't notice this problem in iOS code I've written.  I also don't notice it in VLC.



You can view the headers with:



curl -s -D - http://current.stream.publicradio.org/kcmp.mp3 -o /dev/null



StackOverflow has several posts about this.  For example: http://stackoverflow.com/questions/6582908/why-does-it-take-so-long-for-androids-mediaplayer-to-prepare-some-live-streams.



Any idea what's going on?





 		 	   		  

_______________________________________________

Icecast mailing list

Icecast at xiph.org

http://lists.xiph.org/mailman/listinfo/icecast





_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150930/4d30793f/attachment.htm>

From purchasing.05 at multiparadigm.com  Wed Sep 30 20:56:14 2015
From: purchasing.05 at multiparadigm.com (MultiParadigm Corp.)
Date: Wed, 30 Sep 2015 13:56:14 -0700
Subject: [Icecast] Delay playing some streams on Android
In-Reply-To: <BLU179-W207A3F177B341E0154D444ED4D0@phx.gbl>
Message-ID: <20150930135614.0e377ce7397666338d3aeed6efde40f2.ff8eef7670.mailapi@email12.secureserver.net>

I didn't have time to look in an actual config file for the name (burst-size), but you figured it out!
 
StageFright is frustrating and has a history of nasty bugs.  You discovered one of its irritating limitations.
 
I think most good stream players avoid it.   
 
Miles Whitener
MultiParadigm Corporation
--------- Original Message --------- Subject: Re: [Icecast] Delay playing some streams on Android
From: "M M" <mh747 at outlook.com>
Date: 9/30/15 3:01 pm
To: "Icecast streaming server user discussions" <icecast at xiph.org>

   
I suppose you were pointing me towards the "burst-size" setting, but it's not totally clear.  Please correct me if you meant something else.
 
I increased the burst-size to 131072 bytes, or 128 kibibytes.  My Android app now plays the stream without much delay.  I still don't know why I didn't notice this problem in an Android emulator.
 
Thanks for the pointer.
 


 From: purchasing.05 at multiparadigm.com
To: icecast at xiph.org
Date: Tue, 29 Sep 2015 14:25:46 -0700
Subject: Re: [Icecast] Delay playing some streams on Android

 The built in player (StageFright) uses a large buffer.  If the Icecast mount also uses a large  buffer, the buffer in the player can be filled quickly (on a fast connection), otherwise not.


 -------- Original Message --------
 Subject: [Icecast] Delay playing some streams on Android
 From: M M <mh747 at outlook.com>
 Date: Tue, September 29, 2015 4:13 pm
 To: "icecast at xiph.org" <icecast at xiph.org>
 
 
 I'm writing an Android app to play streams.  I use the standard Android "MediaPlayer" library to play streams.  I've noticed that some streams start playing without much delay (MPR), but others take quite a while to start (WFMU).  The only thing changing in my code is the URI of the Icecast mountpoint.  My test device is a Nexus 5 running Android 5.1.1.
 
 http://current.stream.publicradio.org/kcmp.mp3 starts playing in about 2 seconds.  It's a 128 kbps stream from Minnesota Public Radio.
 
 http://stream0.wfmu.org/freeform-128k starts playing in about 9 seconds.  It's a 128 kbps stream from WFMU.
 
 The problem gets worse as the bitrate goes down.  32 kbps streams take quite a while to start.
 
 I don't notice this problem in iOS code I've written.  I also don't notice it in VLC.
 
 You can view the headers with:
 
 curl -s -D - http://current.stream.publicradio.org/kcmp.mp3 -o /dev/null
 
 StackOverflow has several posts about this.  For example: http://stackoverflow.com/questions/6582908/why-does-it-take-so-long-for-androids-mediaplayer-to-prepare-some-live-streams.
 
 Any idea what's going on?
 
 
 
 _______________________________________________
 Icecast mailing list
 Icecast at xiph.org
 http://lists.xiph.org/mailman/listinfo/icecast
 
_______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast

_______________________________________________ Icecast mailing list Icecast at xiph.org http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20150930/9afe0b06/attachment.htm>