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:
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.
Further, I’m still asking myself what goes wrong with LiVES. When we install it, the package dependencies insist on installing a PulseAudio server to the Linux environment, even though it could be my intention just to connect to the external one, provided by ‘XSDL’. Otherwise, LiVES refuses to use PulseAudio as its sound-output.
But when I run LiVES, the GUI starts up fine, and also guides me through some initial configuration steps. Yet, when I next load a video-clip and try to preview that, the playback stutters – at a rapid rate of short bursts.
This is not entirely unexpected, but I’m still having thoughts as to whether it could be corrected. Because I’m assuming that the developers of LiVES made no programming errors, I would need to find, where my jury-rigged configuration is failing, before I could get the latter application to work.
(On my Linix laptop named ‘Klystron’, this application works 100%, even in Multi-Tracking Mode, because that would be a so-called ‘real Linux system’. )
It currently offers me three (Video) Output-Modes (on the Linux tablet):
- SDL (Accelerated with Shared Memory.)
- yuv4mpeg_stream (Due to ‘mjpegtools’ being installed.)
(Edit : )
Since my last update, I’ve learned a few more things about LiVES in this configuration. One fact seems to be, that if I use the preloaded library to offer shared-memory support, doing so does in fact improve the speed with which the Video-Output-Plug-Ins render video. This is the first proof I’ve received, that Linux applications will use shared memory, even though according to the GUI, no explicit mention may be made of it.
But the Audio-Stuttering won’t stop. Some references suggest that this behavior is ‘normal’, if the PulseAudio Client is assuming a sample-rate of 44100Hz, while the PulseAudio Server is running at 48kHz. But even if I resample the Audio – Successfully – to 48kHz, the stuttering still doesn’t stop.
(From what I can tell, the CPU on my tablet just isn’t strong enough to run this type of software. )
And I’ve made a discovery about LiVES in this configuration, which is worse than what I knew before: If I tell it to go from Clip Editing Mode into Multi-Tracking Mode, LiVES just crashes my whole LXDE desktop. And the Video-Editor is useless, unless we can eventually go into Multi-Tracking Mode.