Getting Pulseaudio to schedule real-time threads under Debian / Stretch and beyond.

On the computer which I name ‘Phosphene’, I have Debian 9 / Stretch installed, and, going the popular route, the Debian maintainers have decided that ‘Pulseaudio’ should be the main sound server, while in certain cases, it can be made to coexist with the ‘Jack’ / ‘Jack v2′ daemon, the latter for more demanding needs. In my case, starting Jack suspends Pulse.

In addition, Debian systems I’m familiar with run ‘pulseaudio’ as user, and not as root.

But, the way my Pulse daemon is configured, includes a ‘loopback’ module, that sends audio that has been input and sampled from the analog input of my (“Creative X-Fi”) sound card, back to its analog output, so that I can listen to an old-fashioned-but-modern radio receiver, over my speakers, without having to connect anything special to do so.

The problem that I was experiencing was, buffer underruns, and sound drop-outs, due to the way this default sound server was operating the sound card. And, surely enough, it had something to do with a by-now famous issue, of allowing Pulse to schedule certain threads to run with real-time priority. This can be enabled in the config file ‘/etc/pulse/daemon.conf‘, but fails to become actual when just enabled so.

Trying to find an answer to why this attempt was failing, sent me on a trip to many Web-sites and BB-postings, most of which had as disadvantage, the fact that with Pulse, there is an old way and a new way to accomplish this, and the fact that most of the BB-postings assumed the old way, being dated to the year 2016 and earlier.

Rest assured, under Debian 9 / Stretch, authorizing Pulse to schedule some threads with RT priority, is managed according to ‘the new way’. Just to recap how ‘the old way’ worked:

The file ‘/usr/bin/pulseaudio‘ needed to be set with ‘SETUID root’, and when run this way, if the sound server detected that the real user (not the effective user) belonged to the group ‘pulse-rt‘, would schedule the threads it needed to run with RT, and would then drop privileges, so that according to the process-monitor ‘top’, it would never even give a hint that anything had in fact been scheduled with RT.

This is how ‘the new way’ is supposed to work:

If the user needs for Pulse specifically to run with RT, he must actually install the package ‘rtkit‘, which runs as a system user, and which sets certain threads to have RT priority in a curated way, that’s meant to be ‘safer’, than it still is for any one user to belong to a group, that simply allows him or her to run arbitrary processes with RT. In fact, ‘the old way’ was also meant as a similar safeguard.

I had installed the specified package, rebooted my system – with Pulse given its new startup parameters, and found alas, that the file ‘/var/log/syslog‘, which was benefiting from an elevated logging level set by me, revealed numerous messages that I did not understand.

Trying to figure out what was happening resulted in more than one day’s frustration, and then finally, to some peace of mind…

(Updated 4/16/2020, 13h15 … )

Continue reading Getting Pulseaudio to schedule real-time threads under Debian / Stretch and beyond.

PulseAudio Restart Bug – Solved

I enjoy my Linux computers, and one reason is the fact that many technical issues can be resolved, without having to reboot endlessly. However, in my past usage, there has been an irritating exception to this pattern. It’s common under Linux, that we can simply restart the PulseAudio Server from the command-line, using one out of several methods, and that the subject should be done with. But alas, every time I have ever restarted PulseAudio in this way, or, if the server restarted on its own, afterwards, when looking up the Plasma 5 -generated status display (which is actually referred to as “Phonon”), I’d be missing a Devices List, like so:

Screenshot_20191026_152751

This type of display can be interpreted to mean several things, such as, that the PulseAudio server did restart, but that perhaps, it simply failed to connect to the inter-process, session-unique, message-bus. Therefore, in the past, whenever I had such a display, I eventually did what I thought I had to do, which was, to log out and back in again, or, to reboot. On my system, PulseAudio is configured such, that it runs as one user-name, and not as root.

In fact, a peculiar side effect of this bug was, that the list of available output devices was still being displayed, within ‘pavucontrol‘.

But this ordeal has now become even more inconvenient than it ever was because on the computer which I name ‘Phosphene’, the need may recur more frequently, ‘just to restart the PulseAudio server’.

However, I have finally found the true cause for this malfunction, which was, that when PulseAudio is restarted from within an existing session, it simply fails to load one module, which is also the module that it needs, in order to be able to list the available devices:

 


module-device-manager

 

In fact, there exists a script in ‘/usr/bin‘, that loads a series of X11-related modules.

Therefore, after a restart of this service, I can simply give the following command now:

 


/usr/bin/start-pulseaudio-x11

 

And Eureka! I can now obtain a list of available devices, without ever having to log out and back in, or, without ever having to reboot:

Screenshot_20191026_152853

In fact, I have created a shell-script, which I can click on as user, and which carries out this task, safely.


 

I’ve also discovered that the ‘ProjectM’ music visualization application still works, and detects the beat of the playing music as before. What this means is that theoretically, after ‘ProjectM’ was installed, instead of rebooting, I could have just restarted the PulseAudio server as described here, to get that working.


 

( Edited 2019/10/29, 23h35 … )

I know that there exists an unrelated problem, that just happens to give the same appearance within ‘Phonon’, but that cannot be resolved in this way…

Continue reading PulseAudio Restart Bug – Solved

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)

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 … )

Continue reading There exists HD Radio.