“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:

screenshot_20180423_150952_c

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:

screenshot_20180423_151117

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

Continue reading “Help! No Volume Mute under Plasma 5!”

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.

Dirk

 

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