Technical Impediment In Getting Sound From My Linux Tablet (Solved)

One of the facts which I’ve blogged about is, that I have a Linux Guest System installed on the Android Tablet, that’s a Google Pixel C.

Another fact which I blogged about a long time ago was, that I am able to share the PulseAudio Sound Server that resides on the computer now named ‘Phosphene’, for use by the client computer I name ‘Klexel’.

A basic limitation to my Linux Tablet remains, that it isn’t suited to play back audio streams, or video streams that have audio, because inherently, I’m just running its Linux Guest as a VNC Session. And so a logical thought on that would be:

‘Why not specify the Sound-Providing Server, as the place that the Linux Guest System streams its sound to, at least as long as I am on my own LAN?’

And while in theory this sounds like a good idea, in practice the implementation is still some distance away.

The main problem? While ‘Klexel’ is connected to this Sound Server, it ties up the only TCP Port, which is therefore unable to accept new connections, say from my Linux Tablet. Now, I can tell ‘Klexel’ to relinquish its session on the Sound Server, but doing so has an unexpected consequence. This corrupts the module on the PulseAudio Server, that was listening for remote connections. I need to unload the module, and reload it with the same parameters as before, just so that ‘Klexel’ can reconnect.

The long-term effect of this will be, that the Linux Tablet may be able to obtain one session on ‘Phosphene’ for sound, but that every time this tablet disconnects, again, that module on Phosphene’s PulseAudio Server will go into a corrupted state.

Hence, I have not yet worked this into a practical solution. But if I ever did, I’d be able to expand the applications of the Linux Guest System – on the Tablet – into audiovisual applications.



I am now one step closer to permitting Linux audiovisual applications on my tablet to access the sound server on my LAN. What I have discovered is, that the module in question can be loaded more than once on the PulseAudio Server, as long as each instance of it listens on a different port number. I.e., the second instance can be configured to listen on port 4318 instead of the default, port 4317. The configuration lines which accomplish this are as follows:


load-module module-native-protocol-tcp port=4317 auth-ip-acl=; auth-anonymous=true auth-cookie-enabled=false

load-module module-native-protocol-tcp port=4318 auth-ip-acl=; auth-anonymous=true auth-cookie-enabled=false


I realize that the legacy Port Number which the PulseAudio Server listens on by default, is 4713. But in Computing, it’s generally impossible for two programs to be listening on the same Port. Therefore this module listens on a different Port Number, just because PulseAudio is already running.

The command ‘pactl list modules‘ confirms that both instances are loaded and stable. Further, when the video-player ‘xine’ is finished with its connection to the server, it closes the TCP Port in a way that does not corrupt the module, so that ‘xine’ can be started a second time and will cause sound to play for the second time.

What this last observation seems to suggest is that the so-called relinquishing of the Local Sound Sink by ‘Klexel’, a Debian 9.11 computer, is corrupted, and not the behaviour of the actual module on the PulseAudio Server, also running on a Debian 9.11 computer.

This is good news. :-)

Screenshot from 2019-09-09 23-45-49

Continue reading Technical Impediment In Getting Sound From My Linux Tablet (Solved)

Why the Linux guest-system, on my Linux-tablet, is only a shell.

According to some of my own postings, I possess an old Android-based tablet, which is a Samsung Galaxy Tab S, first generation, onto which I installed a Linux guest-system, using the Android apps “GNURoot (Debian)” and “XSDL”, both available from Google Play. The latter of these apps emulates a simple X-server, which Linux-programs running under the first app can make use of.

The desktop-manager which I chose to use for my Linux guest-system is LXDE, precisely because that desktop-manager does not strictly require that Linux-based daemons be running.

But there are certain standard, LXDE-features which will not even work on that setup:

  • The Trash Bin
  • The LXDE-Settings Panel
  • (etc.)

The LXDE Trash Bin requires the package ‘gvfs’, and the Settings Panel requires the package ‘lxde-settings-daemon’. Both these dependencies launch daemons – i.e., programs that run in the background, and that make up part of a real Linux-session.

The ability to run daemons, essentially, requires that the user have a rooted tablet. Because I never rooted my tablet, I am without any daemons, that would normally belong to any Linux guest-system.

Continue reading Why the Linux guest-system, on my Linux-tablet, is only a shell.

I now have LyX working properly, on my Linux tablet.

According to This Earlier Posting, I had installed “GNURoot (Debian)” and “XSDL” on an old tablet, that are both Android apps available from Google Play, and which do not use ‘root’. There were numerous Linux-applications which would run, and many more that do not. I had also installed numerous Linux-packages that can collectively be referred to as “LaTeX” on that tablet, which actually just means by itself, command-line programs. Yet, even when typesetting using ‘LaTeX’, it’s often more fun to use a GUI. And the Linux-application “LyX” is such a GUI.

So, I have the hypothetical ability to do serious document-work on that tablet, even though the tablet is only using an emulated mouse, and “Hacker’s Keyboard”, and the mentioned emulated X-server.

What I recently did, was to get LyX to work properly:


Continue reading I now have LyX working properly, on my Linux tablet.

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