From ohnonot-github at posteo.de  Sun Jun  5 06:33:34 2022
From: ohnonot-github at posteo.de (D.T.)
Date: Sun, 05 Jun 2022 06:33:34 +0000
Subject: [Icecast] only a few listeners - reduce resource usage?
In-Reply-To: <fde8358c7a9007ce8f49abc86b2bd8c8f6c3de57.camel@de.loewenfelsen.net>
References: <3f7f867267cc8cdb13c3a3b6b5dd4945000f9640.camel@posteo.de>
 <fde8358c7a9007ce8f49abc86b2bd8c8f6c3de57.camel@de.loewenfelsen.net>
Message-ID: <eaa9d57cf77d356f724c2d28cae9ccc745a9caef.camel@posteo.de>

Hello, thank you for your timely reply!

It took me a while to get into it.

Additional challenges came up: I realised that most of my music
collection is MP3, and I can save some quality/processing when I stream
MP3 instead of OGG/Vorbis.
I think I have that part under control now, but I mention it for
context. It also means that I cannot use ogg-based source clients -
even Debian's libshout3 does not support MP3 - I use ffmpeg for
everything currently. This works OK so far:

1. Looping through music collection, ffmpeg transcodes and pipes or
just pipes music to stdout

?|
?V

2. The result is caught (-i pipe:) by a continuous ffmpeg process that
is an icecast client

?|
?V

3. Icecast2 => World

________________

Now, about the on-demand relaying.

First, I want to make sure about the terminology:

- The master is the one connected to the icecast clients that actually
produce the music
- The slave is public-facing and relays web requests for mountpoints to
the master

So what is currently point 3. would become the master, which then
relays to

4. Icecas2 (slave) => world

Correct?

Since I want on-demand streaming for all my streams I decided on the
global <master-server> configuration.

But this means I need to start 2 separate icecast daemons with
different configurations, yes?
The provided init script (Debian package) clearly does not have such a
scenario in mind, and things could quickly get messy.

Or am I missing something obvious here?

Cheers,

D.T.


On Thu, 2022-04-07 at 07:18 +0000, Philipp Schafft wrote:
> Good morning,
> 
> On Wed, 2022-04-06 at 06:37 +0000, D.T. wrote:
> > Hello,
> > I have made myself a radio station that just shuffles my music
> > collection, transcodes it to ogg/vorbis and streams that over
> > icecast.
> > It's a simple shell script utilixing ffmpeg and oggfwd, on a
> > headless
> > Debian server.
> > Due to copyright issues I cannot make it public (I guess), so I'll
> > often have no listeners at all, and usually just myself.
> > But the script is still chugging along, transcoding music to
> > nowhere.
> > 
> > Now I understand that the buffer has to be full when a listener
> > connects. And I also understand that the unique character of a
> > radio
> > station would be lost if the playlist actually stops when nobody is
> > listening.
> > 
> > Even so, is it possible to avoid this waste of resources while
> > still
> > having my very own radio station?
> 
> Actually, yes and a bit of no:
> 
> You can do that with on-demand relays. They are exactly what you ask
> for:
> With on-demand relays the source is connected when at least one
> listener is connected and is disconnected in times of idle.
> 
> So from an Icecast point of view this is totally possible.
> 
> However I have not yet seen any out-of-the-box sourceclient for that.
> But if you are already on the scripting level of things that could be
> an option for you.
> 
> Overview on how it works:
> Basically when data is required Icecast will do a HTTP GET request to
> a
> URL you provided. It expects a source of data there. Keep in mind
> that
> this source needs to provide data at the correct speed.
> 
> And that's all there is to it already. :)
> 
> 
> > Cheers,
> > 
> > D.T.
> > 
> > PS: thanks for yet another glorious FOSS application!!!
> 
> Thank you for your kind words. :)
> 
> 
> With best regards,
> 
> 
> PS: Feel free to use "shout" from libshout as a little bit more
> modern
> replacement to "oggfwd". :)
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

___

Vaccines for everyone!
Donate to the COVAX alliance:
https://gogiveone.org/?(WHO)
https://www.gavi.org/donate?(Gavi)

___

Vaccines for everyone!
Donate to the COVAX alliance:
https://gogiveone.org/ (WHO)
https://www.gavi.org/donate (Gavi)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220605/e67192cd/attachment.sig>

From robinstl68 at icloud.com  Mon Jun  6 13:45:55 2022
From: robinstl68 at icloud.com (Robert Winkelmann)
Date: Mon, 6 Jun 2022 08:45:55 -0500
Subject: [Icecast] Privileged Ports IC 2.5
Message-ID: <d00b84d8-ad67-ef50-7afd-f1289b1efb89@icloud.com>

Currently I am using the Ubuntu apt package for my production Icecast 
servers and have the setup for accessing the secure ports via settings 
in both the Icecast file and the startup files that handle that.

As I am testing the 2.5 using the download make/build system I do have 
the server up, SSL working on ports but not sure what people are doing 
to allow the privileged port access as for now I am starting it manually 
from command line. I have not tried it yet but assume that I can copy 
the current startup script, change the file locations to the beta files 
and run that but was curious what others are doing in testing to be able 
to open Port 80 for SSL.



From phschafft at de.loewenfelsen.net  Thu Jun 23 11:07:43 2022
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Thu, 23 Jun 2022 11:07:43 +0000
Subject: [Icecast] Presentation on low latency audio streaming in mobile
 networks
Message-ID: <c26457f6b8d9637a1874cf5a7f8caaee4b285a9a.camel@de.loewenfelsen.net>

Good afternoon,

again we have *one* seat left for tomorrow's presentation: On low
latency audio streaming in mobile networks.

The presentation will be at 15:00 UTC on our Jitsi.

If anyone is interested feel free to write me off-list.

All the details over here:
https://www.linkedin.com/events/onlowlatencyaudiostreaminginmob6944928558788042753/about/


With best regards,

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon:  +49.3535 490 17 92
Website:   https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220623/64e828cd/attachment.sig>

From db76 at riseup.net  Sun Jun 26 04:41:04 2022
From: db76 at riseup.net (Damian)
Date: Sun, 26 Jun 2022 14:41:04 +1000
Subject: [Icecast] HTTPS stream URL on https://dir.xiph.org
In-Reply-To: <60B8A40E-4BD6-44FC-9D4E-B79DE74A7891@riseup.net>
References: <60B8A40E-4BD6-44FC-9D4E-B79DE74A7891@riseup.net>
Message-ID: <3DBFFC31-FBA7-47A6-B27D-D563760716FD@riseup.net>

Hi,

I was hoping to get a response to my post in May but perhaps it is an issue that has already been discussed in a previous thread. If so, could someone please point me to it?

The main question I have is whether it is possible to specify a https listen URL that would be used on the xiph stream directory. My understanding is that google Chrome no longer supports unencrypted streams so it seems to make sense that the stream links on the xiph directory be https instead of http only.

Damian



