I have been using Linux for 25 years, and used Unix for the
years before that. I never used Microsoft Windows. And I did not
use Blackboard until a late March, 2020 for teaching. I did not
have a video camera attached to my computer until then. So,
when CUNY changed to online teaching on March 19, 2020,
I was totally
unprepared. Blackboard said that my browser is unsuitable
for video conferencing since I don't have Java on my computer.
On both these counts, Blackboard had the wrong information.
I did have Java on my computer, and I was able to make
Blackboard videconferencing work on my computer. But not
without one and two glitches.
On the first day of video conferencing, on March 24, when students were talking there was a terrible echo, since the output of my speakers was picked up by the microphone of the video camera; to eliminate the echo, the students suggested that I use earphones, so as to silence my speakers. The problem was that I did not have earphones. During lunch break, I walked over to a nearby Staples (which was open, since most of the stores, such as a Best Buy, also nearby, were closed), and picked up earphones; there worked for the afternoon class and ever since.
I ordered my video camera on March 12, it was delivered on March 14, and I installed it on March 19, but it took me several hours to make the camera usable; when recording sound, the recording had a loud hiss. After a couple of hours of playing with audio parameters, I was able to eliminate the hiss, but I did not understand how I did it. Anyway, I was able to have a couple of video conferences, but on the morning of April 2, the audio hiss reappeared, and again it took me an hour and a half to work out the problem. I was unable to hold video conference for the first of my classes and for about 20 minutes into the second class. The third class in the afternoon went off without a hitch.
Note that this hiss is a common problem, and you can read about it if you google with the search words
except that most of the advice I read did not work.
Finally, after all my classes, I spent several hours
on the problems, and I figured out how to solve it.
The solution works reliably on my computer.
Typing the command
$ pavucontrol &
(the $ sign is the user command line prompt, you don't
type it), a window appears where the audio parameters
can be set. When clicking on Input Devices in the
top row, one can control audio input settings. On
USB Live camera Analog Stereo, the volume can be
set anything if it is loud enough so the recording
is audible. I use a setting about 100%, but 153%
also works -- but it probably makes me too loud
for the listeners. The video camera uses a USB 2
input.
The Monitor of Build-in Analog Stereo has to be set to 0 volume. Apparently, the hissing noise came from this not being set to zero. No microphone is plugged in, but apparently the Linux kernel does not realize that in this case the audio input on this channel should be automatically set to 0. Perhaps, in the next round of kernel upgrades this will be done automatically -- the reason this is not done is that it is probably not understood that this is the source of the hissing problem.
I was trying to set the audio input volume from the commandline rather than from GUI (Graphical User Interface), but I was not able to do it. Apparently, the command amixer cannot do it (I believe it should be able to do it, but maybe I cannot figure out the correct form of the command: I can use amixer to set the audio output volume). The commands pacmd and paclt should be able to do it, but I still need to understand their syntax, and I have very little time, what with writing notes for courses and thinking through various issues of online teaching. I would prefer to rely on command line rather than GUI commands, since the former are more reliable and can be put in scripts so as to execute them automatically.
Meanwhile, the GUI environment has its own problems. I would prefer to use a lean GUI environment, such as XFCE, but about a year a serious bug was introduced into XFCE: after the screensaver engages, I cannot wake up the computer (it does not respond to keyboard or or mouse clicks). The only way to wake it up is either through shutting it down by cutting power (seriously inadvisable, since before a shutdown, the sync command should be run as superuser, so as to synchronize the various memories, cache, RAM, and disk, so as not to lose information), or by logging in from another computer. So I reverted to KDE.
I have been avoiding the use of GNOME. The last time I checked, GNOME was able to give me four desktops (this may have changed since), while both KDE and XFCE is able to give me 20, which is the number I use (you can use each desktop to do different kind of work, open different windows). My version of Linux can support about 256 windows (they would not all fit on a single desktop). This seems ample, but there have been times I had to close some windows. The 256 number is not a hard limit; it can be changed, but I think in order to increase it the kernel needs to be re-compiled with the new limit. I did compile the Linux kernel at least once in the past, but it is a somewhat complicated operation, what with choosing all the options, so I prefer not to do it.
Meanwhile, KDE in its bloatedness has a terrible problem. It has a serious memory leak, meaning that when memory is no longer needed, it is not always freed; so, in time, it uses up almost all the memory allocated to it. Then everything slows down to a crawl. For example, you type the command pavucontrol to set audio parameters, and you have to wait for half a minute before the window opens, or you wait and wait and nothing happens. This is an untenable situation when you need to work with GUI. The solution is to stop KDE and then restart it:
$ killall plasmashell && kstart plasmashell
(The $ is the user prompt, not to be typed). This takes only a few seconds to run, and it does not interfere with any work. The taskbar disappears for a second, the background becomes black, but no work is interrupted, no windows are closed, and in a few seconds everything returns to normal).
Rather than running this command from the commandline regularly, it would be reasonable to schedule it regularly using the command cron, but there is a major difficulty. To get a lot of advice that did not work for me, you can google for
The problem is cron in userspace does not have enough permissions to run this command, yet the command needs to be run in user space so at the end the user has all the permissions to use his own environment. The solution was to run it as a superuser, while impersonating the user. As superuser, after typing
# crontab -e
(the symbol #, called octothorpe, or the pound sign, is the superuser prompt, not to be typed) opens the superuser crontab file. The line
32 4 * * * /home/mate/bin/bin1/restartk_cron
in this file runs the command on the line at 4:32 am every day (which is just as well, since I am not usually awake at that time). Here /home/mate is my home directory, and restartk_cron is the following script:
#!/bin/bash
# Tue Apr 7 12:41:26 EDT 2020
su - mate -c \
"xterm -display :0 -e \
/home/mate/bin/bin1/restartk"
# See
# https://forum.manjaro.org/t/plasma-5-why-am-i-still-seeing-it-totally-unresponsive/8527
Here, the first line indicates that this is a script using the bash shell (for Bourne Again Shell, a play of words on the older Unix shell called the Bourne Shell, still eminently usable). The lines starting with octothorpe # are comments and have no effect (except for the first line -- in this line the comment symbol is immediately escaped by the bang, or exclamation point, ! symbol, so that line does something). So the only thing this command does is to log in as mate (the superuser does not need a password to do this; if I were to run this command as user, I need to enter my password -- even though the command is in my own userspace), then opens a window to run the script restartk. Thing needs to be done this way, since when you run a script, you need to name the window from which you run it. For cron, this is difficult, since it does not know how to identify the windows already open; so the easiest way is for cron to open its own window in which to run the command. The window will close after the command finishes. Meanwhile, the command restartk has to be run as user; this is why cron had to login as mate.
Finally, the script restartk is as follows:
#!/bin/bash
# Tue Apr 7 12:41:26 EDT 2020
# su mate -
export DISPLAY=:0.0
killall plasmashell && kstart plasmashell
# See
# https://forum.manjaro.org/t/plasma-5-why-am-i-still-seeing-it-totally-unresponsive/8527
First, the script identifies the display with the DISPLAY=0:0 command, and then it kills and restarts plasmashell. All this has been tested to work reliably. I am not claiming that there is no simpler solution, but this one was the simplest I could find.
After this, I hope KDE will never slow down, but the future is not ours to tell. As in the English version of the song Que Sera, Sera (https://en.wikipedia.org/wiki/Que_Sera,_Sera_(Whatever_Will_Be,WillBe).
If you think it would be better to use Windows instead of Linux because KDE has a memory leak, see this: Microsoft server crash nearly causes 800-plane pile-up.
Last updated: Sun Apr 12 18:52:19 EDT 2020.