I'm running ices-kh to stream from jack at 64kbps, and also using oggenc (with ecasound via jack) to record the audio to disk at the same time. This is also running at 64kbps. ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't see why there should be such a difference - both are recording the same audio stream in real time at the same bitrate. oggenc is getting its input as a raw audio pipe from ecasound. I checked with ldd, and both are using the same version of libvorbisenc. Why is this happening?
On Wed, 13 Oct 2004 18:11:09 +0100, Andy Baxter wrote:> I'm running ices-kh to stream from jack at 64kbps, and also using oggenc > (with ecasound via jack) to record the audio to disk at the same time. > This is also running at 64kbps. > > ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't > see why there should be such a difference - both are recording the same > audio stream in real time at the same bitrate. oggenc is getting its input > as a raw audio pipe from ecasound. I checked with ldd, and both are using > the same version of libvorbisenc. > > Why is this happening?P.S. I know you can record streams from ices, or dump the stream from icecast, but the scripting for splitting the stream into individual shows is simpler using the ecasound/oggenc method, so I wanted to try using that.
On Thursday 14 October 2004 03:11, Andy Baxter wrote:> I'm running ices-kh to stream from jack at 64kbps, and also using oggenc > (with ecasound via jack) to record the audio to disk at the same time. > This is also running at 64kbps. > > ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't > see why there should be such a difference - both are recording the same > audio stream in real time at the same bitrate. oggenc is getting its input > as a raw audio pipe from ecasound. I checked with ldd, and both are using > the same version of libvorbisenc. > > Why is this happening? >Whilst I don't have a definite answer, it's very common for certain types of application to cause 'top' (and any tool that works in a similar way) to drastically under-report cpu usage. A common example familiar to many (it's probably less noticable now, since cpus are much faster) is xmms playing mp3s - on a system where that was known to take ~10-15% of cpu time, top consistently reported 0% used. So it might just be that the cpu usage is being mis-reported. Mike
On Thu, 14 Oct 2004 10:43:50 +1000, Michael Smith wrote:> On Thursday 14 October 2004 03:11, Andy Baxter wrote: >> I'm running ices-kh to stream from jack at 64kbps, and also using oggenc >> (with ecasound via jack) to record the audio to disk at the same time. >> This is also running at 64kbps. >> >> ices is using virtually no cpu (0.0%), but oggenc is using 15-16%. I can't >> see why there should be such a difference - both are recording the same >> audio stream in real time at the same bitrate. oggenc is getting its input >> as a raw audio pipe from ecasound. I checked with ldd, and both are using >> the same version of libvorbisenc. >> >> Why is this happening? >> > > Whilst I don't have a definite answer, it's very common for certain types of > application to cause 'top' (and any tool that works in a similar way) to > drastically under-report cpu usage. > > A common example familiar to many (it's probably less noticable now, since > cpus are much faster) is xmms playing mp3s - on a system where that was known > to take ~10-15% of cpu time, top consistently reported 0% used. > > So it might just be that the cpu usage is being mis-reported. > > MikeIt looks like this is the problem - the cpu times from /proc/[pid]/stat are stuck at zero for ices, but not for some of the other processes. Killing the process drops the total cpu use by about 13%, which fits with the amount needed by oggenc.
On Thu, Oct 14, 2004 at 10:43:50AM +1000, Michael Smith wrote:> Whilst I don't have a definite answer, it's very common for certain types of > application to cause 'top' (and any tool that works in a similar way) to > drastically under-report cpu usage.It's threaded programs under a kernel that does threads in the kernel (Linux 2.6 does; 2.4 doesn't). The current procps tools (especially top and pstree) don't know about kernel threads. icecast, ices2 and xmms all use threads. -- Paul Martin <pm@zetnet.net> (work) <pm@nowster.zetnet.co.uk> (home)