> On 30 May 2022, at 18:01AEST, Damian <db76 at riseup.net> wrote:
> 
> Dear Icecast community,
> 
> I have a question about the (beta) Icecast Directory of streams at https://dir.xiph.org/. My question concerns the blue ?Play? button that appears to the right of each stream. I have noticed that the stream URLs for all the streams listed in this directory are http instead of https URLS. I have an SSL compiled version of Icecast. I?d like to know if it is possible (in version 2.4.4) to configure Icecast to display the  HTTPS stream URL. I haven?t yet experimented with version 2.5 to see if this feature exists. 
> 
> Any info on this would be helpful.
> 
> Damian
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast



From epirat07 at gmail.com  Sun Jun 26 10:12:19 2022
From: epirat07 at gmail.com (Marvin Scholz (ePirat))
Date: Sun, 26 Jun 2022 12:12:19 +0200
Subject: [Icecast] HTTPS stream URL on https://dir.xiph.org
In-Reply-To: <3DBFFC31-FBA7-47A6-B27D-D563760716FD@riseup.net>
References: <3DBFFC31-FBA7-47A6-B27D-D563760716FD@riseup.net>
Message-ID: <E10E1EF6-41B5-4F9F-8AB9-4440555EEA21@gmail.com>



> On 26. Jun 2022, at 06:41, Damian <db76 at riseup.net> wrote:
> 
> ?Hi,
> 
> I was hoping to get a response to my post in May but perhaps it is an issue that has already been discussed in a previous thread. If so, could someone please point me to it?
> 
> The main question I have is whether it is possible to specify a https listen URL that would be used on the xiph stream directory. My understanding is that google Chrome no longer supports unencrypted streams so it seems to make sense that the stream links on the xiph directory be https instead of http only.
> 
> Damian
> 
> 

Hi,
this is unfortunately not possible currently with Icecast 2.4 and it is a known issue that will be resolved in the 2.5 release.

> 
>> On 30 May 2022, at 18:01AEST, Damian <db76 at riseup.net> wrote:
>> 
>> Dear Icecast community,
>> 
>> I have a question about the (beta) Icecast Directory of streams at https://dir.xiph.org/. My question concerns the blue ?Play? button that appears to the right of each stream. I have noticed that the stream URLs for all the streams listed in this directory are http instead of https URLS. I have an SSL compiled version of Icecast. I?d like to know if it is possible (in version 2.4.4) to configure Icecast to display the  HTTPS stream URL. I haven?t yet experimented with version 2.5 to see if this feature exists. 
>> 
>> Any info on this would be helpful.
>> 
>> Damian
>> _______________________________________________
>> 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


From mwpmorris at gmail.com  Sun Jun 26 14:10:46 2022
From: mwpmorris at gmail.com (Matt Morris)
Date: Sun, 26 Jun 2022 15:10:46 +0100
Subject: [Icecast] Presentation on low latency audio streaming in mobile
 networks
In-Reply-To: <c26457f6b8d9637a1874cf5a7f8caaee4b285a9a.camel@de.loewenfelsen.net>
References: <c26457f6b8d9637a1874cf5a7f8caaee4b285a9a.camel@de.loewenfelsen.net>
Message-ID: <371FE591-0C4F-45BC-83C1-CDD7C1F41A26@gmail.com>

Hi,

Is there any chance of having these presentations hosted somewhere for non-live viewing? I have seen a few that I would find very useful but work in the field most weeks so am unable to attend any ?live? events.

Many thanks, Matt Morris. 

Sent from my iPhone

> On 23 Jun 2022, at 12:07, Philipp Schafft <phschafft at de.loewenfelsen.net> wrote:
> 
> ?Good afternoon,
> 
> again we have *one* seat left for tomorrow's presentation: On low
> latency audio streaming in mobile networks.
> 
> The presentation will be at 15:00 UTC on our Jitsi.
> 
> If anyone is interested feel free to write me off-list.
> 
> All the details over here:
> https://www.linkedin.com/events/onlowlatencyaudiostreaminginmob6944928558788042753/about/
> 
> 
> With best regards,
> 
> -- 
> Philipp Schafft (CEO/Gesch?ftsf?hrer) 
> Telephon:  +49.3535 490 17 92
> Website:   https://www.loewenfelsen.net/
> Follow us: https://www.linkedin.com/company/loewenfelsen/
> 
> L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
> Bickinger Stra?e 21                     HRB 12308 CB
> 04916 Herzberg (Elster)                 VATIN/USt-ID:
> Germany                                 DE305133015
> _______________________________________________
> 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/octet-stream
Size: 228 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220626/3588879e/attachment.obj>

From dave.mehler at gmail.com  Sun Jun 26 15:12:32 2022
From: dave.mehler at gmail.com (David Mehler)
Date: Sun, 26 Jun 2022 11:12:32 -0400
Subject: [Icecast] Presentation on low latency audio streaming in mobile
 networks
In-Reply-To: <371FE591-0C4F-45BC-83C1-CDD7C1F41A26@gmail.com>
References: <c26457f6b8d9637a1874cf5a7f8caaee4b285a9a.camel@de.loewenfelsen.net>
 <371FE591-0C4F-45BC-83C1-CDD7C1F41A26@gmail.com>
Message-ID: <CAPORhP6vxWvEaROSsXZGfae7yLxj6bpyKLVqPQdO2gnSeUwPGg@mail.gmail.com>

Hello,

I would second this, my schedule is such that I can rarely attend presentations.

Thanks.
Dave.


On 6/26/22, Matt Morris <mwpmorris at gmail.com> wrote:
> Hi,
>
> Is there any chance of having these presentations hosted somewhere for
> non-live viewing? I have seen a few that I would find very useful but work
> in the field most weeks so am unable to attend any ?live? events.
>
> Many thanks, Matt Morris.
>
> Sent from my iPhone
>
>> On 23 Jun 2022, at 12:07, Philipp Schafft <phschafft at de.loewenfelsen.net>
>> wrote:
>>
>> ?Good afternoon,
>>
>> again we have *one* seat left for tomorrow's presentation: On low
>> latency audio streaming in mobile networks.
>>
>> The presentation will be at 15:00 UTC on our Jitsi.
>>
>> If anyone is interested feel free to write me off-list.
>>
>> All the details over here:
>> https://www.linkedin.com/events/onlowlatencyaudiostreaminginmob6944928558788042753/about/
>>
>>
>> With best regards,
>>
>> --
>> Philipp Schafft (CEO/Gesch?ftsf?hrer)
>> Telephon:  +49.3535 490 17 92
>> Website:   https://www.loewenfelsen.net/
>> Follow us: https://www.linkedin.com/company/loewenfelsen/
>>
>> L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
>> Bickinger Stra?e 21                     HRB 12308 CB
>> 04916 Herzberg (Elster)                 VATIN/USt-ID:
>> Germany                                 DE305133015
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>


From marius at flage.org  Sun Jun 26 15:50:08 2022
From: marius at flage.org (Marius Flage)
Date: Sun, 26 Jun 2022 17:50:08 +0200
Subject: [Icecast] Presentation on low latency audio streaming in mobile
 networks
In-Reply-To: <CAPORhP6vxWvEaROSsXZGfae7yLxj6bpyKLVqPQdO2gnSeUwPGg@mail.gmail.com>
Message-ID: <20220626155011.986BC32204B@hobbiton.radiomeloy.no>

Thirded :)--MariusSendt fra min Galaxy
-------- Opprinnelig melding --------Fra: David Mehler <dave.mehler at gmail.com> Dato: 26.06.2022  17:12  (GMT+01:00) Til: Icecast streaming server user discussions <icecast at xiph.org> Emne: Re: [Icecast] Presentation on low latency audio streaming in mobile
  networks Hello,I would second this, my schedule is such that I can rarely attend presentations.Thanks.Dave.On 6/26/22, Matt Morris <mwpmorris at gmail.com> wrote:> Hi,>> Is there any chance of having these presentations hosted somewhere for> non-live viewing? I have seen a few that I would find very useful but work> in the field most weeks so am unable to attend any ?live? events.>> Many thanks, Matt Morris.>> Sent from my iPhone>>> On 23 Jun 2022, at 12:07, Philipp Schafft <phschafft at de.loewenfelsen.net>>> wrote:>>>> ?Good afternoon,>>>> again we have *one* seat left for tomorrow's presentation: On low>> latency audio streaming in mobile networks.>>>> The presentation will be at 15:00 UTC on our Jitsi.>>>> If anyone is interested feel free to write me off-list.>>>> All the details over here:>> https://www.linkedin.com/events/onlowlatencyaudiostreaminginmob6944928558788042753/about/>>>>>> With best regards,>>>> -->> Philipp Schafft (CEO/Gesch?ftsf?hrer)>> Telephon:? +49.3535 490 17 92>> Website:?? https://www.loewenfelsen.net/>> Follow us: https://www.linkedin.com/company/loewenfelsen/>>>> L?wenfelsen UG (haftungsbeschr?nkt)???? Registration number:>> Bickinger Stra?e 21???????????????????? HRB 12308 CB>> 04916 Herzberg (Elster)???????????????? VATIN/USt-ID:>> Germany???????????????????????????????? DE305133015>> _______________________________________________>> Icecast mailing list>> Icecast at xiph.org>> http://lists.xiph.org/mailman/listinfo/icecast>_______________________________________________Icecast mailing listIcecast at xiph.orghttp://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220626/849664ee/attachment.htm>

From fredg at paravelsystems.com  Sun Jun 26 16:58:07 2022
From: fredg at paravelsystems.com (Fred Gleason)
Date: Sun, 26 Jun 2022 12:58:07 -0400
Subject: [Icecast] Presentation on low latency audio streaming in mobile
 networks
In-Reply-To: <371FE591-0C4F-45BC-83C1-CDD7C1F41A26@gmail.com>
References: <c26457f6b8d9637a1874cf5a7f8caaee4b285a9a.camel@de.loewenfelsen.net>
 <371FE591-0C4F-45BC-83C1-CDD7C1F41A26@gmail.com>
Message-ID: <29D136D1-330D-418D-9295-A5BE97915B9D@paravelsystems.com>

On Jun 26, 2022, at 10:10, Matt Morris <mwpmorris at gmail.com> wrote:

> Is there any chance of having these presentations hosted somewhere for non-live viewing? I have seen a few that I would find very useful but work in the field most weeks so am unable to attend any ?live? events.

++

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|         A room without books is like a body without a soul.         |
|                                                                     |
|                                                         -- Cicero   |
|---------------------------------------------------------------------|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220626/dedba275/attachment.htm>

From phschafft at de.loewenfelsen.net  Sun Jun 26 17:30:07 2022
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Sun, 26 Jun 2022 17:30:07 +0000
Subject: [Icecast] Presentation on low latency audio streaming in mobile
 networks
In-Reply-To: <371FE591-0C4F-45BC-83C1-CDD7C1F41A26@gmail.com>
References: <c26457f6b8d9637a1874cf5a7f8caaee4b285a9a.camel@de.loewenfelsen.net>
 <371FE591-0C4F-45BC-83C1-CDD7C1F41A26@gmail.com>
Message-ID: <521570f54818590de9cc05b4dc6842f1a6b347ed.camel@de.loewenfelsen.net>

Good afternoon,

On Sun, 2022-06-26 at 15:10 +0100, Matt Morris wrote:
> Hi,
> 
> Is there any chance of having these presentations hosted somewhere
> for non-live viewing?

we sadly can not do this as they are meant to be interactive. To allow
everyone to speak openly recordings are a no-go.


> I have seen a few that I would find very useful but work in the field
> most weeks so am unable to attend any ?live? events.

There are a few options here. But first please understand that the
presentations are *not* by the Icecast Team. They are by L?wenfelsen
meant for our business partners. This is also also why I announce them
on here so late: I'm only announcing if there are virtual seats left.
The primary platform we announce them on is LinkedIn.

So what are the options then?
 * We're repeating presentations of most interest. So if you write
   (off-list) what you are interested in (both repeats but also new
   topics) your voice is heard. :)
 * Time of day for the presentations is relatively flexible as long as
   it is within our business hours. But naturally cannot be changed
   once a presentation is announced. But feedback for upcoming
   presentations is very welcome.
 * We're totally happy to write you a confirmation of participation for
   your company in case that helps. (And before you say "no": have you
   actually asked your boss?)
 * If there is specific interest we can arrange a presentation for your
   group/company. Made specifically for you. But business terms apply
   such as being within business hours.

Also feel free to write all requests and feedback directly to:
support at loewenfelsen.net

Hope that clarifies the situation a bit.


With best regards,


> On 23 Jun 2022, at 12:07, Philipp Schafft <
> > phschafft at de.loewenfelsen.net> wrote:
> > 
> > ?Good afternoon,
> > 
> > again we have *one* seat left for tomorrow's presentation: On low
> > latency audio streaming in mobile networks.
> > 
> > The presentation will be at 15:00 UTC on our Jitsi.
> > 
> > If anyone is interested feel free to write me off-list.
> > 
> > All the details over here:
> > https://www.linkedin.com/events/onlowlatencyaudiostreaminginmob6944928558788042753/about/

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon:  +49.3535 490 17 92
Website:   https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220626/8f26fb21/attachment.sig>

From dik23 at hotmail.com  Mon Jun 27 21:34:51 2022
From: dik23 at hotmail.com (Dik ....)
Date: Mon, 27 Jun 2022 21:34:51 +0000
Subject: [Icecast] Reinstall changes icecast.xml
Message-ID: <LOYP123MB31849B6B8B530F94E1ED021EA8B99@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>

Ubuntu 20.04.4
Icecast 2.4.4-3ubuntu0.1

    <authentication>
        <!-- Sources log in with username 'source' -->
        <source-password>PASSWORD-A</source-password>

        <!-- Relays log in with username 'relay' -->
        <relay-password>PASSWORD-B</relay-password>

        <!-- Admin logs in with the username given below -->
        <admin-user>username</admin-user>
        <admin-password>PASSWORD-C</admin-password>
    </authentication>

Then I do apt remove icecast2 and apt install icecast2.... The icecast.xml stays the same apart from:

    <authentication>
        <!-- Sources log in with username 'source' -->
        <source-password>PASSWORD-D</source-password>

        <!-- Relays log in with username 'relay' -->
        <relay-password>PASSWORD-D</relay-password>

        <!-- Admin logs in with the username given below -->
        <admin-user>username</admin-user>
        <admin-password>PASSWORD-D</admin-password>
    </authentication>

