JACK Sync: A Primer For Linux Users
Recently I've been working with the transport synchronization capabilities of the JACK audio server. This article is a report on those capabilities as tested with a variety of Linux audio applications under the JAD and 64 Studio distributions.
JACK: The 1-minute Profile
By now everyone in the Linux music and sound world has heard about Paul Davis's JACK audio server and transport control system. By way of introducing this article and for the benefit of the remaining few people who don't yet know about it I'll briefly review JACK's more salient characteristics.
JACK's name is a recursive acronym for "JACK audio connection kit". The kit provides a system for freely connecting independent audio data I/O points, thus allowing the audio output from one JACK-savvy application to be sent to the audio input of any other JACK-aware client. The system supports multiple connections to and from any audio I/O points, and all data streams are synchronized to sample-accuracy.
As a sound server, JACK operates between the low-level sound system drivers and any JACK-aware client applications, managing the flow of multiple freely interconnected audio data streams. The system has been designed for professional use, and it has become an expected feature in Linux audio software. JACK has been extended recently to handle MIDI data streams in sample-sync with its audio I/O, an especially exciting development for those of us who await a MIDI-capable Ardour.
JACK was also designed from the start with a transport control system that would synchronize the operation of any subscribed clients, and that system is the focus of this article.
Synchronization: A Little Background
In the sound and music software world, synchronization typically refers to the precise timing of audio events with video, MIDI, and other event streams. Accurate synchronization of audio and video events is a critical part of movie production. Sounds must occur at the precise times of their associated visual cues, and our aural acuity will notice very quickly when sound and image don't correspond. What seems to be a simple problem turns out to be a complicated procedure, thanks to the different timebases used for audio and video, hence the need for some means of synchronizing disparate event streams.
In Ye Olden Tymes film composers calculated event correspondences with stopwatch and pencil. They let machines do the math now, but there is still a need to understand synchronization arcana such as the variety of SMPTE frame rates and how to successfully utilize MTC.
The advent of the MIDI sequencer ushered in an new crop of synchronization problems and solutions. First, sequencers and drum machines needed to be synchronized with each other (or with other sequencers and drum machines), hence the development of various MIDI synchronization protocols such as frequency shifted keying (FSK), song position pointer (SPP), and "smart" FSK sync. Next, the MIDI studio wanted to integrate with the tape studio. Since most tape recording studios already used SMPTE timecode as a synchronization solution it seemed only natural that the MIDI studio should adopt SMPTE as well. The original MIDI specification made no provision for carrying SMPTE timecode signals over a MIDI cable, so the spec was eventually extended to define an encoding of SMPTE into what is now known as MIDI Time Code (MTC).
The marriage of the MIDI sequencer and the hard-disk recorder brought in another synchronization headache. Computer-based recordists quickly discovered that the timing of audio tracks and MIDI tracks tended to drift apart after a few seconds of simultaneous play. This problem prompted the development of solutions for synchronizing audio and MIDI tracks within the same application, paving the way for the development of the modern audio/MIDI sequencer.
The JACK Transport Control System
The ability to manage multiplexed audio I/O is impressive, but it isn't worth much during recording or playback if the various tracks, channels, and streams don't stay in time with one another. To make that happen, JACK supplies a transport control subsystem. The system provides sample-accurate synchronization of streaming audio I/O, and any client that supports the JACK transport control can operate or be operated by any other similarly aware client. In a typical scenario where two or more applications agree to use the JACK transport control, any client can behave as the control master, thus eliminating the need to designate a master client. The transport timebase (i.e. the musical tempo) is set and maintained by only one of the clients, but it remains in effect regardless which application acts as the master control.
This transport control system is an integral component of JACK, and it is completely transparent at the user level. No extra software is required: When you load the jackd daemon you've loaded the transport control system as well. The client application's transport UI is used as it would be without JACK, and the user has no contact with the system's underlying details.
Space limits forbid an in-depth discussion of those details here, but interested readers can find full technical documentation of the system on the JACK Web site at jackaudio.org. Developers of audio and MIDI software for Linux and OSX are especially welcome and are encouraged to integrate JACK support into their own software.
JACK Sync In The Studio
Synchronizing with JACK is usually a straightforward process. My first example is typical: I started QJackCtl, Rui Nuno Capela's excellent GUI for controlling JACK, then I started the latest MusE sequencer (version 0.9) with no special options. MusE recognized JACK instantly, and I could control the start/stop and rewind/fast-forward functions at any time from either QJackCtl or MusE.
Next I tried synchronizing Ardour and the seq24 MIDI sequencer. Seq24 works in two edit modes, a pattern composer and a performance arrangement editor (seq24's Song Editor), and it is designed to operate in only one of those modes at any time.
Seq24's Files/Options dialog includes the JACK Sync tab seen in Figure 2. Unlike MusE, seq24 has a variety of options to condition its behavior with JACK. Each option works as reported by the tooltips help: JACK Transport enables seq24's status as a peer client, Transport Master attempts to set seq24 as the master controller, and Master Conditional will set seq24 to master status only if there is no other master defined elsewhere. The Live and and Song mode buttons determine which mode JACK will control (it can only do one at a time), and the Connect/Disconnect bars should be self-explanatory.
This example also illustrates how JACK handles different transport capabilities. By design, seq24 has no manual rewind controls, it automatically rewinds the pattern or song back to its beginning (or to the start of a designated loop in the Song Editor). The start/stop controls work perfectly, as does the autorewind, yet it also behaves as expected when controlled by the rewind buttons in Ardour or QJackCtl. Figure 3 shows off this synchronized network in action, with QJackCtl acting as the master transport control while Ardour records the audio output from QSynth (as played by the JACK-sync'd seq24). Yes, it's cool and a lot of fun.
My next experiment put Ardour in sync with a video display utility named xjadeo. Xjadeo was designed as a video monitor "assistant" specifically for the synchronization of audio samples with video frames. It is definitely not intended for general-purpose video file playback.
As previously, I set Ardour's sync status to JACK and Time Master, then I started xjadeo with this command line :
xjadeo -i 3 foo.avi
Xjadeo's bare appearance (Figure 4) conceals a powerful helper application. Its feature set includes various controls for frame rate and timecode display (the -i switch), color equalization controls, and the capability to sync via MTC (MIDI Time Code) instead of JACK. Again, space forbids a complete presentation of xjadeo and its features, but considering its price (free) and availability (free) you could just check it out for yourself.
The experiment was once again anticlimactic. Everything worked as advertised, I could control xjadeo's transport from either Ardour or QJackCtl to sync the audio and video streams, and I was a happy fellow. Even in my simple test it was easy to see how the program could be put to serious use.
For my last test I connected the audio output from the Hydrogen drum machine into an audio recording track in the Rosegarden sequencer. As usual, QJackCtl was also employed.
Setting Hydrogen for JACK sync is easy enough. Make sure the audio driver of choice is JACK (in the Tools/Preferences dialog), then click the JACK Trans button in Hydrogen's track display (see Figure 5). That's it, Hydrogen will now behave as the transport master or slave.
Setting up Rosegarden requires more navigation, but the process is equally straightforward. Go to the Settings/Configure Rosegarden panel, click on the Sequencer Settings icon, then select the Synchronization tab. Set the JACK transport mode to Sync, apply the changes, then click OK (Figure 6). Now Rosegarden shares JACK transport peer status with Hydrogen and QJackCtl.
And yet once more it all worked as advertised. One extra step was added: I had to manually connect the stereo outputs from Hydrogen to the inputs for the Rosegarden track, a trivial task quickly completed in QJackCtl's audio connections panel. I also had to start from Rosegarden if I wanted to record the drum track. Alas, the sequencer's Record status is not available to the transport control.
JACK vs. ReWire
JACK is sometimes referred to as the Linux equivalent of ReWire, an audio/MIDI connection and transport protocol for Windows and Macintosh sound and music software. I have no Windows system here at Studio Dave, but a comparison of features revealed that JACK and ReWire indeed share some common design concerns. Both provide audio routing with flexible I/O and a master transport control system, and both are freely available. However, ReWire is available free of charge only to developers of proprietary software. JACK is GPL'd open-source free software, available at no charge to anyone, anywhere, anytime.
At the start of this article I referred to "Paul Davis's JACK". Paul is indeed the chief architect and head honcho in charge of JACK, but his software has become the work of many hands. Its thriving development community ensures JACK's maintenance and further evolution: MIDI support is already available in versions >= 0.103.00, JACK for OSX exists now, and a rumored Windows port may yet see the light of day. Speaking personally, I'd like to see more applications incorporate the JACK transport control. For example, the LiVES video editor supports the JACK audio server, but it would be very cool if it also supported the transport control. Video editors are a natural choice, but other audio applications such as trackers and soundfile editors might make good candidates for JACK sync.
Similis sum folio de quo ludunt venti.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|Fancy Tricks for Changing Numeric Base||May 29, 2016|
|Working with Command Arguments||May 28, 2016|
|Secure Desktops with Qubes: Installation||May 28, 2016|
|CentOS 6.8 Released||May 27, 2016|
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
- Tips for Optimizing Linux Memory Usage
- Secure Desktops with Qubes: Introduction
- Working with Command Arguments
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Secure Desktops with Qubes: Installation
- Fancy Tricks for Changing Numeric Base
- CentOS 6.8 Released
- Linux Mint 18
- The Italian Army Switches to LibreOffice
- Petros Koutoupis' RapidDisk
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide