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:






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.

There exists HD Radio.

In Canada and the USA, a relatively recent practice in FM radio has been, to piggy-back a digital audio stream, onto the carriers of some existing, analog radio carriers. This is referred to as “HD Radio”. A receiver as good as the broadcasting standard should cost slightly more than \$200. This additional content isn’t audible to people who have standard, analog receivers, but can be decoded by people who have the capable receivers. I like to try evaluating how well certain ‘Codecs’ work, which is an acronym for “Compressor-Decompressor”. Obviously, the digital audio has been compressed, so that it will take up a narrower range of radio-frequencies than it offers audio-frequencies. In certain cases, either a poor choice, or an outdated choice of a Codec in itself, can leave the sound-quality injured.

There was an earlier blog posting, in which I described the European Standard for ‘DAB’ this way. That uses ‘MPEG-1, Layer 2′ compression (:1). The main difference between ‘DAB’ and ‘HD Radio’ is the fact that, with ‘DAB’ or ‘DAB+’, a separate band of VHF frequencies is being used, while ‘HD Radio’ uses existing radio stations and therefore the existing band of frequencies.

The Codec used in HD Radio is proprietary, and is owned by a company named ‘iBiquity’. Some providers may reject the format, over an unwillingness to enter a contractual relationship with one commercial undertaking. But what is written is, that The Codec used here resembles AAC. One of the things which I will not do, is to provide my opinion about a lossy audio Codec, without ever having listened to it. Apple and iTunes have been working with AAC for many years, but I’ve neither owned an iPhone, nor an OS/X computer.

What I’ve done in recent days was to buy an HD Radio -capable Receiver, and this provides me with my first hands-on experience with this family of Codecs. Obviously, when trying to assess the levels of quality for FM radio, I use my headphones and not the speakers in my echoic computer-room. But, it can sometimes be more relaxing to play the radio over the speakers, despite the loss of quality that takes place, whenever I do so. (:2)

What I find is that the quality of HD Radio is better than that of analog, FM radio, but still not as good as that of lossless, 44.1kHz audio (such as, with actual Audio CDs). Yet, because we know that this Codec is lossy, that last part is to be expected.

(Updated 8/01/2019, 19h00 … )

Just Installed Kanotix Steelfire on one of my Boxes

For more than a week, I was worried about Kanotix, because their Web-site was down. But after just checking today, I found it was up again!   It has been a habit of mine to install initial Debian systems, from Kanotix Live Disks.

I already posses a powerful computer which I name ‘Plato’, onto which I installed Debian / Stretch by way of an experimental Live Disk from Kanotix, but cannot fully say that that one is a Kanotix computer, because at the time, Kanotix didn’t have an official Debian / Stretch release yet. What I did have was two systems running the slightly older Debian / Jessie, and the official Kanotix release with that, is called “Kanotix Spitfire”.

But what I also had for some time, was a weaker PC that still had Debian / Lenny on it, which was an antique system, that required its own security measures, just not to pose a vulnerability to me.

My special security measure for that computer, was just never to turn it on. In fact, it had no eligible Web-browser. But like that, because the hardware was still good, this represented wasted hardware, just sitting in my computer room.

So, now that the Kanotix site is back up, what I did was to download a 32-bit, LXDE Disk Image, of “Kanotix Steelfire”, which is by now their official Debian / Stretch release. In principle many people, including Kanotix experts, would agree that it makes more sense to use as desktop manager, Plasma 5, but as it happens, the computer that just received a new O/S is so weak in terms of RAM and graphics chip-set, that I didn’t think it could handle Plasma 5.

The newly-set-up computer used to be named ‘Walnut’, but is now to be named ‘Klexel’. It has as graphics acceleration, an old Intel chip-set, which Kanotix distributions actually support, in the form of ‘i915 support’. This is neither an Nvidia, nor an AMD/ATI chip-set. But amazingly, I do have some level of direct-rendering with it, and, in addition, I have Compiz Fusion on that box now, and at least, the 3D desktop-switching belonging to Compiz works!

So now, with ‘Klexel’ wiped, I can take my time with it, and install what I think it should have. But what will slow me down a bit, is the fact that I’m not used to LXDE as a main window-manager. In the past I goofed around with LXDE a bit, but now, this is going to be Klexel’s window manager, under which the GUI is arranged differently, from what I’m used to.

(Update 09/09/2019, 15h50 … )

(As of 09/01/2018, 21h35 : )

“Help! No Volume Mute under Plasma 5!”

One of the subjects I blog about, is a computer I named ‘Plato’, which is running Debian / Stretch (Debian 9), and the desktop manager of which is Plasma 5, which is the successor to KDE 4.x .

One of the features which KDE 4 definitely had, was an icon in the notification-tray, from which we could control our volume levels easily, as well as to mute the sound temporarily, eventually to be unmuted again, at which point the earlier, unmuted settings should be remembered. At first glance it would seem that Plasma 5 has done away with this capability. Trying to solve this can cause people to spend hours searching the Internet, changing their Plasma 5 preferences, and maybe even forgetting their Plasma 5 preferences, because they disabled all their System Sounds from there.

Recently, I was on a fact-finding mission about this, and am willing to share my solutions.

Under Plasma 5, we really only need to have 2 packages installed, in order to control our volume-levels, etc., assuming that we have gotten our hardware recognized first. Those packages would be:

1. ‘plasma-pa’
2. ‘pavucontrol’

The first of these packages integrates with Plasma, and is also responsible for the icon in the notification tray. The second package gives us more control, over our sound-levels specifically, since Plasma 5 uses the Pulse Audio sound-server by default.

If we can see the icon in the notification tray, then a detail which we may overlook after we left-click on that icon, is a tiny little loudspeaker-symbol, on the left end of one of the volume sliders:

Left-clicking on this little symbol will cause the volume-bar to the right of it to become slightly pale, which will mean, that the device in question has been muted. I’m saying that ‘we’ could overlook that we even have this feature, because earlier, ‘I’ did not know that I have this feature.

But, this is only what the ‘plasma-pa’ package can show us. The ‘pavucontrol’ package gives us the ability to fine-tune our sound-levels as shown below:

Now, there’s an aspect to how this setup now works, which is slightly more complicated than how KDE 4 used to handle it. The Pulse Audio server attempts to adjust playback as well as recording levels, on a per-application basis. Thus, the view above is almost empty, because there were no applications playing back any sounds, at the moment I recorded this screen-shot.

A frustrating fact which can exist with this, is that some applications will only play a sound for 2 seconds, during which an additional volume-bar appears in the GUI, and after which that volume-bar disappears again, even if we did not have enough time to adjust one volume level. This happens to result from the design-decision, that volume-control should exist at the per-application level. Hence, even if we use media-control keys on our keyboard, those keys will only affect the one main application which happens to be playing, at any given moment. They won’t affect System Sounds.

But this description might sound like I have to say, ‘There is no problem,’ when in fact, under Debian / Stretch, There Is a problem. That problem, as I see it, lies in the fact that by default, the one volume-bar which the GUI has shown above, for all System Sounds, may not even work.

(Updated 04/26/2018 … )