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