Are these passwords supposed to change on reinstall?  Where is it getting PASSWORD-D from, it's nowhere else in icecast.xml??

I noticed this when I updated from 18.04 to 20.04, which meant that icecast didn't work as expected after the update, but the same happens with uninstall / reinstall on 20.04.

This is unhelpful when updating


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

From phschafft at de.loewenfelsen.net  Tue Jun 28 12:41:39 2022
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Tue, 28 Jun 2022 12:41:39 +0000
Subject: [Icecast] Reinstall changes icecast.xml
In-Reply-To: <LOYP123MB31849B6B8B530F94E1ED021EA8B99@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
References: <LOYP123MB31849B6B8B530F94E1ED021EA8B99@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <0e21bf925dfe03b8f650384940da3b5d0faade7b.camel@de.loewenfelsen.net>

Good morning,

On Mon, 2022-06-27 at 21:34 +0000, Dik .... wrote:
> Ubuntu 20.04.4
> Icecast 2.4.4-3ubuntu0.1
> [...]
> Then I do apt remove icecast2 and apt install icecast2.... The
> icecast.xml stays the same apart from:
> 
>     [...]
> Are these passwords supposed to change on reinstall?  Where is it
> getting PASSWORD-D from, it's nowhere else in icecast.xml??
> 
> I noticed this when I updated from 18.04 to 20.04, which meant that
> icecast didn't work as expected after the update, but the same
> happens with uninstall / reinstall on 20.04.
> 
> This is unhelpful when updating

this doesn't look like it is about upstream Icecast but the Ubuntu
package. Therefore best addressed at the Ubuntu bug tracker.

However: There are some Debian based packages out there that manage the
password as part of the package configuration. My best guess here is
re-installing triggered the package manager to sync it's stored
password back into the config file. If that is the case maybe it is
best to manage the password within the package manager?

Over here at Debian that is debconf. And it asks me on install if I
want to have Icecast managed by it. If I select the managed mode I get:
   $ debconf-show icecast2
   * icecast2/icecast-setup: true
   * icecast2/hostname: localhost
   * icecast2/adminpassword: hackme
   * icecast2/sourcepassword: hackme
   * icecast2/relaypassword: hackme

So maybe you can also just disable that by setting icecast2/icecast-
setup to false? But again, I would like to refer you to the Ubuntu
package maintainer/bug tracker here as all the above is guesswork based
on how things are on Debian.

Still hope that helped.


With best regards,

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon:  +49.3535 490 17 92
Website:   https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220628/f2d9f079/attachment.sig>

From tombones at 440music.com  Tue Jun 28 19:03:44 2022
From: tombones at 440music.com (Tommy TBones Cramer)
Date: Tue, 28 Jun 2022 14:03:44 -0500
Subject: [Icecast] IceCast Control Panel
Message-ID: <b347a6f1-8f95-d930-4b3c-fc525b8c6100@440music.com>

Hello,

I am installing a new server to host my iceCast broadcast and will use 
CWP(CentOS Web Panel) which has iceCast as an available program for auto 
installation and wanted to know if anyone has used CWP for managing 
multiple radio broadcast? or if you know of another web site control 
panel that has an auto install for iceCast?

I have 13 streams at present with an additional 5 planned by years end 
and using CWP I'm hoping will save me time setting up new streams.

I've been on this mailing list fir a while and hope I'm using it right

Thanks

-- 
Tommy TBones Cramer
Owner
440Music Entertainment Co
www.440music.com
773 491 9937
599 365 0104 Zoom
t440Music Skype



From dik23 at hotmail.com  Wed Jun 29 11:54:09 2022
From: dik23 at hotmail.com (Dik ....)
Date: Wed, 29 Jun 2022 11:54:09 +0000
Subject: [Icecast] Reinstall changes icecast.xml
In-Reply-To: <0e21bf925dfe03b8f650384940da3b5d0faade7b.camel@de.loewenfelsen.net>
References: <LOYP123MB31849B6B8B530F94E1ED021EA8B99@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
 <0e21bf925dfe03b8f650384940da3b5d0faade7b.camel@de.loewenfelsen.net>
Message-ID: <LOYP123MB3184324DA6E1FA3AEAA26A91A8BB9@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>

Thanks for getting back

I get the exact same results using the versions supplied for 18.04 in the xiph repo

http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_18.04/

$ debconf-show icecast2 displays PASSWORD-D rather than the standard hackme

Editing debconf using debconf-get-selections / debconf-set-selections fixes this but it seems odd that I need to

________________________________
From: Icecast <icecast-bounces at xiph.org> on behalf of Philipp Schafft <phschafft at de.loewenfelsen.net>
Sent: 28 June 2022 13:41
To: Icecast streaming server user discussions <icecast at xiph.org>
Subject: Re: [Icecast] Reinstall changes icecast.xml

Good morning,

On Mon, 2022-06-27 at 21:34 +0000, Dik .... wrote:
> Ubuntu 20.04.4
> Icecast 2.4.4-3ubuntu0.1
> [...]
> Then I do apt remove icecast2 and apt install icecast2.... The
> icecast.xml stays the same apart from:
>
>     [...]
> Are these passwords supposed to change on reinstall?  Where is it
> getting PASSWORD-D from, it's nowhere else in icecast.xml??
>
> I noticed this when I updated from 18.04 to 20.04, which meant that
> icecast didn't work as expected after the update, but the same
> happens with uninstall / reinstall on 20.04.
>
> This is unhelpful when updating

this doesn't look like it is about upstream Icecast but the Ubuntu
package. Therefore best addressed at the Ubuntu bug tracker.

However: There are some Debian based packages out there that manage the
password as part of the package configuration. My best guess here is
re-installing triggered the package manager to sync it's stored
password back into the config file. If that is the case maybe it is
best to manage the password within the package manager?

Over here at Debian that is debconf. And it asks me on install if I
want to have Icecast managed by it. If I select the managed mode I get:
   $ debconf-show icecast2
   * icecast2/icecast-setup: true
   * icecast2/hostname: localhost
   * icecast2/adminpassword: hackme
   * icecast2/sourcepassword: hackme
   * icecast2/relaypassword: hackme

So maybe you can also just disable that by setting icecast2/icecast-
setup to false? But again, I would like to refer you to the Ubuntu
package maintainer/bug tracker here as all the above is guesswork based
on how things are on Debian.

Still hope that helped.


With best regards,

--
Philipp Schafft (CEO/Gesch?ftsf?hrer)
Telephon:  +49.3535 490 17 92
Website:   https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220629/40317357/attachment.htm>

From phschafft at de.loewenfelsen.net  Wed Jun 29 13:15:34 2022
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Wed, 29 Jun 2022 13:15:34 +0000
Subject: [Icecast] Reinstall changes icecast.xml
In-Reply-To: <LOYP123MB3184324DA6E1FA3AEAA26A91A8BB9@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
References: <LOYP123MB31849B6B8B530F94E1ED021EA8B99@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
 <0e21bf925dfe03b8f650384940da3b5d0faade7b.camel@de.loewenfelsen.net>
 <LOYP123MB3184324DA6E1FA3AEAA26A91A8BB9@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <ba88cbd9f2f00f3466261706b4850f4effe30b0b.camel@de.loewenfelsen.net>

