This becomes very critical for me!
I have changed the motherboard to a more Linux-friendly one (regarding graphics), but the issue remains!
I
have even disabled all the router graphics in python files and the
issue still remains: idle machines alltogether use a lot of CPU! And by
using "top" command it shows that this cpu usage is by "python" only
(not Xorg for instance), moreover, top's values are higher than those
shown inside of the program.
I have tried to ask for the support from paniq by describing the issue on his Armstrong's page:
https://bitbucket.org/paniq/armstrong/issue/19/idle-machines-high-cpu-usageAlso, dont forget, that it's not only me suffering from this:
https://bitbucket.org/bucket_brigade/neil/issue/148/router-performanceI
would explain a little more the problem itself: each single machine
which is idle but in player play/stop state takes some amount of CPU.
Before you press play the first time everything is allright! But once
you will press play, even idle machines take CPU! After pressing stop
and even not hearing any sound anymore, CPU usage would last forever!
When
there are just a few of machines (about 10 in total) it is almost not
noticable. All .ccm files provided on this group do not use much more
than about 10 machines!
But I personally want to create
GOA-Trance music and it generally requires a lot of machines, taking it
all from the machine. At least, this is how people were doing.
I also
want to learn making music, I am a beginner and also I don't mind
learning Linux and contributing to the project (already contributed
bypass mode, full psycle plugins support).
There are quite a lot of
native psycle modules available and some of them a real GOA-Trance
(Taika Kim)! This is the perfect way to learn!
I was also don't mind
using psycle under wine, but it becomes also very hard, because older
.psy files might not work with newer psycle release and vice versa. So
it's messing up with various psycle versions and also wine versions as
on newer wine the performance of psycle is much worse somehow..
So
I've chosen the way of porting psycle songs which use it's native
plugins into Neil. By now by hand and it's quite interesting
learning-wise.
This is the first song I've made:
https://soundcloud.com/deepxcode/ht-brain-cryIt
is completely sequenced and rendered in Neil using only pscycle
plugins. It works just fine as it uses about 10 machines in total.
But
when it came to the second song, which uses about 40 machines, it
becamse unable to play it! The CPU usage raised to 300% even when only
10 machines out of 40 were playing!
Strange thing, when I removed all of the unused machines for the current pattern, usage dropped to 10%!!
Also, when I only muted all of the machines, usage dropped to 60%.
This is not related to router view only, but any view!
There
definitely should be some bug regarding detecting of the idle state of
machines. I've started learning all of the possible related files and
here is what I have found already (you may also see this in my
Armstrong's issue link):
In file libneil/src/libzzub/song.cpp on
the line about 1290 there is the code (running each time after command
to process audio has been given to a plugin):
if (m.last_work_audio_result) {
if (scanPeakStereo(&m.work_buffer[0].front(), &m.work_buffer[1].front(), sample_count,
m.last_work_max_left, m.last_work_max_right, falloff)) {
// the plugin claims it has generated non-silence, but our scan says otherwise
m.writemode_errors++;
}
}
I have made a check of adding here a code of writing
m.writemode_errors
into a file. It has shown that the value gets increased for about a
thousand (1000) per second! This is after you would press play. When you
would press stop afterwards, this value would get increasing forever!!
Unless you would close the program or possibly load another file.
I
think this is very significant indication of the bug, but I still
haven't figured out, how it generally works: who (which file, line)
tells the plugin to play and decided if there is anything to play or no
according to the pattern. This seems to be able to improve and do not
use more than 10% of CPU if you have 40, 50 or 100 machines in the idle
state! I would repeat that this is very critical for me and I am
spending all my available time to study the files and gather the
information.
I have already contacted the original libzzub
developer Anders Ervik (calvin) on #buze IRC channel. People say he is
available often but no reply yet.
I have also checked for at least any documentation available over libzzub. And found only very little:
http://web.archive.org/web/20080727012344/http://doc.zeitherrschaft.org/pyzzub/This is from the former libzzub web site
http://web.archive.org/web/20081001113648/http://trac.zeitherrschaft.org/zzub/There is also a recent documentation for Armstrong available at Buze website:
http://batman.no/buze/developer/armstrong/index.htmlBut it seems to be very different: SQLite and everything..
When
I was writing this, I have got a reply in #buze channel were the
original libzzub developer resides and I'm still waiting for him to
suggest.
Someone there told me that this issue might be related to very known "denormals" problem.
I
have also talked in #psycle channel and it's developer, bohan,
confirmed that it might be this and added that they in psycle, take care
of this on the host level:
<bohan> in psycle's core, the output of a plugin is passed through a denormal/infinite/nan remover
Do we have things like this Neil?
Is there are LADSPA/DSS module for denormal removing?
And here is a little suggestion fro, #buze channel regarding the song.cpp:
ld0d>
b0tm1nd, well, you have to figure out if it's process_stereo() (which
should end up calling the plugin itself rather directly) or something
else that's taking so much time
<ld0d> b0tm1nd, because process_stereo should be rather directly a call to the plugin itself
<ld0d>
b0tm1nd, and if it's not that but the code after it, then the correct
way to fix it would be to move the scanPeakStereo() earlier and to clear
last_work_audio_result if the output is silent, and fix all the rest of
the code to use it
...
<ld0d> but it could be something else, so better analyze process_stereo() carefully first
I will remind that you can notice
this on any .ccm file availble! Just press play then stop and you will
see the CPU usage of machines which should not be!