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.


 

Update:

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=127.0.0.0/8;192.168.2.0/24 auth-anonymous=true auth-cookie-enabled=false

load-module module-native-protocol-tcp port=4318 auth-ip-acl=127.0.0.0/8;192.168.2.0/24 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)

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.