Good afternoon,

On Wed, 2022-06-29 at 11:54 +0000, Dik .... wrote:
> Thanks for getting back
> 
> I get the exact same results using the versions supplied for 18.04 in
> the xiph repo
> 
> http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_18.04/

Yes, the provided packages basically mirror the distribution specific
parts from the downstream distributions. As they should work as drop-in 
replacement they shouldn't be too different.


> $ debconf-show icecast2 displays PASSWORD-D rather than the standard
> hackme
> 
> Editing debconf using debconf-get-selections / debconf-set-selections 
> fixes this but it seems odd that I need to

Good. So at least we have identified the problem.

Also means that it's part of your operating system and it's config. So
I would really like to recommend opening a ticket there. If you did so,
please feel free to link it on here. :)


With best regards,

> From: Icecast <icecast-bounces at xiph.org> on behalf of Philipp Schafft
> <phschafft at de.loewenfelsen.net>
> Sent: 28 June 2022 13:41
> To: Icecast streaming server user discussions <icecast at xiph.org>
> Subject: Re: [Icecast] Reinstall changes icecast.xml
>  
> Good morning,
> 
> On Mon, 2022-06-27 at 21:34 +0000, Dik .... wrote:
> > Ubuntu 20.04.4
> > Icecast 2.4.4-3ubuntu0.1
> > [...]
> > Then I do apt remove icecast2 and apt install icecast2.... The
> > icecast.xml stays the same apart from:
> > 
> >     [...]
> > Are these passwords supposed to change on reinstall?  Where is it
> > getting PASSWORD-D from, it's nowhere else in icecast.xml??
> > 
> > I noticed this when I updated from 18.04 to 20.04, which meant that
> > icecast didn't work as expected after the update, but the same
> > happens with uninstall / reinstall on 20.04.
> > 
> > This is unhelpful when updating
> 
> this doesn't look like it is about upstream Icecast but the Ubuntu
> package. Therefore best addressed at the Ubuntu bug tracker.
> 
> However: There are some Debian based packages out there that manage
> the
> password as part of the package configuration. My best guess here is
> re-installing triggered the package manager to sync it's stored
> password back into the config file. If that is the case maybe it is
> best to manage the password within the package manager?
> 
> Over here at Debian that is debconf. And it asks me on install if I
> want to have Icecast managed by it. If I select the managed mode I
> get:
>    $ debconf-show icecast2
>    * icecast2/icecast-setup: true
>    * icecast2/hostname: localhost
>    * icecast2/adminpassword: hackme
>    * icecast2/sourcepassword: hackme
>    * icecast2/relaypassword: hackme
> 
> So maybe you can also just disable that by setting icecast2/icecast-
> setup to false? But again, I would like to refer you to the Ubuntu
> package maintainer/bug tracker here as all the above is guesswork
> based
> on how things are on Debian.
> 
> Still hope that helped.


-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon:  +49.3535 490 17 92
Website:   https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220629/542cf628/attachment.sig>

From dik23 at hotmail.com  Wed Jun 29 13:47:47 2022
From: dik23 at hotmail.com (Dik ....)
Date: Wed, 29 Jun 2022 13:47:47 +0000
Subject: [Icecast] Reinstall changes icecast.xml
In-Reply-To: <ba88cbd9f2f00f3466261706b4850f4effe30b0b.camel@de.loewenfelsen.net>
References: <LOYP123MB31849B6B8B530F94E1ED021EA8B99@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
 <0e21bf925dfe03b8f650384940da3b5d0faade7b.camel@de.loewenfelsen.net>
 <LOYP123MB3184324DA6E1FA3AEAA26A91A8BB9@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>
 <ba88cbd9f2f00f3466261706b4850f4effe30b0b.camel@de.loewenfelsen.net>
Message-ID: <LOYP123MB3184DDFF94BDA8308DD3AD02A8BB9@LOYP123MB3184.GBRP123.PROD.OUTLOOK.COM>

Bug report opened

https://bugs.launchpad.net/ubuntu/+source/icecast2/+bug/1980241


________________________________
From: Icecast <icecast-bounces at xiph.org> on behalf of Philipp Schafft <phschafft at de.loewenfelsen.net>
Sent: 29 June 2022 14:15
To: Icecast streaming server user discussions <icecast at xiph.org>
Subject: Re: [Icecast] Reinstall changes icecast.xml

Good afternoon,

On Wed, 2022-06-29 at 11:54 +0000, Dik .... wrote:
> Thanks for getting back
>
> I get the exact same results using the versions supplied for 18.04 in
> the xiph repo
>
> http://download.opensuse.org/repositories/multimedia:/xiph/xUbuntu_18.04/

Yes, the provided packages basically mirror the distribution specific
parts from the downstream distributions. As they should work as drop-in
replacement they shouldn't be too different.


> $ debconf-show icecast2 displays PASSWORD-D rather than the standard
> hackme
>
> Editing debconf using debconf-get-selections / debconf-set-selections
> fixes this but it seems odd that I need to

Good. So at least we have identified the problem.

Also means that it's part of your operating system and it's config. So
I would really like to recommend opening a ticket there. If you did so,
please feel free to link it on here. :)


With best regards,

> From: Icecast <icecast-bounces at xiph.org> on behalf of Philipp Schafft
> <phschafft at de.loewenfelsen.net>
> Sent: 28 June 2022 13:41
> To: Icecast streaming server user discussions <icecast at xiph.org>
> Subject: Re: [Icecast] Reinstall changes icecast.xml
>
> Good morning,
>
> On Mon, 2022-06-27 at 21:34 +0000, Dik .... wrote:
> > Ubuntu 20.04.4
> > Icecast 2.4.4-3ubuntu0.1
> > [...]
> > Then I do apt remove icecast2 and apt install icecast2.... The
> > icecast.xml stays the same apart from:
> >
> >     [...]
> > Are these passwords supposed to change on reinstall?  Where is it
> > getting PASSWORD-D from, it's nowhere else in icecast.xml??
> >
> > I noticed this when I updated from 18.04 to 20.04, which meant that
> > icecast didn't work as expected after the update, but the same
> > happens with uninstall / reinstall on 20.04.
> >
> > This is unhelpful when updating
>
> this doesn't look like it is about upstream Icecast but the Ubuntu
> package. Therefore best addressed at the Ubuntu bug tracker.
>
> However: There are some Debian based packages out there that manage
> the
> password as part of the package configuration. My best guess here is
> re-installing triggered the package manager to sync it's stored
> password back into the config file. If that is the case maybe it is
> best to manage the password within the package manager?
>
> Over here at Debian that is debconf. And it asks me on install if I
> want to have Icecast managed by it. If I select the managed mode I
> get:
>    $ debconf-show icecast2
>    * icecast2/icecast-setup: true
>    * icecast2/hostname: localhost
>    * icecast2/adminpassword: hackme
>    * icecast2/sourcepassword: hackme
>    * icecast2/relaypassword: hackme
>
> So maybe you can also just disable that by setting icecast2/icecast-
> setup to false? But again, I would like to refer you to the Ubuntu
> package maintainer/bug tracker here as all the above is guesswork
> based
> on how things are on Debian.
>
> Still hope that helped.


