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

Update to ‘gstreamer’

Under Debian / Jessie, the standard back-end to the PulseAudio daemon is ‘gstreamer’. This is a set of programs that perform potentially complex sound-processing under Linux, yet have no real GUI as it stands.

In the past week or so, there was an update to this software-subsystem.

I have not rebooted any of my computers since then, nor have I done a simpler user-session-restart. Therefore, I do not yet know whether this update has broken PulseAudio, nor whether it has improved the performance of the audio-daemon, that is standard for KDE, and that definitely has a GUI.

When I find this out, I will comment on it again.



How the JACK Sound Daemon is capable of running at 192kHz

Most of my Linux-computers have as their sound-server ““. But specifically on my laptop named ‘‘, I have set up the to be able to run as an alternative, yet not to be running by default. I have performed experiments on that laptop, to confirm that I can launch this sound-server, using a GUI named ‘‘, but have also had to make modifications to how this GUI executes commands from the user, so that its start-up pauses the , which has been able to resume successfully after I was done using . Without such a detail, the attempt should not be made.

One fact which I can see in , is that is capable of running at 192kHz, even though it has not interrogated any of the available devices, about their real capabilities are.

The reason this is possible is the fact that individual sound devices are just clients to that daemon, including any number of devices that act as sound-sources, rather than acting as sinks, i.e. that act as inputs rather than as one output.

I also own a USB-Sound-Device named the ‘‘, which is mainly intended for use in sound capture, but which also has outputs intended for monitoring purposes.

If I was to run at 192kHz, then one simple consequence of that would be, that zero actual sound-devices would remain compatible with it. As to how cleanly an attempt to connect to an incompatible device exits, giving error messages or crashes, I have not tested, because when I tested the , I took into account the real limit of that device at 96kHz.

Similarly, the runs with 32-bit linear precision by default. In this case, when we enable devices to act as clients, which are only capable of 24-bit sample-depth, which is common, the mismatch is safely ignored. already sees to it, that the last 8 bits of precision get ignored.

Now, I could be cautious and worry, that because of errors in the Linux drivers, those last 8 bits somehow get mapped to a control register as an error. But then the simple way to test for that, was simply to send some 32-bit sound through JACK, to this output device. What I found when testing this, is that the basic operation of the was not disturbed, even though my hearing was not good enough, to tell me when I had my Sennheisers on, whether in fact 24-bit precision was still working. I was mainly testing, that trying to send a 32-bit value, does not disrupt the actual operation.

Continue reading How the JACK Sound Daemon is capable of running at 192kHz