USB Sound Card

One of the recent developments in Computing is, that the actual PCs and laptops have relatively poor sound-chip-sets inside, but that we can add an external sound card via USB. I refer to these as ‘USB Sound Cards’, but think that most people just refer to them as ‘USB Sound Devices’. An actual sound card, used to refer to a PCIe interface card, which we could physically insert into our PC bus, inside the case.

When people buy a USB microphone, because the USB connection is digital, they are in fact buying the Analog / Digital converter inside that microphone, which also makes it the logical equivalent to a sound card. And the fact that it would be a USB mike, does not imply worse quality than an external sound card. To the contrary, users can expect their USB mikes to outperform the internal sound on their devices, which is the whole point in buying them.

I have embarked on yet another project, which is to buy an external sound card that is physically separated from any actual mike or sound source, and to buy a quality mike as well. Hence, I have received my USB sound device already, that has 2 output channels and 2 input channels.

Mine is a “Focusrite Scarlett 2i2” USB Sound Device, even though I usually try not to make endorsements or indictments of commercial products. It is stated to be capable of sampling at 48 and 96 kHz, and stated to be capable of 24-bit precision. It requires a USB 2 connection.

Because sound is taken very seriously with such devices, its only available inputs are a combined XLR / TRS jack each (not a 3.5mm mini-cable). This means that I am still waiting for my XLR-jack microphone to arrive, without which I cannot test the Focusrite. ( :1 )

A plausible question which some readers might ask would be, Why did Dirk not just buy a USB mike? And my answer would be, Because what I pictured wanting was closer to a USB Sound Card, hence an Analog / Digital converter, that can accept a variety of input devices.

But this would also be the context, in which it might make sense to switch my laptop ‘Klystron’ into JACK sound-mode, which supports real-time 48 kHz at 24 bits, and which also supports 96 kHz…

After all, not long ago I was pondering what the settings should be, with which JACK will start, in terms of sample-rate etc..

A key point of this project is again, to test whether the device will work properly under Linux. ( :2 )

Continue reading USB Sound Card

Another Reason, for me Not To Set Up JACK as the Back-End For PulseAudio

According to This Posting, I had written that hypothetically, it might make some sense for me to set up ‘JACK‘ as the back-end, by which ‘PulseAudio‘ sends its sound output, full-time. As opposed to the notion not making sense, to allow a few scripts to do so temporarily, that are being run by the ‘QJackCtl‘ GUI.

Well there is still a reason, why this might not be so. Doing so would be consistent, with setting up a Debian system completely according to our own preferences, and then if something does not work, we are up to our own devices to fix it.

My laptop ‘Klystron’ is a Kanotix / Spitfire system, which is also Debian-based, but in which the exact configuration has been done for me, by the Kanotix team, from their Live Disk (which can actually be written onto a USB-Key). This means that there is an advantage to me, in keeping certain configuration details conform to what the Kanotix people prescribed. If I did run into trouble with it, they would have some chance of maybe suggesting solutions, but only on the assumption that mine is still functioning within their parameters.

The way those parameters are, the current back-end to the PulseAudio sound server is displayed in the GUI as being “gstreamer“, and yet good compatibility with all things ALSA is maintained…

If I was to reconfigure my computers completely, for example because I wanted to change them to use the ‘GNOME desktop manager’ for instance, instead of ‘KDE‘, then the Kanotix team would say ‘Sorry, we are not familiar with the details of your system anymore. Therefore, we cannot help you.’

Yet, more generally, Debian allows deep changes to a configuration.

Dirk

Continue reading Another Reason, for me Not To Set Up JACK as the Back-End For PulseAudio

Running JACK side-by-side with PulseAudio

On the laptop I name ‘Klystron’, the default sound server is PulseAudio, as is often the case with desktop setups. And yet I found myself installing a lot of Linux music-authoring software on it, only to find that in order to get the full benefit of that, we need to be able to use JACK as our sound server. This was not really a new observation.

Specifically, in order to allow ‘Rosegarden‘ and ‘QTractor‘ to work fully, we need to have JACK. Without JACK installed, Rosegarden will complain when run that it can produce no sound output, but is still installable. And QTractor has the actual JACK daemon as one of its install dependencies. More generally, I did not find any DSSI hosts, that could run without JACK.

Under Linux, ‘LADSPA’ and ‘LV2′ are effect-plugin-APIs, which can also be used from applications such as ‘Audacity‘, while ‘DSSI’ is The Linux instrument plugin-API. One needs DSSI for any type of plugin, which receives a MIDI sequence and plays that, regardless of whether the MIDI-sequence came from a sequencer, or from a live, real controller-instrument.


And so I took the time last night, to set up the actual JACK daemon – not just its libraries – to coexist peacefully with PulseAudio.

The approach I took, was to install QJackCtl, a GUI that allows the user to start and then stop JACK, and that allows the user to configure this starting and stopping to taste. In order for JACK to do what it is supposed to do, I needed to change the ‘Server Path’ with which QJackCtl launches the daemon, to


pasuspender -- jackd

This field within QJackCtl tells the GUI what command to execute, to launch JACK, and has recently been renamed to the “Server Prefix”. Nevertheless it can still be customized in this way.

pasuspender‘ is a utility that comes with PulseAudio, which tells this server to suspend its access to the sound devices, for as long as the program is running, which follows as its command-line parameter. The two dashes are important.

I found, that although ‘pasuspenderdoes suspend PulseAudio, it also fails to resume this service, once the program has terminated, that was given as its parameter. I suspect that this happens, because QJackCtl terminates the command


pasuspender -- jackd

instead of actually terminating the child-process


jackd

Thus, pasuspender cannot act on ‘jackd‘ having exited, because the parent process was terminated, right along with the child-process. And so there is another field within QJackCtl, where I get to specify a post-shutdown script for JACK, where I simply inserted the command


pasuspender /bin/true

This second invocation of ‘pasuspender‘ exits without error, and actually causes PulseAudio to resume.

It is important to give this command in the correct field. I.e., If we gave this command in the pre-shutdown field, we would get a mess.


Now, this is a configuration which allows me marginal use of JACK, and while I have QJackCtl running, PulseAudio will just not work. There exist some script-artists, which will go further, and who have written more-complex scripts for QJackCtl to execute, and that will insert JACK as a back-end, for PulseAudio to continue sending sound-output to, once JACK has been launched. And then those scripts will also reverse this setup, and set PulseAudio back to running in its default mode, once JACK has been terminated.

I had two reasons not to go this route.

  1. On my systems, the back-end which PulseAudio uses are fragile. While they can be reconfigured, doing so messes up the PulseAudio instance running, until my machines are rebooted again. Changing this configuration within a session is poorly advised, on my setups.
  2. Trying to do so struck me as somewhat ambitious, and there are many ways in which an attempt can get stuck, due to minor logical errors between the scripts. The fact that I needed to execute

pasuspender /bin/true

at shutdown, to get PulseAudio truly working again, reminded me that unexpected logic glitches can come up, and that maybe I should not try to get JACK and PulseAudio working concurrently, part of the time. If this was a full-time setup, this option might actually make sense, but for temporary use – controlled with some scripts – this option seemed to make little sense to me.

Continue reading Running JACK side-by-side with PulseAudio