Why OpenShot will Not Run on my Linux Tablet

In This earlier posting, I had written, that although I had already deemed it improbable that the sort of Linux application will run on my Linux tablet, I would nevertheless try, and see if I could get such a thing to run. And as I wrote, I had considerable problems with ‘LiVES’, where, even if I had gotten the stuttering preview-playback under control, I could not have put LiVES into multi-tracking mode, thereby rendering the effort futile. I had also written that on my actual Linux laptop, LiVES just runs ~perfectly~.

And so a natural question which might come next would be, ‘Could OpenShot be made to run in that configuration?’ And the short answer is No.

‘OpenShot’, as well as ‘KDEnlive’, use a media library named ‘mlt’, but which is also referred to as ‘MeLT’, to perform their video compositing actions. I think that the main problem with my Linux tablet, when asked to run such applications, is that it is only a 32-bit quad-core, and an ARM CPU at that. The ARM CPUs are designed in such a way, that they are optimal when running Dalvik Bytecode, which I just learned has been succeeded by ART, through the interpreter and compiler that Android provides, and in certain cases, at running Codecs in native code, which are specialized. They do not have ‘MMX’ extensions etc., because they are RISC-Chips.

When we try to run CPU-intensive applications on an ARM CPU that have been compiled in native code, we suffer from an additional performance penalty.

The entire ‘mlt’ library is already famous, for requiring a high amount of CPU usage, in order to be versatile in applying effects to video time-lines. There have been stuttering issues, when trying to get it to run on ‘real Linux computers’, though not mine. My Linux laptop is a 64-bit quad-core, AMD-Family CPU, with many extensions. That CPU can handle what I throw at it.

What I also observe when trying to run OpenShot on my Linux tablet, is that if I right-click on an imported video-clip, and then left-click on Preview, the CPU usage is what it is, and I already get some mild stuttering / crackling of the audio. But if I then drag that clip onto a time-line, and ask the application to preview the time-line, the CPU usage is double what it would otherwise be, and I get severe playback-slowdown, as well as audio-stuttering.

In itself, this result ‘makes sense’, because even if we have not elected to put many effects into the time-line, the processing that takes place, when we preview it, is as it would be, if we had put an arbitrary number of effects. I.e., the processing is inherently slow, for the eventuality that we’d put many effects. So slow, that the application doesn’t run on a 32-bit, ARM-quad-core, when compiled in native code.

(Updated 10/09/2017 : )

Continue reading Why OpenShot will Not Run on my Linux Tablet

Getting Some Software To Run On My Linux Tablet, which Was Not Meant To Run

One of the computing adventures which I’ve been blogging about, is that I’ve been able to install a Linux Guest System, under the Android Host System, on my Samsung Galaxy Tab S, First-Generation tablet. I use the two Android apps, ‘GNURoot’ and ‘XSDL’, which can be obtained from Google Play, and which do not require root.

In this posting, I had as a message to my readers, that certain types of Linux applications are poor candidates for this sort of environment – a chroot-Linux-Shell, that connects externally to an X-server, which in turn seems to provide pure X-server protocol as well as a port, to connect PulseAudio clients to.

But in the same posting, I had named a specific Linux-application, which would solve each of the two purposes, and which in my opinion at the time, might have the best chances to run – assuming that any have a chance to run:

  1. ‘mhWaveEdit’
  2. LiVES

As some of my readers might expect, since that posting, I have nevertheless pressed ahead, and experimented with installing each of these Linux-applications, on the guest-system.

Long story short, I found that mhWaveEdit seems to work fine, and installed effortlessly, while LiVES does not.


One observation which I’ve made, is that the PulseAudio server built-in to the Android app ‘XSDL’, offers sound output, but not sound input. Hence, I cannot connect to the mike, which is built-in to the tablet. But this is a very minor issue, since I’ve exceeded typical usage-scenarios in what I’ve already been able to do.

Continue reading Getting Some Software To Run On My Linux Tablet, which Was Not Meant To Run

The Sort Of Software that will Not Run, on my Linux Tablet

In this posting I wrote, that I had installed Linux in a chroot-environment, on my old Samsung Galaxy Tab S, First Generation tablet, which remains an Android-based tablet. I did this specifically using the apps from the Google play store, named ‘GNURoot’ and ‘XSDL’, which do not require root.

Here, I gave a compendium of Linux-applications which do run in the resulting Linux guest-system.

I think that I need to point out a broad category of Linux applications that will always remain poor choices:

  • Audio Editors,
  • Video Editors.

The problem with any Audio Editor, is that it will eventually need to input and output Audio – not just edit sound files – and any Video Editor, needs to give a preview of all its video-clips – not just edit video files. This seems like a silly thing to write, but is non-trivial in my present context.

I have taken a Linux engine – GNURoot – and connected it to an externally-supplied X-server emulation – XSDL. The pipeline between these two Android apps is very narrow. It consists of X-server protocol – which is excellent and rendering text and GUIs, of shared memory at its maximum, and of a PulseAudio server, visible on the Linux side as such, but collectively running on the Android side as an SDL client.

I have no way to provide OpenGL or SDL on the Linux-side. What this means, is that virtually any non-linear video editor will want to see both installed on the Linux side, while neither is provided.

Continue reading The Sort Of Software that will Not Run, on my Linux Tablet

I have now installed ‘xine’ on my Linux tablet.

In this earlier posting, I had written that I’ve installed Linux on an older tablet of mine, that being my Samsung Galaxy Tab S, First Generation, with only 16GB of storage.

In order to do so, I used the (non-rooted) applications from Google Play, ‘GNURoot’ and ‘XSDL’.

One feature which the author of ‘XSDL’ pointed out, is the fact that we may download a shared library to run under Linux, which when preloaded, makes the shared-memory extension available, for the purpose of running one application. By default pure X-server protocol does not have this, even though any half-decent Linux system has shared memory extension, X-Video extension, and beyond that, ‘vdpau‘, to allow fast video playback.

One Linux application which I had been using this way, was ‘gnome-mplayer’ , for which I had also written a shell-script, that preloads the shared-memory library. The video-player application was launching and running fine, but I’m no longer convinced that it was ever benefiting from shared memory. More specifically, we can set in the preferences of the player application, to use ‘X11′ as its video output-mode, and ‘pulseaudio’ as its audio output-mode.

Literally, selecting X11 in this way, does not mean shared memory as the output-mode, although the player could have bee negotiating with the (fake) X-server over this parameter…

So. To make sure I’d be obtaining the full benefit of shared memory, when playing back video-streams more seriously, I next proceeded to install ‘xine-ui’. It is highly-configurable, in that we can choose shared memory video-output explicitly.

Continue reading I have now installed ‘xine’ on my Linux tablet.