I am running Icecast2 and Ices2 on Redhat Linux 9. I have two ices running with
two different
configuration sending to Icecast and the cpu load for each is around 7.0. The
playlist contains
ogg files encoded using Ogg Encoder Decoder 1.2.8b from (www.mediatwins.com)
with
64kbps, 44.1KHz, VBR.
The <encode> </encode> is the same for both configurations and
here it is:
<encode>
<managed>0</managed>
<nominal-bitrate>32000</nominal-bitrate>
<samplerate>22050</samplerate>
<channels>2</channels>
</encode>
At <nominal-bitrate>24000</nominal-bitrate> the %CPU goes below 1
but I get
the following from Icecast admin web-address/status.xsl
Stream Information (stream not currently available)
Stream Type: Ogg Vorbis
Current Song: -
I tried by adding <quality>0</quality> to the above and tried to
tune between -1 to 10 but still %CPU is very high
I tried
<encode>
<quality>0</quality>
<nominal-bitrate>64000</nominal-bitrate>
<managed>0</managed>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
and the %CPU is around 13
How can I reduce the cpu load?
Here are some more info about the enviornment:
Machine info:
Pentium 4 - 2.0Ghz 1GB RAM
Redhat Linux 9
// below is the "top" output for the two ices and icecast
15:05:33 up 120 days, 14:53, 1 user, load average: 0.24, 0.20, 0.18
94 processes: 91 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 14.5% user 0.3% system 0.0% nice 0.0% iowait 85.0% idle
Mem: 1022796k av, 1003860k used, 18936k free, 0k shrd, 188964k buff
751916k actv, 0k in_d, 24812k in_c
Swap: 2048276k av, 66032k used, 1982244k free 554988k cached
<p> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU
COMMAND
2878 root 15 0 1844 1724 724 S 7.5 0.1 542:44 0 ices
2875 root 15 0 2068 1912 732 S 6.9 0.1 547:58 0 ices
2863 glen 15 0 2528 1976 1156 S 0.3 0.1 5:09 0 icecast
------------------------------------------------
<!-- ices-playlist_01.xml -->
<?xml version="1.0"?>
<ices>
<!-- run in background -->
<background>1</background>
<!-- where logs, etc go. -->
<logpath>/usr/local/share/ices/log</logpath>
<logfile>ices01.log</logfile>
<!-- 1=error,2=warn,3=info,4=debug -->
<loglevel>4</loglevel>
<!-- set this to 1 to log to the console instead of to the file above
-->
<consolelog>0</consolelog>
<!-- optional filename to write process id to -->
<pidfile>/usr/local/share/ices/pid/ices01.pid</pidfile>
<stream>
<!-- metadata used for stream listing (not currently used) -->
<metadata>
<name>zdomain-name.com</name>
<genre>pop</genre>
<description>Music Radio</description>
<url><a
href="http://www.zdomain-name.com</url">http://www.zdomain-name.com</url</a>>
</metadata>
<!-- input module
The module used here is the playlist module - it has
'submodules' for different types of playlist. There are
two currently implemented, 'basic', which is a simple
file-based playlist, and 'script' which invokes a command
to returns a filename to start playing. -->
<input>
<module>playlist</module>
<param name="type">basic</param>
<param name="file">/usr/local/share/ices/station
_01.txt</param>
<!-- random play -->
<param name="random">1</param>
<!-- if the playlist get updated that start at the beginning
-->
<param name="restart-after-reread">1</param>
<!-- if set to 1 , plays once through, then exits. -->
<param name="once">0</param>
</input>
<!-- Stream instance
You may have one or more instances here. This allows you to
send the same input data to one or more servers (or to different
mountpoints on the same server). Each of them can have different
parameters. This is primarily useful for a) relaying to multiple
independent servers, and b) encoding/reencoding to multiple
bitrates.
If one instance fails (for example, the associated server goes
down, etc), the others will continue to function correctly.
This example defines two instances as two mountpoints on the
same server. -->
<instance>
<!-- Server details:
You define hostname and port for the server here, along with
the source password and mountpoint. -->
<hostname>zdomain-name.com</hostname>
<port>8000</port>
<password>my_password</password>
<mount>/station_01.ogg</mount>
<!-- Reconnect parameters:
When something goes wrong (e.g. the server crashes, or the
network drops) and ices disconnects from the server, these
control how often it tries to reconnect, and how many times
it tries to reconnect. Delay is in seconds.
If you set reconnectattempts to -1, it will continue
indefinately. Suggest setting reconnectdelay to a large value
if you do this.
-->
<reconnectdelay>2</reconnectdelay>
<reconnectattempts>5</reconnectattempts>
<!-- maxqueuelength:
This describes how long the internal data queues may be. This
basically lets you control how much data gets buffered before
ices decides it can't send to the server fast enough, and
either shuts down or flushes the queue (dropping the data)
and continues.
For advanced users only.
-->
<maxqueuelength>80</maxqueuelength>
<!-- Live encoding/reencoding:
Currrently, the parameters given here for encoding MUST
match the input data for channels and sample rate. That
restriction will be relaxed in the future.
-->
<encode>
<quality>0</quality>
<nominal-bitrate>32000</nominal-bitrate>
<managed>0</managed>
<samplerate>22050</samplerate>
<channels>2</channels>
</encode>
<p> </instance>
</stream>
</ices>
Thank you all!
Ben
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.