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

Music Visualization Plugins Under Linux

It is only very recently, that I have looked at an aspect of my Linux computers, which certain mainstream users would appreciate more than I, usually, which is to set them up, just for listening to music.

A part of music appreciation, can be to have visualizations display, that respond in some way, however minimalistic that may be, to the ‘mood’, the general spectral composition and rhythms. And so if we are used to Windows and its Media Player, we already know about such plugins as ‘Goom‘… And when we are using “Amarok” to listen to music under Linux, we may find ourselves missing such niceties.

There is a comment which I must make about such plugins as Goom though. This type of content is considered to be intellectual property, and the authors wish to be paid, for the numbers of users who view their art while listening. And so one thing which Linux cannot do, would be just to copy each of these plugins. I think that in the past, doing so caused some disputes somewhere.

But that does not mean, that the world of Linux may not have visualization plugins of its own. Hence, the question does arise, as to where those might be.

And the answer for some time has been disappointing. While the sound system on Linux computers has shifted from OSS, ALSA and ESOUND to such standards as ‘Pulse Audio‘ and ‘Phonon‘, this has thrown a bit of a monkey-wrench into the availability of visualizations. Those used to exist specifically for ‘Amarok‘ and ‘Kaffeine‘, but actually do not because of the versions having progressed to a state of incompatibility.

It used to be, that installing such additional packages as ‘libvisual‘, would mean that a visualization panel would become available within Amarok itself. For now this does not happen. And so I have found another way. I would say that the following packages need to be installed:


libvisual
libvisual-dev
libvisual-lugins
libvisual-projectm

libprojectm2
libprojectm-dev
libprojectm-qt1
libprojectm-qt-dev
projectm-data
projectm-dbg

projectm-pulseaudio

I am going whole hog here, and pretending that some of us might actually want to write some of our own visualizations at some point in time, but also that we would want the collections to be available to us, which have already been written by Debian devs. There is a new player on this list, which is known as ‘projectM‘. This is a framework for visualizations to be displayed with OpenGL, GPU acceleration (unlike how ‘libvisual‘ used to work). And a key package I have just now recommended is ‘projectm-pulseaudio‘.

What this does, is put an entry into our application menus, which opens a window, which displays those visuals, for whatever sound sources are in fact playing, through pulseaudio.

So we do not have to use Amarok necessarily. We can use some other music player, and as long as the music is being piped through pulseaudio, the visuals will try to adapt to it.

The only downside to this platform, is the fact that the projectM window sometimes needs a few extra seconds, to detect shifts in the mood of the music, and to select a new theme of visuals to keep up with that. Also, even though some of this is GPU-accelerated, the CPU-load of all that is still quite high, especially if we have Amarok displaying as a full window, and not as a notification tray icon.

But the whole thing works! And I did suppose, that I should add the ‘mood bar’ to Amarok as well…

Dirk