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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide