A New Set Of Headphones

As early as This posting, I had experimented with Bluetooth Headphones, that were specifically designed to handle High-Fidelity sound, for continuous music playback. But the fact is, that in the past 2 years, 3 such headphones failed me. The most-recent, ‘Infinim HBS-910′ set also failed on me, mechanically, only earlier this month, which effectively means that in total, if I continued doing things this way, I’d continue to burn through my money too fast.

So the course which I’ve chosen to go instead, is to use wired headphones, but to buy slightly-higher-quality, wired headphones, that are compatible with an Android device.

There once existed the observation, that the buttons on certain headphones would only work with iOS devices, and the buttons on other headphones would only work on Android-based devices. Interestingly enough, If the packaging doesn’t specify, then today, most headphones will work on either devices. My new Headrush HRB 3012 set has buttons which my Samsung Galaxy S6 recognizes.

(Edit 07/14/2018 : )

About these new ‘Headrush HRB 3012′ headphones:

Their cord consists of a ribbon, instead of the older-type, standard elastic, round-cross-section cords, which I was used to. I think that the current, ribbon design is a clever way to minimize any injuries which a headphone-cord can sustain, let’s say because users often pull the headphones out of their socket, by the cord instead of by the jack. The only way I foresee the ribbon-design getting injured, would be if somebody got a knot into it – and was then foolish enough to try to undo the knot, by just pulling it tight. And, because the ribbon tends to be more stiff, undoing knots correctly, has actually become easier.

There is one little issue with these though. Like the designs that I was used to, this set of headphones has a bump in its ribbon, which splits into two ribbons: One to the left ear, and one to the right ear. And in the segment of ribbon to the right ear, there is a remote-controller-button, inline-mike bump. When all the ribbons are (untwisted) parallel, and at right-angles to the wearer, the ribbon that goes to the right ear, has its mike facing away from the wearer, and has the controller-buttons facing towards the wearer.

As a result, I find myself twisting or rotating the right-hand ear-phone 360⁰ at the end of its ribbon-segment, thereby turning the inline-bump 180⁰, so that the inline-mike is again, facing towards me.

Dirk

 

Browsing Android Files using Bluetooth

One of the casual uses of Bluetooth under Android, is just to pair devices with our Android (host) device, so that specific apps can use the paired (slave) device. This includes BT-headphones, and many other devices.

But then a slightly more advanced use for BT under Android could be, that we actually send files to a paired Android device. It’s casually possible to take two Android tablets, or a tablet and a phone, and to pair those with each other. After that, the way to ‘push’ a file to the paired device, from the originating device, is to open whichever app displays files – such as for example, the Gallery app, if users still have that installed, or a suitable file-manager app – and to tap on ‘Share’, and then select ‘Bluetooth’ as what to share the file to. Doing this should open a list of paired devices, one of which should be suitable to receive a pushed file in this way.

But then, some people would like to take Bluetooth file-sharing up another level. We can pair our Android device – such as our phone – with a Bluetooth-equipped, Linux computer, which may be a bit tricky in itself, because the GUI we usually use for that assumes some legacy form of pairing. But eventually, we can set up a pairing as described. What I need to do is select the option in my Linux-BT-pairing GUI, which requires me to enter the pass-code into the Linux-GUI, which my Android device next displays…

And then, a question which many users find asking themselves is, ‘Why can’t I obtain FTP-like browsing capability, from my Linux-computer, over the files on the phone? Am I not giving the correct commands, from my Linux-computer?’

Chances are high, that any user who wishes to do this, is already giving the correct commands from his or her Linux-computer…

(Updated 06/03/2018, 20h45 … )

Continue reading Browsing Android Files using Bluetooth

How to Add a Web-browser to GNURoot + XSDL.

In This earlier posting – out of several – I had explained, that I’ve installed the Android apps “GNURoot Debian” and “XSDL” to my old Samsung Galaxy Tab S (first generation). The purpose is, to install Linux software on that tablet, without requiring that I root it. This uses the Android variant of ‘chroot’, which is actually also called ‘proot’, and is quick and painless.

However, there are certain things which a ch-rooted Linux system cannot do. One of them is to start services to run in the background. Another is, to access hardware, as doing the latter would require access to the host’s ‘/dev’ folder, not the local, ch-root’s ‘/dev’ folder. Finally, because XSDL is acting as my X-server, when GNURoot’s guest-software tries to connect to one, there will be no hardware-acceleration, because this X-server is really just an Android app, and does not really correspond to a display device.

This last detail can be quite challenging, because in today’s world, even many Linux applications require, direct-rendering, and will not function properly, if left just to use X-server protocol, à la legacy-Unix. One such application is any serious Web-browser.

This does not result from any malfunction of either Android app, because it just follows from the logic, of what the apps are being asked to do.

But we’d like to have a Web-browser installed, and will find that “Firefox”, “Arora” etc., all fail over this issue. This initially leaves us in an untenable situation, because even if we were not to use our Linux guest-system for Web-browsing – because there is a ‘real’ Web-browser installed on the (Android) host-system – the happenstance can take place, by which a Web-document needs to be viewed anyway – let’s say, because we want to click on an HTML-file, that constitutes the online documentation for some Linux-application.

What can we do?

Continue reading How to Add a Web-browser to GNURoot + XSDL.

How the Obsolescence of Dalvik Does Not Even Represent an Inconsistency

There was a development with Android, which slipped my attention, and which took place during or after the advent of Android 4.4 (KitKat).

In general, it has always been a fact that Android application-programmers were encouraged to write a kind of source-code, which was identical in its syntax to Java, and which was compiled by their IDE into a kind of bytecode. Only, for many years this language was not officially named Java, instead officially being named Dalvik for some time. Exactly as it goes with Java, this bytecode was then interpreted by a central component of the Android O/S (although, there exist computers on which the JVM is not central to the O/S).

This means, devs were discouraged but not forbidden, from writing their apps in C++ , which would have been compiled directly into native code. In fact, the Native Development Kit has always been an (optional) part of “Android Studio”.

But since Android 5+ (Lollipop), the use of this interpreter has been replaced with something called the Android Runtime (ART). This fact does not present me with much of an inconsistency, only a late awareness of progress.

Even when I was learning some of the basics of programming in Java, one piece of technology which had a name, was a so-called “Flash Compiler”. This was in fact distinct from a “JIT Compiler”, in that the JIT compiler would use the source-code, in order to compile parts of it into native code, while a flash-compiler would only need to use bytecode, in order to derive native code.

So, if the newer Android Runtime flash-compiles the bytecode, this does not change the fact, that devs are writing source-code, which is by default still Java, and initially being compiled by their IDE, into bytecode.

Clearly though, there is a speed-improvement in flash-compiling the bytecode and then executing the resulting native code, over interpreting the bytecode.


 

Yet, the speed-improvement which was once thought to exist in RISC-Chip CPUs, has largely vanished over the History of Computing. One original premise behind RISC-Machines was, that they could be made to run at a higher clock-speed, than Complex Instruction Set (CISC) Computers, and that due to this increase in clock-speed, the RISC-Machines could eventually be made faster.

In addition, early CISC-Machines failed to use concurrency well, in order to execute a number of operations simultaneously. By doing this, modern CISC-Machines also obtain low numbers of clock-cycles per instruction. But I think that this subject will remain in debate, as long as practical CISC-Machines have not exploited concurrency as much as theory should permit.

Since an optimizing compiler generally has the option of compiling source-code into simpler instructions, even when targeting a CISC-Machine, it would follow that realistic source-code needs to be compiled into longer sequences of RISC-Machine instructions.

This debate began before the days, when a CPU had become one chip. Since the CPU is by now a single chip, communication at the speed of light permits a CISC-Machine to have as high a clock-speed as a RISC-Machine. OTOH, the power consumption of a RISC Chip may still be slightly better.

And, as long as the CPU of Android devices only needed to execute a Bytecode Interpreter, this set of instructions could be optimized again, for the purpose of doing so, on a RISC-Machine. But, if we compare the speeds of modern RISC and CISC -Machines running optimized, native code – i.e., compiled C++ – I think it’s clear that the CISC-Machines, including the ones that were meant to run Windows or Linux on, outperform RISC machines.

(Edit 10/09/2017 : )

I believe that there exist specific situations in which a RISC-Machine runs faster, and that a lot of that depends on what language of source-code is being compiled. In the case of RISC-Machines, the compiler has fewer options to optimize the code, than it would with CISC-Machines.

Continue reading How the Obsolescence of Dalvik Does Not Even Represent an Inconsistency