--
Philipp Schafft (CEO/Gesch?ftsf?hrer)
Telephon:  +49.3535 490 17 92
Website:   https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220629/df52a5cd/attachment.htm>

From phschafft at de.loewenfelsen.net  Thu Jun 30 09:39:46 2022
From: phschafft at de.loewenfelsen.net (Philipp Schafft)
Date: Thu, 30 Jun 2022 09:39:46 +0000
Subject: [Icecast] On low latency
Message-ID: <4e2ea5d32b40a613041da76801471875cb697947.camel@de.loewenfelsen.net>

Good morning,

over at L?wenfelsen we asked on LinkedIn what people think how low they
can go with Icecast and latency. As I think this is also interesting
for this list I want to share the results with you. Also going more
into technical details here as this list is more tech focused.

We asked what is possible?: Less than 10s, less than 1s, less than
100ms, or less than 10ms. What do you think?


So let's have a look:
There are a number of values that add up to the total latency.


The first one is the network latency. This is basically the time it
takes for any information to travel from the source to the sink
(listener) on the network. There are two limiting factors here: the
network access on both ends and the speed of light once you reached the
backbone level.

Network access delay depends very much on the network access technology
used (e.g. DSL, cable modem, power line, LTE, ...) as well as the ISP
and it's configuration. The values here dropped a lot. When I started
with Icecast it was more like 60..100ms in Germany now it is more like
2..10ms on wired connections.

In most cases your source client is connected via a good, nearly
backbone level network. So you can ignore that. However if you for
example have small studio that has just a consumer grade uplink you
need to keep that in mind.

Once you reached the backbone information will flow at about 1/3 of the
speed of light. It depends on where you are and where you want to send
to. But the above worked as a rule of thumb of me. So add about
1ms/100km.


You can consider this part of the latency unchangeable as it is
directly based on the physics of our universe.

There is a little more, see jitter a little later in this mail.


The next part is signal generation and rendering delay. This basically
means codec delays, delays of your sound hardware, delays of all the
other hardware (such as your RAM, your CPU, your PCI bus, ...).

This part is a bit under your control: You can use more modern
components and get a lower value. But all this also depends on both
physics and how we understand it. It is a area of huge amounts of
research and development.

So basically you add up all the numbers: sound card delay, sound card
interface delay, software delay, codec delay, network interface
delay,...

Most of those will be in the microsecond range so we can ignore it.
However sound cards, software, and codecs have a significant delay. At
least for codecs this got down a lot over the last 20 years. So
depending on your configuration you can reach values below 50ms.

The same applies for your listener. However e.g. codec delay which is a
large part of the source side's delay is normally much smaller on the
decoder side. But on the other hand you may not have that nice
processional sound card but something random adding more delay again.


Now there are two parts left, the delay by Icecast and the delay by the
listener software. So let's have a look at Icecast:

We had some tests (the results were in our last presentation) on the
delay within Icecast. Basically Icecast does forward data as soon as it
gets it. (I'm not sure where that myth Icecast would do some buffering
comes from.) But I think nobody really measured that before. So we did.
And in all our tests Icecast forwarded the data in less than 500?s. Now
please also keep in mind that this was done on multi-tasking operating
systems (both servers and desktops) so other things where going on as
well. Meaning that Icecast is subject of being blocked by other
processes as part of the normal operation of the operating system. And
this is what I have seen in the numbers.


What So the last significant part is the buffer in the listener client.
In reality this buffer is > 90% of the latency you get. Which is good
news actually:
If you control the listener client (e.g. the listener is using your
App) you are on full control over that buffer. So you can select any
value you like.

However there are a few limitations here to keep in mind:
 * Network naturally jitters. The jitter is the difference in time it
   takes for two packets to travel via the network. It is no delay by
   itself as when summed up you will always get a sum of zero. However
   for smooth playback the listener client must keep at least so much
   buffer to handle the worst expected jitter. This is what that
   listener buffer was made for initially. 20 years ago a value of e.g.
   8 seconds seemed reasonable here. Today I would say that on wired
   networks a value of 500ms..1500ms seams reasonable. Lower in
   controlled environments.
 * Mobile networks come with dead spots. The listener's buffer helps
   with them as well as they look like jitter. Dead spots can be from a
   few milliseconds to tens of seconds. So again: Select a value that
   gives the best tradeoff for your usecase.
   Bigger buffer: more
   reliable, more delay
   Smaller buffer: less reliable, less delay
 * Browsers are very bad as media players. You will often have a hardtime to really control them. So just because you added a <audio>elements doesn't mean that you have playback under control.



So on the conclusion:
Icecast provides low latency forwarding of data. In the area of reliabl
e streams ("the music never stops") it provides the lowest latency
possible by laws of physics.

What latency you can expect depends on your setup and configuration.
Are you more optimistic? Or do you want to play more conservative? Do
you have your network, hardware, and listener clients under control? Or
maybe only parts of that? What kind of network anyway?

In reality It seems like the values you can get are around 20..500ms
plus the listener playback buffer (which can range from a few
milliseconds to a few seconds).

Also keep in mind that the numbers normally look much worse than they
are: Sound travels at about 343m/s (air, normal conditions). So every
ms more latency you have corresponds to someone sitting 34.3cm more
away from the speaker. So dancing to the music in your living room adds
another 15ms...


Hope this post was of interest. Also congratulations to everyone who
made it to the end.

If anyone is interested on how we measured it feel free to drop me a
mail off-list. Also if you're a CDN and want some measurements done or
have other questions, feel free to contact us as well.


With best regards,

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon:  +49.3535 490 17 92
Website:   https://www.loewenfelsen.net/
Follow us: https://www.linkedin.com/company/loewenfelsen/

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220630/489ea2a3/attachment.sig>

From dennis at heerema.net  Thu Jun 30 15:41:27 2022
From: dennis at heerema.net (Dennis Heerema)
Date: Thu, 30 Jun 2022 17:41:27 +0200
Subject: [Icecast] On low latency
Message-ID: <59b0aa88-3dd3-4e9b-be96-bde6be046cb8@email.android.com>

An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220630/3de6e178/attachment.htm>

From mwpmorris at gmail.com  Thu Jun 30 18:35:50 2022
From: mwpmorris at gmail.com (Matt Morris)
Date: Thu, 30 Jun 2022 19:35:50 +0100
Subject: [Icecast] On low latency
In-Reply-To: <59b0aa88-3dd3-4e9b-be96-bde6be046cb8@email.android.com>
References: <59b0aa88-3dd3-4e9b-be96-bde6be046cb8@email.android.com>
Message-ID: <2F259545-457A-44CE-83FB-45BF229935C6@gmail.com>

+1, yes many thanks Philipp. This is the exact talk that I was disappointed in missing out on so very valuable information.

