Hi, Just checked the CPU usage again as running the AgsDrum sequencer, during playback the usage goes down to 80 %.
I think with a small patch we can fix this behavior. regards, Joël On Thu, Nov 28, 2019 at 4:26 AM Joël Krähemann <jkraehem...@gmail.com> wrote: > > Hi, > I take your complain about CPU usage serious. I intend to target it > in GSequencer v2.4.x > > The high CPU usage is due to AgsThreadPool providing non-blocking > calls to AgsTaskThread. > > But I don't see any way to provide it to buster. > > If you are interested in what is going on related to the thread API, > here are further informations: > > http://savannah.nongnu.org/forum/forum.php?forum_id=9601 > > sorry, > Joël > > On Thu, Nov 28, 2019 at 3:26 AM Joël Krähemann <jkraehem...@gmail.com> wrote: > > > > Hi, > > Yes, it is true. GSequencer consumes too much power as doing no audio > > processing. > > This was targeted with next major release v3.0.0 expected available > > within a half year. > > > > To change this behavior, I had to refactor the threading API of > > GSequencer. Currently > > it creates many threads without running any audio processing. > > > > The thread pool is the main cause for this, which is used by AgsTaskThread. > > > > In GSequencer v3.0.0 the AgsTask objects are launched in GMainContext. But > > for > > now they run asynchronous exclusive and are added by a non-blocking call. > > > > > > On Thu, Nov 28, 2019 at 2:00 AM westlake <westlake2...@videotron.ca> wrote: > > > > > > Here when I use gsequencer, (pasuspender not needed) > > > LADSPA_PATH="" DSSI_PATH="" LV2_PATH="" gsequencer > > > > > > I can run skipping the plugin-scan, I can get the graphical interface > > > within a second... > > > > > > dragging the window skimps as this app is not throttling it's cpu > > > utilization correctly.. > > > > > > When using "top", the app is using 300%... > > > > > > The limits setting /etc/security/limits.conf:: > > > (for security limits.conf, I comment-out everything in > > > /etc/security/limits.d/ to keep the configuration easier to read) > > > "" > > > * hard core 0 > > > * hard nofile 1048576 > > > * hard rtprio 95 > > > * - memlock unlimited > > > * - msgqueue 65536 > > > * - nice -19 > > > * - nice -20 > > > * - rttime 100000 > > > * soft core 0 > > > * soft nofile 1048576 > > > * soft rtprio 95 > > > @users - priority 0 > > > "" > > > > > > changed rtprio to 35, and "top"(command) still says gsequencer is using > > > 300% even after reboot. > > > "* hard rtprio 95 > > > * soft rtprio 95" > > > "* hard rtprio 35 > > > * soft rtprio 35" > > > > > > > > > The observation when rtprio is set at 95-> majority of threads go at > > > FIFO 95. [ screenshot provided ] > > > > > > The observation when rtprio is set at 35-> all threads are set to > > > SCHED_OTHER and only one gets set at FIFO with priority 20. > > > > > > 'jack' for both rtprio cases in ags' settings, 1 reboot with the > > > different rtprio settings. So the rtprio gets set aggressively with 95, > > > but barely nothing set with 35. << buggy. > > > > > > More buggy because with both rtprio settings the cpu is still at 300%. > > > > > > --> ags should be down at 2-5% when it is not doing any work. > > > > > > When I look at an RT-driven application such as ardour, while it runs it > > > does spike in cpu it immediately goes back down to 5%. > > > > > > ..also the rt-safe option in ags doesn't do anything. cpu% is still > > > spiked high.. > > > > The RT-safe option does reduce the calls to malloc(). > > > > > > > > Other observation: > > > When ags is set at alsa, the cpu% is lower but it is still very high at > > > 110%. > > > > > > The threads with the alsa setting show 0.3% cpu utilization instead of > > > 10% when ags is set to jack.. the "main" process I suppose is the one > > > that is always going 100+% for both alsa and jack cases. > > > > > > quick summary:: > > > Alsa (top without -H) --> 110% > > > Jack (top without -H) --> 300% > > > > > > When it says 100+%, ags is using more than 1 core.. > > > > > > With jack, 3 cores are now bogged down.. That tells me there is > > > something very wrong. > > > > > > I can now see what is happening... there's a bug because gsequencer is > > > doing no work but it polls the cpu at 100%-300%... > > > > There many threads running. Especially AgsThreadPoll creates some > > threads that might be used. > > > > > > > > The cpu% is still grabbed even when I change kernel.sched_rt_runtime_us > > > = 950000 to 500000 > > > > > > so there's a serious violation of scheduling policy happening here with > > > RT kernels for this software. > > > > What scheduling policy are you talking about? > > > > > > > > .. > > > I also don't know what makes you think pulseaudio is being used, here I > > > have it masked under ~/.config/systemd/user .. Jackdbus here is also > > > not handled by the dbus-auto-activation,... > > > > > > ~/.local/share/dbus-1/services/org.jackaudio.service > > > " > > > [D-BUS Service] > > > Name=org.jackaudio.service > > > > > > SystemdService=dbus-org.jackaudio.service > > > " > > > > > > ~/.config/systemd/user/dbus-org.jackaudio.service -- allows the user to > > > enable/disable jackdbus and whether to have it auto-start or not.. This > > > is user-defined startup unit file and is what I use here to stop jack as > > > needed. > > > > > > pulseaudio cannot be autostarted because it is masked.. > > > > > > ls ~/.config/systemd/user/ > > > pulseaudio.service -> /dev/null > > > pulseaudio.socket -> /dev/null > > > > > > things in ~/.config/systemd/user override things in /usr/lib/systemd/user/ > > > /usr/lib/systemd/user/pulseaudio.service > > > /usr/lib/systemd/user/pulseaudio.socket > > > > > > there may be a "pulse" entry in "aplay -L", but its a dormant entry as > > > "pgrep -fa pulseaudio" and "pacmd" do not show no pulseaudio ever gets > > > loaded... > > > > > > For security/audit team: > > > Ags-> 2 megabytes, uses 300% of the cpu cores. > > > Ardour-> a 100+ megabyte application uses just 5%. > > > > > > > What makes you think memory usage has anything to do with CPU > > consumption? > > > > > This package severely ignores scheduling restrictions. --- its' the only > > > RT audio application on debian that violates and ignores settings in > > > both /etc/security/limits.conf and /etc/sysctl.d/ for > > > kernel.sched_rt_runtime_us. > > > > So you think I should parse these files? > > > > > > > > This package may be better to have removed for now, as it seriously > > > violates scheduling of the kernel. Possibly more than just rt-kernels. > > > > > > > I see no reason for this. > > > > > thanks
