A brief survey of Linux audio session managers

Most of my music and sound work requires only a few applications. If I'm recording a song, I use a digital audio workstation (DAW) with a few plugins launched from within the sequencer, and if I make something in Csound, it's usually done completely in the AVSynthesis environment. The DAW and AVSynthesis programs are self-contained; they need no external software to store and recall their internal and external connections, plugin states, MIDI controller settings, and so forth. When I work in those environments, I know that I can open a previously saved session and have all former connections, states, and settings restored to their last conditions.

Recently I've been experimenting with a more heterogeneous workspace with several applications connected in a modular system. The JACK server allows flexible inter-application data exchange, and some powerful setups can be configured with the many JACK-compliant sequencers, synthesizers, and plugins. Unfortunately, the reconnection and reconfiguration of a complex modular system becomes a real problem when you've opened a DAW — with plugins, of course — and half a dozen standalone synthesizers are active with an equal number of standalone audio processors, each with its own internal settings and configuration details. The resulting maze of connections and configurations takes time to re-establish, valuable time that could be better spent on making music. Fortunately, help is here, thanks to Linux audio session managers.

A session manager (or "session handler") is a utility that stores and recalls every aspect of your audio production session. Typically each session has a unique identifier, so a click or two can reload, reconfigure, and reconnect all the pieces of your session exactly as you saved it. For smaller sessions, a manager may be a neat convenience, but for large-scale sessions with dozens of components the session manager is indispensable.

Technicalities

Session managers work in a few different ways, though all do the same things. Some can only manage applications that are JACK-compliant or that subscribe to a particular session protocol; others are more accommodating. Most managers include a graphical interface, but, since this is Linux, there are non-graphical solutions too. In fact, even the bash shell makes it easy to write a script that will relaunch an entire session. Such scripts are powerful and effective, but interaction is limited and it may be difficult to monitor and store state changes. Changes to your basic setup configuration may require additions to the script outside the session.

Session management protocols are designed to handle these matters. A basic session handler should be able to restore a session exactly as the user left it, but the handler must deal with a mash-up of harsh realities, including the internal and external states of host and clients (with display positions and sizes), the instantiation of all active plugins with their selected presets and internal edits, the loading of all necessary files used by the project, and the connections between the components in the system, including audio and MIDI I/O, track and bus assignments, and any other routing considerations. The session manager must be toolkit- and distribution-independent and it must handle the full variety of plugin and sound file formats. It should also be indifferent to the audio backend, but it should be aware of system services such as D-Bus. Finally, the manager should provide robust error reporting when things go wrong.

Session managers typically provide a library of services and a daemon to monitor and report process changes. An application that is linked to the manager's library can be monitored by the session daemon and update its state data for saving and recall. Obviously, the efficiency of any session management software depends on the services provided by the library and the client's implementation of the library services (if any).

In this article we'll look at the current crop of session managers for Linux audio production. We begin with a little history to understand how we've come to the present state of the art.

From LADCCA to LASH

The first attempt at Linux audio session management appeared as LADCCA, the Linux Audio Developer's Configuration and Connection API. Developer Bob Ham's LADCCA Reference Manual indicates that, even at the earliest stage, developers were aware of the basic problems and issues. LADCCA's development group expanded and the project eventually became LASH, the Linux Audio Session Handler. Focus remained on managing applications written for JACK and/or plain ALSA, with expanded services via D-Bus, improved signal handling, backward compatibility with previous APIs (including LADCCA), and other amenities. LASH developer Dave Robillard's LASH Manual provides more details for programmers. LASH became a popular solution for complex sessions and is still found in many software repositories.

On to LADISH

LADISH — the Linux Audio Developers (Integrated? Interesting? Indefatigable?) Session Handler — is the current successor to the LADCCA/LASH lineage. The project goals remain JACK-centric, with sophisticated client identification according to "levels" that define the detail of state storage and recall. D-Bus and jack-dbus are required, and the LASH and JACK Session APIs are supported.

The concept of levels is neatly summarized in the LADISH documentation, quoted below:

The use of these levels is an attempt to sort and regulate the various possible conditions for any Linux audio application. Those conditions include the degree of JACK compliance, any WINE or DOS requirements, network operation, the multiplicity of existing APIs, and so forth.

Like the original LASH project, LADISH includes a GUI (called gladish) for configuring LADISH and your session management preferences:

Gladish works perfectly, providing a neat concept of virtual Studios, Rooms, and Projects for organizing your session components. As an alternative, users of the KXStudio system can also choose to use its excellent Claudia utility, a custom-made frontend for the LADISH System:

A "getting started with LADISH" tutorial is on-line at the LADISH Wiki. Further excellent tutorial material can be found at Lampros Liontos's wonderful Penguin Producer web site.

The Non Session Manager

The Non Session Manager is a component in the Non* suite of audio/MIDI software by Jonathan Liles. It can be used as a standalone program without the rest of the suite, but you will need to install the core NonToolKit library first. Check your distribution's software repositories for an installable Non suite. If it hasn't been packaged for your system, you'll have to visit the Non Web site and follow the instructions there regarding access to the project's Git repositories. The suite is easy to compile, with only a few dependencies, all commonly found in any modern Linux distribution repositories.