Matt Morris.

Sent from my iPhone

> On 30 Jun 2022, at 16:49, Dennis Heerema <dennis at heerema.net> wrote:
> 
> ?
> Hallo Philipp,
> 
> Thank you very much for sharing this.
> 
> 
> Kind regards,
> 
> Dennis
> 
> Op 30 jun. 2022 11:40 schreef "Philipp Schafft (phschafft at de.loewenfelsen.net)" <phschafft at de.loewenfelsen.net>:
> Good morning,
> 
> over at L?wenfelsen we asked on LinkedIn what people think how low they
> can go with Icecast and latency. As I think this is also interesting
> for this list I want to share the results with you. Also going more
> into technical details here as this list is more tech focused.
> 
> We asked what is possible?: Less than 10s, less than 1s, less than
> 100ms, or less than 10ms. What do you think?
> 
> 
> So let's have a look:
> There are a number of values that add up to the total latency.
> 
> 
> The first one is the network latency. This is basically the time it
> takes for any information to travel from the source to the sink
> (listener) on the network. There are two limiting factors here: the
> network access on both ends and the speed of light once you reached the
> backbone level.
> 
> Network access delay depends very much on the network access technology
> used (e.g. DSL, cable modem, power line, LTE, ...) as well as the ISP
> and it's configuration. The values here dropped a lot. When I started
> with Icecast it was more like 60..100ms in Germany now it is more like
> 2..10ms on wired connections.
> 
> In most cases your source client is connected via a good, nearly
> backbone level network. So you can ignore that. However if you for
> example have small studio that has just a consumer grade uplink you
> need to keep that in mind.
> 
> Once you reached the backbone information will flow at about 1/3 of the
> speed of light. It depends on where you are and where you want to send
> to. But the above worked as a rule of thumb of me. So add about
> 1ms/100km.
> 
> 
> You can consider this part of the latency unchangeable as it is
> directly based on the physics of our universe.
> 
> There is a little more, see jitter a little later in this mail.
> 
> 
> The next part is signal generation and rendering delay. This basically
> means codec delays, delays of your sound hardware, delays of all the
> other hardware (such as your RAM, your CPU, your PCI bus, ...).
> 
> This part is a bit under your control: You can use more modern
> components and get a lower value. But all this also depends on both
> physics and how we understand it. It is a area of huge amounts of
> research and development.
> 
> So basically you add up all the numbers: sound card delay, sound card
> interface delay, software delay, codec delay, network interface
> delay,...
> 
> Most of those will be in the microsecond range so we can ignore it.
> However sound cards, software, and codecs have a significant delay. At
> least for codecs this got down a lot over the last 20 years. So
> depending on your configuration you can reach values below 50ms.
> 
> The same applies for your listener. However e.g. codec delay which is a
> large part of the source side's delay is normally much smaller on the
> decoder side. But on the other hand you may not have that nice
> processional sound card but something random adding more delay again.
> 
> 
> Now there are two parts left, the delay by Icecast and the delay by the
> listener software. So let's have a look at Icecast:
> 
> We had some tests (the results were in our last presentation) on the
> delay within Icecast. Basically Icecast does forward data as soon as it
> gets it. (I'm not sure where that myth Icecast would do some buffering
> comes from.) But I think nobody really measured that before. So we did.
> And in all our tests Icecast forwarded the data in less than 500?s. Now
> please also keep in mind that this was done on multi-tasking operating
> systems (both servers and desktops) so other things where going on as
> well. Meaning that Icecast is subject of being blocked by other
> processes as part of the normal operation of the operating system. And
> this is what I have seen in the numbers.
> 
> 
> What So the last significant part is the buffer in the listener client.
> In reality this buffer is > 90% of the latency you get. Which is good
> news actually:
> If you control the listener client (e.g. the listener is using your
> App) you are on full control over that buffer. So you can select any
> value you like.
> 
> However there are a few limitations here to keep in mind:
>  * Network naturally jitters. The jitter is the difference in time it
>    takes for two packets to travel via the network. It is no delay by
>    itself as when summed up you will always get a sum of zero. However
>    for smooth playback the listener client must keep at least so much
>    buffer to handle the worst expected jitter. This is what that
>    listener buffer was made for initially. 20 years ago a value of e.g.
>    8 seconds seemed reasonable here. Today I would say that on wired
>    networks a value of 500ms..1500ms seams reasonable. Lower in
>    controlled environments.
>  * Mobile networks come with dead spots. The listener's buffer helps
>    with them as well as they look like jitter. Dead spots can be from a
>    few milliseconds to tens of seconds. So again: Select a value that
>    gives the best tradeoff for your usecase.
>    Bigger buffer: more
>    reliable, more delay
>    Smaller buffer: less reliable, less delay
>  * Browsers are very bad as media players. You will often have a hardtime to really control them. So just because you added a elements doesn't mean that you have playback under control.
> 
> 
> 
> So on the conclusion:
> Icecast provides low latency forwarding of data. In the area of reliabl
> e streams ("the music never stops") it provides the lowest latency
> possible by laws of physics.
> 
> What latency you can expect depends on your setup and configuration.
> Are you more optimistic? Or do you want to play more conservative? Do
> you have your network, hardware, and listener clients under control? Or
> maybe only parts of that? What kind of network anyway?
> 
> In reality It seems like the values you can get are around 20..500ms
> plus the listener playback buffer (which can range from a few
> milliseconds to a few seconds).
> 
> Also keep in mind that the numbers normally look much worse than they
> are: Sound travels at about 343m/s (air, normal conditions). So every
> ms more latency you have corresponds to someone sitting 34.3cm more
> away from the speaker. So dancing to the music in your living room adds
> another 15ms...
> 
> 
> Hope this post was of interest. Also congratulations to everyone who
> made it to the end.
> 
> If anyone is interested on how we measured it feel free to drop me a
> mail off-list. Also if you're a CDN and want some measurements done or
> have other questions, feel free to contact us as well.
> 
> 
> With best regards,
> 
> -- 
> Philipp Schafft (CEO/Gesch?ftsf?hrer) 
> Telephon:  +49.3535 490 17 92
> Website:   https://www.loewenfelsen.net/
> Follow us: https://www.linkedin.com/company/loewenfelsen/
> 
> L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
> Bickinger Stra?e 21                     HRB 12308 CB
> 04916 Herzberg (Elster)                 VATIN/USt-ID:
> Germany                                 DE305133015
> 
> _______________________________________________
> 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/20220630/c27dd8f1/attachment.htm>

From db76 at riseup.net  Thu Jun 30 21:05:49 2022
From: db76 at riseup.net (db76 at riseup.net)
Date: Fri, 1 Jul 2022 07:05:49 +1000
Subject: [Icecast] On low latency
In-Reply-To: <2F259545-457A-44CE-83FB-45BF229935C6@gmail.com>
References: <2F259545-457A-44CE-83FB-45BF229935C6@gmail.com>
Message-ID: <0E68BC93-E8BF-4ABC-BC96-9EA3A924A3BF@riseup.net>

Same here. Very valuable so thanks for sharing this Philipp.

