Thanks for the reply David.
I was actually looking for a way to render the stream almost perfectly
reliable, by using liquidsoap to fill in transparently when the actual
source is unavailable, instead of kicking the users. I have been running
some tests all day, and so far my main finding is that the CPU usage varies
alot, and I can't find the constant. All streams have the same source
server, and I only have 2 different bitrates (128 and 32). But CPU usage
varies greatly :
1002 18422 1 2 20:55 ? 00:00:08 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/chga128.liq
1002 18436 1 8 20:55 ? 00:00:26 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/chga32.liq
1002 18451 1 9 20:55 ? 00:00:27 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/cibl128.liq
1002 18465 1 1 20:55 ? 00:00:05 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/cibl32.liq
1002 18481 1 4 20:55 ? 00:00:13 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/cile.liq
1002 18496 1 11 20:55 ? 00:00:35 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/cjrg128.liq
1002 18510 1 6 20:55 ? 00:00:20 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/cjrg32.liq
1002 18526 1 3 20:55 ? 00:00:11 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/ckrl128.liq
1002 18542 1 10 20:55 ? 00:00:30 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/ckrl32.liq
1002 18557 1 23 20:55 ? 00:01:13 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/test128.liq
1002 18572 1 4 20:55 ? 00:00:14 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/test192.liq
1002 18588 1 16 20:55 ? 00:00:49 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/test64.liq
I currently have 13 streams, the cile.liq has 2 in it. The file name
indicates the bitrate. As you might notice, some 128 and 192 kbit/s are
taking less CPU then some 32 kbit/s encodes. I can't figure out why. The
content does not explain, I think...
With 13 streams CPU usage is about 50% on each core (the sever is a
dual-core 1.6 Ghz CPU, pretty slow). So a high-end core 2 duo should handle
30 streams easily, probably more.
Another test I just did :
I actually have 2 streams with the same source, so in 40 streams there is 20
actual sources. Since liquidsoap is already decoding the mp3 streams, I will
try having liquidsoap doing the reencode for the low quality stream, using
the built-in encoder.
This is what the cile.liq is doing, and the output of 2 streams consumes
less CPU then some 32 kbit/s relaying. Strange...
1002 18481 1 4 20:55 ? 00:00:13 /usr/local/bin/liquidsoap -d
/usr/local/etc/liquidsoap/cile.liq
Thanks for your help, it is much appreciated !
Guillaume
On Sun, Jul 4, 2010 at 8:40 PM, David Baelde <[email protected]> wrote:
> Hello Guillaume,
>
> 2010/7/4 Guillaume Ferland <[email protected]>:
> > My current problem is that even with only 2 streams relayed by
> liquidsoap,
> > my CPU usage is about 20% (speedstep is supported by the cpu, so it might
> be
> > lower, overall load is very low...). I have up to 40-50 streams running
> on a
> > server. I am curious if this will be a problem, i'm using low-end cpus on
> my
> > machines atm for streaming, as usage generated by icecast is very low.
>
> Unfortunately, 20% doesn't sound absurd. Liquidsoap's design relies on
> a fundamental choice: work with raw streams to do as many things as
> possible. But this choice means that we decode everything, so
> liquidsoap, as a relay, is not optimal in terms of CPU power: it
> decodes and then re-encodes (of course, this is necessary if you are
> transcoding, but I don't think that it is your goal here).
>
> Comparatively, icecast is very light: it simply passes data around,
> only looking at the ogg level in data, not doing any vorbis
> encoding/decoding.
>
> If you have that many streams to relay, you might need a simpler tool
> that does only relaying... unfortunately, I don't know any :(
>
> Hope that helps,
> --
> David
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