After installing the program it's ready to run. The command-line invocation takes two possible options, one to specify the URL of the Non Session Manager daemon (nsmd) and one to indicate a particular root path for your sessions. When the session manager starts, it requires no further configuration.

The Non Session Manager is easy to use. The top button bar exposes most of its functions, though there are a few hidden features. The "New" button starts a new session, "Add Client" adds an application to the session, "Save" saves the session, and "Close" closes it. The "Open" button opens an existing session, or you can click on the session name in the list box, where we encounter hidden feature number one: clicking on the session name will immediately close the running session and load your selection, so be sure to save your work first. The "Duplicate" button copies a running session as a template for later similar sessions.

When you add a client to a session you might discover another hidden feature, the nsm-proxy client. This convenient feature lets you add clients built without Non Session Manager or other session management support, though the addition is limited to opening and closing the particular client. If a client has LADISH level-1 support (or another method of saving its internal state), you can also select a "Save State" signal, though the Non Session Manager may not directly handle the state data.

Yet another hidden feature: When adding clients you can add a special client named JACKPatch that will store your JACK audio and MIDI connections. You can save a JACK connection map as a Patchbay in QJackCtl, but of course you need to be running QJackCtl. The Non Session Manager JACKPatch client provides a handy means of storing and restoring your connections without an external application.

The Non Session Manager also has features of interest to users of networked audio systems. Its documentation states that the Non Session Manager is the only session manager capable of saving and restoring session configurations of networked machines. Alas, I was unable to test a networked session, so I must refer the reader to the Non Session Manager Web site for more information regarding the handler's implementation over a network.

Of the session handlers I tested, the Non Session Manager gets top honors for features, flexibility, ease of use, and transparency. It does its job, otherwise it stays out of the way. It doesn't interfere with other processes, and it can be reconfigured interactively during a session. The Non Session Manager isn't perfect — I'd like to have a more direct method of entering nsm-proxy clients, and I might like to be able to rename sessions, but these are minor issues. Otherwise the Non Session Manager is highly recommended Linux audio software.

QJackCtl

The image below shows QJackCtl's JACK Session manager at work.

If your modular configuration includes only JACK-compliant applications and you use QJackCtl to manage connections, you might consider using it to manage your sessions as well. Operation is simple enough — just click on the Session button and follow the prompts for saving your work. The manager saves all aspects of its clients and restores them exactly. Incidentally, Ardour subscribes to the JACK session management protocol, making it a simple matter to include its considerable powers into a modular setup.

Programmer's documentation for the JACK session API can be perused at jackaudio.org. For normal users, the Tango Studio project has provided some excellent documentation on its helpful JACK Session tutorial page.

Chino

In my research for this article, I discovered Chino, a scripted session manager with no ties to previous management protocols. According to its author, Chino is "... a framework and toolset to build and manage a meta-application consisting of the user's favorite modular JACK audio and MIDI tools, each started and interconnected in predefined ways." Chino's developer is rather modest about his project, but I found it to be a well-designed tool that may be just the item you need if the "heavier" solutions don't suit your project requirements and you're comfortable with the Linux command line.

Installation and configuration are covered in Chino's documentation. No unusual dependencies are required, but you'll need the jack_snapshot utility to store and recall your JACK audio and MIDI connections. You can also save an SVG graphic display of your session's status. You'll need the Xsvg viewer to view it from within a Chino session, though any SVG-capable viewer can be used to view the image outside the session.

Chino defines a session in a method/application hierarchy. According to the documentation, methods are "categories for applications that are to be handled in similar ways. Every application belongs to one method." Following that definition, the documentation informs us that applications can be "(almost) anything... one or more (audio)-programs, audio/MIDI hardware or netjack ports — many things can be crammed into an application." In practice it's all simple enough. Start with this command to start a new session:

	chino -n newsession

Follow the prompts, and be sure to use the h (Help) and w (Write) options liberally. You'll find your way around Chino quickly enough.

If your saved session is named newsession.sdef you'll reopen it with this command:

	chino -o newsession.sdef

Chino is easy to use and does its job quickly and efficiently. However, it is still in development, with a few rough edges yet to polish. I created a test session from its default settings for the amSynth and Yoshimi synthesizers, with normal audio/MIDI connections made with QJackCtl. I saved the session, but, on closing, amSynth had to be manually stopped. On reopening the session, the synthesizers appeared as expected, but only amSynth's connections were restored. I must emphasize that this is a single test case and in no way stands as a general estimation. I'll need to spend some more time with Chino — there's much more to it than what I've presented, and it is definitely worth watching.

Summing the signals

When I started writing this article I had little experience with session managers. I'm still no expert, still having a lot to learn about these projects, but I'll hazard an opinion or two. Currently I prefer the Non Session Manager for the greatest number of my projects. The LADISH-based handlers are advised for sessions with only JACK-aware applications, though QJackCtl's session handler may be preferred when using that utility. Chino is available for command-line users, as is the humble and powerful bash scripting language.

Modular music systems are difficult to configure and restore, but by definition what is difficult is not impossible. Apparently the developers of these programs and utilities have a similar attitude towards difficult things, and I'm happy to report the ever-improving states and conditions of their projects.