## About a minor (Home-Screen) nuisance I’ve experienced on Android deviceS.

I have owned several Android-based devices, and some of those were purchased from Samsung, those being:

• A Galaxy Tab S, First Generation,
• (An earlier Smart-Phone),
• A Galaxy S6 Smart-Phone,
• A Galaxy S9 Smart-Phone.

A feature which all these devices have, is the Touchwiz Home-Screen (program). This is the default of what the devices display, when not displaying a specific app, when not displaying the app drawer, and when not displaying ‘Bixby’ (most recently). An unfortunate behaviour of the devices is, that Touchwiz will sometimes crash. In my experience, when it does, this is no big deal, because it restarts automatically, and after a few minutes, even my Notification-Bar Entries will reappear. If certain apps fail to make their notifications reappear by themselves, then launching those apps from the application groups will make their notifications reappear.

I tend to rate each Android device, according to how rarely its Home-Screen will crash in this way. According to that, my Google Pixel C Tablet fared better because its home-screen has never crashed on me. My S9 Phone fared almost as well, in that Touchwiz seldom crashed. But now I think I’ve identified a situation which will frequently cause Touchwiz to crash on the S9 Phone.

Firstly, as I’m writing this, the firmware on that phone is at its latest version, that being the October 1 patch, of 2019, of Android 9.

I discovered that I can trigger this situation, as I was experimenting with the Super-Slow-Mo camera recording mode, in which the camera can record up to 0.4 seconds of video at 960FPS, at a resolution of 1280×720. When the camera does this, it generates a 20MB video, after that has been compressed via a standard H.264 CODEC into an .MP4 container-file. I have the default set, to record all camera footage to the external Micro SD Card. Having recorded the super-slow-mo video once, triggered this behaviour.

There is a simple way to interpret what has caused this, that does not seem to lay any blame on Samsung: When the camera is recording video that fast, it’s generating data faster than the external SD Card can store it. Therefore, the data takes up RAM, until some later point in time, when the O/S has transferred the data to the SD Card, by writing it out. This moment was reached several seconds later.

Here’s where the news gets a bit worse. I can download This 3rd-party app, that’s designed to test what speed of external SD Card I have. The reason I need to do this is the fact that I never seem to remember exactly what type of SD Card I purchased, for use with one specific device.

According to this app, my external SD Card can be written to sequentially at ~12MBytes/Sec. That makes it a Class 10 card. Yet, 20MB of data are to be stored in 0.4 seconds. In fact, simply running the benchmarking app caused a second Touchwiz crash, which was just as inconsequential as the first, that I was trying to investigate. What this seems to suggest is, that virtually no SD Card that I can buy, can really be fast enough to be written to at the speed with which the camera app can generate its data. The camera app will need to cache its footage in RAM, before that footage has been written to the SD Card.

Further, the footage is certainly being stored in RAM in an uncompressed form of data (384 raw frames), while what’s to be written to the SD Card is finally compressed. (:1)

And yet, either of these two apps will cause the Touchwiz crash. Hmm… I think that for the moment, I’ll just hold my horses, and record a maximum of 0.2 seconds of Super-Slow-Mo. Thankfully, this is a parameter that I can choose, with the little icon in the upper-right-hand corner of the view, before shooting.

(Updated 11/17/2019, 12h10 … )

## A problem that seems to exist in modern manufacture of metals.

There exists a problem in how modern facilities manufacture pieces of metal, which I know was real in one example that I can remember. This example was one in which “Stainless-Steel Ice Cubes” were meant to be kept in a freezer, and later put into drinks to cool them off, without ever diluting the drinks, due to melting ice for example.

When I purchased a set of stainless-steel ice cubes years ago, what I noticed was that they had an invisible film of residue on them, from the manufacturing process. I noticed this film, because touching it would irritate my skin. So what I needed to do was, to put those ice cubes through my dishwasher, after which they no longer irritated my skin from being handled, and after which they were also safe to plunk into drinks.

The fact that they had such a residue actually implies, that the people in charge of the manufacturing process do not understand what the machines are doing. After all, if these stainless-steel ice cubes are meant to be put into drinks, then it’s actually a part of the design objective that they not have any toxic residue on them, or, that the customer be warned in a way that can’t be misunderstood, that he or she needs to put them through the dishwasher before using them.

And I suspect that this problem is more prevalent with the way modern countries produce stainless-steel, resulting in low greenhouse gas emissions, than it would have been using old-fashioned methods of working steel. After all, nobody seems to recall this problem from ‘the old days’ of steel manufacture.

