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