> On 1 Jul 2022, at 04:36, Matt Morris <mwpmorris at gmail.com> wrote:
> 
> ?+1, yes many thanks Philipp. This is the exact talk that I was disappointed in missing out on so very valuable information.
> 
> Matt Morris.
> 
> Sent from my iPhone
> 
>>> On 30 Jun 2022, at 16:49, Dennis Heerema <dennis at heerema.net> wrote:
>>> 
>> ?
>> Hallo Philipp,
>> 
>> Thank you very much for sharing this.
>> 
>> 
>> Kind regards,
>> 
>> Dennis
>> 
>> Op 30 jun. 2022 11:40 schreef "Philipp Schafft (phschafft at de.loewenfelsen.net)" <phschafft at de.loewenfelsen.net>:
>> Good morning,
>> 
>> over at L?wenfelsen we asked on LinkedIn what people think how low they
>> can go with Icecast and latency. As I think this is also interesting
>> for this list I want to share the results with you. Also going more
>> into technical details here as this list is more tech focused.
>> 
>> We asked what is possible?: Less than 10s, less than 1s, less than
>> 100ms, or less than 10ms. What do you think?
>> 
>> 
>> So let's have a look:
>> There are a number of values that add up to the total latency.
>> 
>> 
>> The first one is the network latency. This is basically the time it
>> takes for any information to travel from the source to the sink
>> (listener) on the network. There are two limiting factors here: the
>> network access on both ends and the speed of light once you reached the
>> backbone level.
>> 
>> Network access delay depends very much on the network access technology
>> used (e.g. DSL, cable modem, power line, LTE, ...) as well as the ISP
>> and it's configuration. The values here dropped a lot. When I started
>> with Icecast it was more like 60..100ms in Germany now it is more like
>> 2..10ms on wired connections.
>> 
>> In most cases your source client is connected via a good, nearly
>> backbone level network. So you can ignore that. However if you for
>> example have small studio that has just a consumer grade uplink you
>> need to keep that in mind.
>> 
>> Once you reached the backbone information will flow at about 1/3 of the
>> speed of light. It depends on where you are and where you want to send
>> to. But the above worked as a rule of thumb of me. So add about
>> 1ms/100km.
>> 
>> 
>> You can consider this part of the latency unchangeable as it is
>> directly based on the physics of our universe.
>> 
>> There is a little more, see jitter a little later in this mail.
>> 
>> 
>> The next part is signal generation and rendering delay. This basically
>> means codec delays, delays of your sound hardware, delays of all the
>> other hardware (such as your RAM, your CPU, your PCI bus, ...).
>> 
>> This part is a bit under your control: You can use more modern
>> components and get a lower value. But all this also depends on both
>> physics and how we understand it. It is a area of huge amounts of
>> research and development.
>> 
>> So basically you add up all the numbers: sound card delay, sound card
>> interface delay, software delay, codec delay, network interface
>> delay,...
>> 
>> Most of those will be in the microsecond range so we can ignore it.
>> However sound cards, software, and codecs have a significant delay. At
>> least for codecs this got down a lot over the last 20 years. So
>> depending on your configuration you can reach values below 50ms.
>> 
>> The same applies for your listener. However e.g. codec delay which is a
>> large part of the source side's delay is normally much smaller on the
>> decoder side. But on the other hand you may not have that nice
>> processional sound card but something random adding more delay again.
>> 
>> 
>> Now there are two parts left, the delay by Icecast and the delay by the
>> listener software. So let's have a look at Icecast:
>> 
>> We had some tests (the results were in our last presentation) on the
>> delay within Icecast. Basically Icecast does forward data as soon as it
>> gets it. (I'm not sure where that myth Icecast would do some buffering
>> comes from.) But I think nobody really measured that before. So we did.
>> And in all our tests Icecast forwarded the data in less than 500?s. Now
>> please also keep in mind that this was done on multi-tasking operating
>> systems (both servers and desktops) so other things where going on as
>> well. Meaning that Icecast is subject of being blocked by other
>> processes as part of the normal operation of the operating system. And
>> this is what I have seen in the numbers.
>> 
>> 
>> What So the last significant part is the buffer in the listener client.
>> In reality this buffer is > 90% of the latency you get. Which is good
>> news actually:
>> If you control the listener client (e.g. the listener is using your
>> App) you are on full control over that buffer. So you can select any
>> value you like.
>> 
>> However there are a few limitations here to keep in mind:
>>  * Network naturally jitters. The jitter is the difference in time it
>>    takes for two packets to travel via the network. It is no delay by
>>    itself as when summed up you will always get a sum of zero. However
>>    for smooth playback the listener client must keep at least so much
>>    buffer to handle the worst expected jitter. This is what that
>>    listener buffer was made for initially. 20 years ago a value of e.g.
>>    8 seconds seemed reasonable here. Today I would say that on wired
>>    networks a value of 500ms..1500ms seams reasonable. Lower in
>>    controlled environments.
>>  * Mobile networks come with dead spots. The listener's buffer helps
>>    with them as well as they look like jitter. Dead spots can be from a
>>    few milliseconds to tens of seconds. So again: Select a value that
>>    gives the best tradeoff for your usecase.
>>    Bigger buffer: more
>>    reliable, more delay
>>    Smaller buffer: less reliable, less delay
>>  * Browsers are very bad as media players. You will often have a hardtime to really control them. So just because you added a elements doesn't mean that you have playback under control.
>> 
>> 
>> 
>> So on the conclusion:
>> Icecast provides low latency forwarding of data. In the area of reliabl
>> e streams ("the music never stops") it provides the lowest latency
>> possible by laws of physics.
>> 
>> What latency you can expect depends on your setup and configuration.
>> Are you more optimistic? Or do you want to play more conservative? Do
>> you have your network, hardware, and listener clients under control? Or
>> maybe only parts of that? What kind of network anyway?
>> 
>> In reality It seems like the values you can get are around 20..500ms
>> plus the listener playback buffer (which can range from a few
>> milliseconds to a few seconds).
>> 
>> Also keep in mind that the numbers normally look much worse than they
>> are: Sound travels at about 343m/s (air, normal conditions). So every
>> ms more latency you have corresponds to someone sitting 34.3cm more
>> away from the speaker. So dancing to the music in your living room adds
>> another 15ms...
>> 
>> 
>> Hope this post was of interest. Also congratulations to everyone who
>> made it to the end.
>> 
>> If anyone is interested on how we measured it feel free to drop me a
>> mail off-list. Also if you're a CDN and want some measurements done or
>> have other questions, feel free to contact us as well.
>> 
>> 
>> With best regards,
>> 
>> -- 
>> Philipp Schafft (CEO/Gesch?ftsf?hrer) 
>> Telephon:  +49.3535 490 17 92
>> Website:   https://www.loewenfelsen.net/
>> Follow us: https://www.linkedin.com/company/loewenfelsen/
>> 
>> L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
>> Bickinger Stra?e 21                     HRB 12308 CB
>> 04916 Herzberg (Elster)                 VATIN/USt-ID:
>> Germany                                 DE305133015
>> 
>> _______________________________________________
>> 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/20220701/9d8a2787/attachment.htm>