Getting the integrated equalizer to work, from Debian Jessie, KDE 4.

I happen to have an older laptop, which I name ‘Klystron’, that is running Debian 8 / Jessie, with KDE 4 as its desktop manager. Don’t ask me why, but I tend to leave older builds of Linux running on some of my computers, just because they seem to be running without any deficiencies.

That laptop has lousy speakers. I decided a few days ago, that it would benefit, if I could get the 14-band graphical equalizer to work, that is generally available on Linux computers which, like that laptop, use the ‘PulseAudio’ sound server. However, on this old version of Linux, achieving that was a bit harder than it’s supposed to be. Yet, because I succeeded, I felt that I should share with the community, what the steps were, needed to succeed.

First of all, this is what the equalizer looks like, which I can now open on that laptop:

Equalizer_1

And it works!

 

In order to get this sort of equalizer working with PulseAudio, eventually, the following two modules need to be loaded:

module-equalizer-sink

module-dbus-protocol

And, if I gave the command ‘load-module…’ naively from the command-line, as user, because under my builds of Linux, PulseAudio runs in user mode, both these modules seem to load fine, without my having to install any additional packages.

On more recent builds of Linux, one needs to install the package ‘pulseaudio-equalizer’ to obtain this feature, or some similarly-named package. But, because these two modules just loaded fine under Debian / Jessie, I guess the functionality once came integrated with PulseAudio.

But I soon started to run in to trouble with these modules, and discovered why, then, the equalizer function was not set up to run out-of-the-box…

(Updated 6/26/2020, 10h30… )

Continue reading Getting the integrated equalizer to work, from Debian Jessie, KDE 4.

Changing the <Alt>+(LMB-Drag) behaviour of Linux, under the Plasma 5 desktop manager.

One of the realities of many graphics / editing applications is, that the action to drag either an object or one of its handles with a mouse, or with any other pointing-device, needs to be modified in several ways, depending on what, exactly, the user expects the application to do. I have recently encountered a Web-application, which therefore displays in a Web-browser, in which to hold down the Shift-Key while dragging the corner of a rectangle does one thing, holding down the Ctrl-Key while doing so does another, and holding down the Alt-Key performs yet-another action, which in this case was, to draw an ellipse instead of a rectangle. And in this Web-application, the ability to draw circles or ellipses would eventually become important.

The problem with any application that has this as one of the inputs it accepts, is that such applications were never designed with Linux in mind. The reason is the fact that, under Linux desktop-managers, to <Alt>+(LMB-Drag) gets intercepted, and has as effect to drag the entire application window. That Web-application never receives such a combination of inputs.

Fortunately, if the desktop-manager is one of the ‘Plasma 5′ sub-versions, there is a way to change that behaviour. It can be found under:

System Settings -> Application Style -> Widgets Style and Behaviour -> Applications Tab -> (Breeze Theme from Drop-Down) -> (To the right of the theme chosen from the Drop-Down) Configure… -> General Tab -> Windows’ drag mode -> (From the drop-down) ‘…Titlebar Only’.

That last drop-down is not wide enough to show its full text.

The reason this defaults to ‘Anywhere from within the window’, is a fear that might exist, that an application’s window could end up very-incorrectly positioned on the screen, and that a user might not be able to change that position, by the next time he starts the application. I.e., some applications remember their window-position from one session to the next, and it could be screwed up. If this behaviour is changed, <Alt>+(LMB-Drag) will only drag the window, and therefore be intercepted before it reaches the application, if the mouse-pointer can be positioned over the window’s title-bar.

Continue reading Changing the <Alt>+(LMB-Drag) behaviour of Linux, under the Plasma 5 desktop manager.

About the Frame-Rate of Hardware-Accelerated Animations.

One of the subjects which I’ve posted about before, is that in the case of typical hardware-accelerated animations, the frame-rate, which some people just know as ‘the FPS of the animation’, is actually lower than the refresh-rate of the monitor.

Well, if the user is running Plasma 5 as his desktop-manager – which is Linux-based – then he can open ‘System Settings -> Desktop Behaviour -> Desktop Effects’, and he will see a list of available compositing effects, that would all be hardware-accelerated, and under the section of ‘Tools’, there is an effect named ‘Show FPS’. Enabling that effect, and then clicking on ‘Apply’, will cause a piece of OSD information to display, that actually shows the frame-rate. The user will notice that it does not equal the refresh rate of his monitor.

But there is a catch to this. Often, the rendering software will place an upper limit on the frame-rate. Frame-rates actually higher than the refresh rate of the display device accomplish no useful purpose, and there used to be a simple, command-line test which Linux users could run, which was called ‘glxgears’. This would display a very simple animation, of a red, a green and a blue gear, rotating smoothly. In very early versions of this test-program, a frame-rate of something unreasonable, such as 2000 or maybe even 5000 FPS might result, which simply represents a waste of GPU power. The gears would still rotate at the same, correct apparent speed, but each frame-cycle would be fewer than 1 millisecond apart on average. Therefore, more-recent versions of this test-program will cap the frame-rate at the refresh rate of the monitor, and the gears will display as rotating at the same, smooth speed.

Dirk

 

An update on how to use Latte-Dock.

One of the features which I have posted about recently, is the Plasma 5 add-on called ‘Latte-Dock’. Specifically I wrote, How the user can install version 0.6.0 of this add-on, if it isn’t in the package repositories. What I had also written was, that a safe practice in using Latte-Dock would be, to keep the default Plasma 5 application-launcher in his panel, as a back-up, so that he will always have an application-launcher to click on, even if Latte-Dock crashes.

Well since then I have learned that a more avant-garde way exists to use Latte-Dock, which is, to place the default application-launcher onto the dock as well. This can easily be done because the default application launcher is a widget like any other, which can be dragged to this dock. As an additional detail, a method exists to get v0.6.0 of Latte-Dock to open the application launcher, by just pressing the Super Key, assuming that it has been added to the dock. The instructions I’ve just linked to do not count for later versions of Latte-Dock because those versions already have a check-box in their GUI, which does the same thing.

Hence, I’ve decided to be more progressive in my test-setup for Latte-Dock, and have also placed my only application-launcher onto this dock:

Screenshot_20190329_070015

There is one detail which the reader should note however. I have kept one quick-launcher in the upper-left-hand corner of the screen, in the Plasma panel: The launcher that restarts Latte-Dock from the GUI with one click. The reason I have kept this safeguard is the observation that Latte-Dock can still crash from time to time, which means that the user would be without an application launcher, until he or she gets to restart the dock.

But this way, the layout of that desktop is even more different from the Windows-like layout – common to Plasma 5 and KDE 4 – than it only was a few days ago.

Dirk