Re: only a few listeners - reduce resource usage?

"D.T." <[email protected]>
Newsgroups gmane.comp.audio.icecast.general
Message-ID <[email protected]>
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
> [email protected]
> 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)

_______________________________________________
Icecast mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/icecast
signature.asc (application/pgp-signature, 659 B)
-----BEGIN PGP SIGNATURE-----

iQGzBAABCAAdFiEEfAAgvN4mih7l6uteTaRYCP0a64MFAmKcTj4ACgkQTaRYCP0a
64MXvQwA0Bi1k9KmiPvpoPxdx0bec8mXl9vYJkcNt6wxjRPF2HofcgYIQhBlXZAw
B4eEznGxe49KKy0Eh8N8aWEmAU1syn/PCFeks1T+5J5TO0xwF1gq6izX3N+8+l7F
evKthrSwPqc+BlUXpIzXZEx3PIEuwoRzDFi7bj0XUWbTctXMLh9Hxts/eb4UIqPA
2envUVrhazHWv/Deb2LLw1sZi+3c8UhH5GW7WLEQ5fkEez8vPbw0viU4aldiP6pr
jsuAeFGrd1g/gDsgFiHW2qpmjPlr9AKBIBiW4NMgYix0cHdSgJfRaYyBLXJfnAK7
/dNAUDbGl9W1gvrJSDzNGf4YxusYCzzQgh3VVW5ukhoGcKgZJ3y9vWYj38g+JiHG
9hi2Dh4QEEaiVyAxiOitJkAcFpBtOLEOIv2AoJKW/8D2XFGlro55aeBXBTnxnEdR
jn09SoEc5Zex/EVKm3goU6XGKh+WxBNbAM4DQZVm6YL/N2plKZ5KPzjE/TYA19gy
tDmhkjZ1
=Bb28
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.