Power Failure Today, Downtime

I take the unusual approach of hosting this blog and site, on a server, that is running on my personal computer at home. I don’t recommend that everybody do it this way; this is only how I do it. That makes the availability of my blog and site no better, than the reliability with which I can keep my PC running, as well as that, of my Internet connection.

Unfortunately, I experienced a brief power failure this morning, between 8h45 and 9h00. As a result, this site was down until about 9h40. I apologize for any inconvenience to my readers.

BTW, There have been remarkably few failures in the recent 3 months or so.

Dirk

 

Samsung’s Auto Hot-Spot Feature

I own a Samsung Galaxy S9 smart-phone, and have discovered that, in its tethering settings, there is a new setting, which is named “Auto Hotspot”. What this setting aims to do if activated is, on other Samsung devices, which normally only have WiFi, when the user is roaming along with his phone, there should appear an additional access point for them to connect to. The following screen-shots show, where this can be enabled on the phone

Screenshot_20201220-072343_Settings_e

Screenshot_20201220-072354_Settings_e

Screenshot_20201220-072404_Settings_e

Screenshot_20201220-072414_Settings_e

I believe that this explains a fact which I’ve already commented on elsewhere, which is, that when I try to set up Google Instant Tethering, the negotiation between my ‘Asus Flip C213 Chromebook’ and this phone, no longer adds Instant Tethering to the list of features which are enabled. My Samsung S9 phone will now only unlock the Chromebook. What I am guessing is that, because the feature I’m showing in this posting is a Samsung feature, with which Samsung wants to compete with the other companies, Samsung probably removed to offer Instant Tethering from their phone.

Obviously, this is only a feature which I will now be able to use, between my S9 phone, and my Samsung Galaxy TAB S6 tablet.


 

 

The reader may ask what the advantages of this feature might be, over ‘regular WiFi tethering’, or ‘a WiFi hotspot’. The advantage could be, that even though it remains an option compatible with all clients, to have the phone constantly offer a WiFi hot-spot could drain the battery more. Supposedly, if Samsung’s Auto Hotspot is being used, it can be kept enabled on the phone, yet not drain the battery overly, as long as client devices do not connect. The decision could then be made directly from the client device, whether to connect or not… This is similar, to what Google’s system offers.

Also, the Samsung phones with Android 10 have as feature, that their ‘regular hotspots’ will time out, say after 20 minutes of inactivity, again, to save battery drain. Yet, if the user is carrying a tablet with him that has been configured to connect to the mobile hotspot Automatically, the phone which is serving out this hotspot will never detect inactivity.


 

Further, I’ve been able to confirm that, as long as I have Auto Hotspot turned on on my phone, indeed it does not show up as an available WiFi connection, on devices that are not joined to my Samsung account. This is as expected. But it also adds hope that, as long as I don’t connect to the phone’s Auto Hotspot from another device, the battery drain due to my leaving this feature enabled on my phone constantly, may not be very high. I will comment by the end of this day, after having left my phone with its own WiFi Off, which means that my phone will be using its Mobile Data, but, not connecting my Samsung TAB S6, whether doing this seems to incur any unusually high amount of battery drain, on the phone…

 

Continue reading Samsung’s Auto Hot-Spot Feature

How to route a USB MIDI Keyboard to a JACK-MIDI Input, under Debian.

One of the possessions which I have is a USB MIDI Keyboard, which I’d like to be able to play, so that my computer’s software synthesizers actually generate the sound…

dsc_0001 email

I know that this can be done because I’ve done it before. But in the past, when I set this up, I was either using an ‘ALSA’ MIDI input, belonging to an ‘ALSA’ or ‘PulseAudio’ application such as “Linux Multimedia Studio”, or I was using ‘QSynth’, which is a graphical front-end to ‘fluidsynth’, but in such a way that QSynth was listening for ALSA MIDI, and outputting JACK audio. This is actually a very common occurrence. I can switch between using the ‘PulseAudio’ and using the ‘JACK’ sound daemon, through a carefully set-up configuration of ‘QJackCtl’, which suspends PulseAudio when I activate JACK, and which also resumes PulseAudio, when I shut down JACK again.

But there is a basic obstacle, as soon as I want to play my MIDI Keyboard through ‘Ardour’. Ardour v6 can be run with the PulseAudio sound system, but only for playback, or, Ardour can be run with its JACK sound back-end, after JACK has been launched. Ardour cannot be run with its ALSA back-end, when PulseAudio is running.

The default behaviour of the Debian kernel modules, when I plug in a USB MIDI Keyboard, is, to make that MIDI connection visible within my system as an ALSA MIDI source, even though some applications, such as Ardour, will insist on only taking input from JACK MIDI sources, when in fact running in JACK mode. And so, this problem needed to be solved this morning…

Screenshot_20201206_091955

The solution which I found was, to feed the Keyboard, which happens to be an “Oxygen 61″, to the ‘MIDI Through Port’ that’s visible in the ALSA Tab of QJackCtl’s Connections window. When MIDI sequences are fed there, they are also output from the System JACK MIDI sources, visible in the MIDI Tab of QJackCtl’s Connections window:

Screenshot_20201206_092022

Screenshot_20201206_092039

I should also note that, in many cases, the JACK clients can ask the JACK sound daemon to be connected to various inputs and outputs from within, without absolutely requiring that the QJackCtl Connections window be used. This explains why the audio output of Ardour was already routed properly to my PC’s speakers. But I found that I could only keep track of the MIDI connection, through QJackCtl’s Connections window. As the screen-shots above show, the second step is, to feed one of the System Sources to the appropriate Ardour MIDI input, in the MIDI Tab of QjackCtl’s Connections window.

The result was, that the synthesizer which I have available as an Ardour plug-in, played beautifully, in response to my pressing keys on the actual MIDI Keyboard, and no longer just, when I clicked on the graphical keyboard within the Ardour application window:

Screenshot_20201206_092206

This on-screen keyboard can be made visible, by double-Alt-Clicking on the icon of the instrument, with Ardour in its Mixer view, and then expanding the resulting windows’ MIDI Keyboard fly-out. Yet, the on-screen keyboard was only useful for setup and testing purposes.

Tada!

 

(Updated 12/07/2020, 17h20… )

Continue reading How to route a USB MIDI Keyboard to a JACK-MIDI Input, under Debian.

How to compute the sine function, on a CPU with no FPU.

There exists a maxim in the publishing world, which is, ‘Publish or Perish.’ I guess it’s a good thing I’m not a publisher, then. In any case, it’s been a while since I posted anything, so I decided to share with the community some wisdom that existed in the early days of computing, and when I say that, it really means, ‘back in the early days’. This is something that might have been used on mini-computers, or, on the computers in certain special applications, before PCs as such existed.

A standard capability which should exist, is to compute a decently accurate sine function. And one of the most lame reasons could be, the fact that audio files have been encoded with an amplitude, but that a decoder, or speech synthesis chip, might only need to be able to play back a sine-wave, that has that encoded peak amplitude. However, it’s not always a given that any ‘CPU’ (“Central Processing Unit”) actually possesses an ‘FPU’ (a “Floating-Point Unit”). In such situations, programmers back-when devised a trick.

It’s already known, that a table of pre-computed sine functions could be made part of a program, numbering maybe 256, but that, if all a program did was, to look up sine values from such a table once, ridiculously poor accuracies would initially result. But it was also known that, as long as the interval of 1 sine-wave was from (zero) to (two-times-pi), the derivative of the sine function was the cosine function. So, the trick, really, was, to make not one lookup into the table, but at least two, one to fetch an approximate sine value, and the next, to fetch an approximate cosine value, the latter of which was supposedly the derivative of the sine value at the same point. What could be done was, that a fractional part of the parameter, between table entries, could be multiplied by this derivative, and the result also added to the sine value, thus yielding a closer approximation to the real sine value. (:3)

But, a question which readers might have about this next could be, ‘Why does Dirk not just look up two adjacent sine-values, subtract to get the delta, and then, multiply the fractional part by this delta?’ And the answer is, ‘Because one can not only apply the first derivative, but also the second derivative, by squaring the fractional part and halving it (:1), before multiplying the result from that, by the negative of the sine function!’ One obtains a section of a parabola, and results from a 256-element table, that are close to 16 bits accurate!

The source code can be found in my binaries folder, which is:

https://dirkmittler.homeip.net/binaries/

And, in that folder, the compressed files of interest would be, ‘IntSine.tar.gz’ and ‘IntSine.zip’. They are written in C. The variance that I get, from established values, in (16-bit) integer units squared, is “0.811416” “0.580644” (:2). Any variance lower than (1.0) should be considered ‘good’, since (±1) is actually the smallest-possible, per-result error.


(Updated 12/04/2020, 11h50… )

Continue reading How to compute the sine function, on a CPU with no FPU.