But the exact same problem can take place, if other types of metal are being mass-produced. For example, if a 3.5mm headphone jack is being manufactured with copper surfaces, and if the process is skipped, which would normally be standard, to gold-plate those copper surfaces, then those surfaces could also end up with an invisible residue from the manufacturing process. If that happened, the next problem would be that the 3.5mm jack fits into its socket snugly, but that a proper connection does not form, so that sound output from the headphones may initially be muffled.

The reason why sound reproduction would be affected would be the fact that such a film would effectively place a resistor with unknown resistance in series with the headphones. And the problem with that would be, that headphones and loudspeakers do not have exactly the same resistance at every frequency. The resistance of such devices is actually referred to as their “impedance”, and gets lower for the highest and lowest audible frequencies. In the mid-range, those devices probably have considerably more than 8Ω, which their impedance probably comes down to, at the outermost frequencies. What this means is that during normal operation, headphone-drivers and speakers will draw more current at the highest and lowest audible frequencies, in order to result in a frequency-response that’s reasonably flat. Therefore, if the value of series resistance is any greater than 4Ω, the voltage actually appearing at the voice-coils will collapse at these frequencies, and sound output will become noticeably abnormal.

If somebody suspects that they have a headphone jack which is doing this, the only good advice would be to use a dry cloth, and to wipe any invisible residue off it.

My reader should be aware that I can’t be 100% sure, that the second case, of the headphone jack, was a real experience of mine. This may have happened to me, when I tested a new set of earbuds for the first time. But only hours later, that set of earbuds worked flawlessly, and continued to do so ever since. Of course, if there ever was any residue on its headphone jack, that could just have rubbed off outside my being aware of it, however silly that sounds.

In general, I’d say that I need to have observed such manufacturing deficiencies at least twice, before concluding that there’s a pattern to them.

Dirk

## Power Failure Today, Downtime

I take the somewhat unusual approach of Hosting my Web-site and blog, on a PC at home. I’m not saying that this is what everybody should do; this is just how I do it. Unfortunately this means that the visibility of this blog is only as good as the reliability of the PC in question, and of my Internet connection.

Today, the city I live in experienced violent wind-gusts, which I’d estimate had wind-speeds of over 100 km/H. This caused a power failure around 9h00 this morning. And, even though that power failure only seemed to last about 15 minutes, I did not reboot my computers immediately, because of the possibility of yet another power failure. The winds continued to gust this way until about 17h00 today.

As a result, this site and blog were down from about 9h00 until about 17h50.

I apologize for any inconvenience to my readers.

Dirk

## PulseAudio Restart Bug – Solved

I enjoy my Linux computers, and one reason is the fact that many technical issues can be resolved, without having to reboot endlessly. However, in my past usage, there has been an irritating exception to this pattern. It’s common under Linux, that we can simply restart the PulseAudio Server from the command-line, using one out of several methods, and that the subject should be done with. But alas, every time I have ever restarted PulseAudio in this way, or, if the server restarted on its own, afterwards, when looking up the Plasma 5 -generated status display (which is actually referred to as “Phonon”), I’d be missing a Devices List, like so:

This type of display can be interpreted to mean several things, such as, that the PulseAudio server did restart, but that perhaps, it simply failed to connect to the inter-process, session-unique, message-bus. Therefore, in the past, whenever I had such a display, I eventually did what I thought I had to do, which was, to log out and back in again, or, to reboot. On my system, PulseAudio is configured such, that it runs as one user-name, and not as root.

In fact, a peculiar side effect of this bug was, that the list of available output devices was still being displayed, within ‘pavucontrol‘.

But this ordeal has now become even more inconvenient than it ever was because on the computer which I name ‘Phosphene’, the need may recur more frequently, ‘just to restart the PulseAudio server’.

However, I have finally found the true cause for this malfunction, which was, that when PulseAudio is restarted from within an existing session, it simply fails to load one module, which is also the module that it needs, in order to be able to list the available devices:


module-device-manager



In fact, there exists a script in ‘/usr/bin‘, that loads a series of X11-related modules.

Therefore, after a restart of this service, I can simply give the following command now:


/usr/bin/start-pulseaudio-x11



And Eureka! I can now obtain a list of available devices, without ever having to log out and back in, or, without ever having to reboot:

In fact, I have created a shell-script, which I can click on as user, and which carries out this task, safely.

I’ve also discovered that the ‘ProjectM’ music visualization application still works, and detects the beat of the playing music as before. What this means is that theoretically, after ‘ProjectM’ was installed, instead of rebooting, I could have just restarted the PulseAudio server as described here, to get that working.

( Edited 2019/10/29, 23h35 … )

I know that there exists an unrelated problem, that just happens to give the same appearance within ‘Phonon’, but that cannot be resolved in this way…