Monitor Your Podcast Recordings With Audio Hijack 3’s Low Latency Mode

| How-To

Rogue Amoeba added a (previously-hidden) preference to Audio Hijack 3.3 that allows users to monitor themselves with no perceptible delay while recording. This is particularly useful for podcasters, as it allows them to record "live-to-tape" while hearing exactly what their listeners will hear.

Audio Hijack Pro users will recall being able to accomplish this by tweaking the audio device buffers. With Audio Hijack 3, Rogue Amoeba completely reworked the interface from Audio Hijack Pro, making the app simpler and even more flexible at the expense of losing the ability to monitor our recordings without hearing ourselves on delay, or with "low latency."

Some USB mics have a "zero latency monitoring" feature, but using it means you won't hear what's actually being recorded, and that can lead to some very disappointing recordings if something goes awry in your process. The new "Audio Processing" preference in Audio Hijack 3.3 allows you to perfectly tweaks these buffers with a simple preference slider.

To put this into context I've included a sample workflow here. This assumes you're recording a podcast with someone over Skype. At the end we'll add in some additional things like noise gates, levels and compressors. Next week we'll utilize Loopback to add theme music.

  1. Launch Audio Hijack and open Audio Hijack > Preferences. In here, set the "Audio Processing" section to "Lower Latency." You'll note the other, default end of the slider is labeled "More Reliable." That's because lowering the latency involves reducing the time the computer has to process everything and get it sent back out to your speakers or headphones. If your computer can't keep up due to CPU or disk demands, you may encounter skips in your audio.

    Audio Hijack Low Latency Preference
  2. Go to Session > New Session to create an audio session that looks like this (or simply download our sample session!)

  3. You'll need to change a few things unless your system is exactly like mine. The first thing to change is your input device (aka your Microphone). It likely has a yellow warning on it like the screenshot above. Click this box and choose your audio input device. Also make sure to twist down the "Advanced" setting and choose the correct channels on your device. If your microphone is mono (and it very likely is), choose the same channel for BOTH your Left and Right Channels here. This is especially important if you're using a generic USB mixer or breakout box into which you've plugged an XLR-based microphone. You don't want to grab another, random channel.

  4. Similarly, change the "Headphones" output device to whatever you plug your headphones into. If it's your Mac, that would either be "Internal Speakers" or "Built-in Headphones" depending upon whether or not you have plugged headphones in yet. This is the device that will be doing live monitoring of your signal, so if you have some sort of "zero latency monitoring" option on your USB device either (a) turn it off or (b) plug your headphones into another place (like your internal headphone jack on your Mac as I have done in our screenshot here).
  5. Click open the Skype box in your Audio Hijack session and make certain that the "Include audio input" box is NOT checked. For our purposes here we only want Audio Hijack to capture the audio coming from Skype, not what we're sending to it.
  6. Similarly, you'll want to go to Skype > Preferences > Audio/Video and make sure it's set to the same input device that Audio Hijack is using (otherwise your guest/host won't be able to hear you).
  7. At this point you're set to test yourself. Head back to Audio Hijack and click the hijack (or "enable") button in the bottom left corner of this session. You should not only hear yourself through your headphones, but you should "see" audio going through the virtual pipes in Audio Hijack. It's pretty cool. Note that you're currently recording (or at least I am in the screenshot — you can disable your recordings by clicking on the Recorder device and turning it off).

  8. Now that you understand how to use Audio Hijack 3's low latency mode, let's show an example of why you might want to do this. One of the handy things about Audio Hijack is its ability to affect your audio with things like noise gates and compressors. Like any audio effects, though, you want to hear the results of them to be sure you're sending high quality audio out to your listeners.

    Here's a workflow utilizing the AUDynamicsProcessor plugin as both a noise gate and compressor (see our tutorial about controlling AUDynamicsProcessor — the relevant part starts at the 3:03 mark). You can see how the Skype audio is loud enough to make it through while the background noise of my microphone is stopped and the AUDynamicsProcessor won't let it pass (until it gets louder). This can help to really clean-up your sound. By using low-latency monitoring you're hearing things at the record point, which means you'll hear immediately if your compressor or noise gate needs to be tuned better.

We've been testing low latency mode since mid-December and the Rogue Amoeba team has done a great job simplifying this previously arcane process. Every episode of Mac Geek Gab, Gig Gab, Small Business Show and our TMO Daily Observations podcasts for the past two months have been recorded with this with no issues whatsoever.

Next up: learn to utilize Rogue Amoeba's Loopback to allow your Skype guest(s) to hear the results of your effects ... and your theme music, too!

Comments

Guy B Serle 1

Looking forward to the Loopback tutorial. Every time I’ve tried to use the two together I’ve had my Mac screens go blank and then restart

plexus

I have been using Audio Hijack for awhile now. There are many issues with it that make it almost unusable. not so much for pod-casting. I am a musician and use AH to route my system audio through various AU plugins before going through one that is used to calibrate my monitoring. Every issues I have brought up with Rogue Amoeba they come back with “our engineers tested this and we can’t find the problem” or “your system is not-standard”. thing is, my system is standard. Here are a list of issues. many of these won’t impact you unless you are using AH in a professional audio situation where you are routing audio and using AU plugins:

1. the module dragging feature is hard to use because the modules will auto-connect based on proximity. if you move a module to close to another one it will connect to it. there is no way for the user to control this. so you are constantly having to tweek the position of modules on the screen to prevent this. also, the way modules connect is inconsistent changing from one use to the next.

2. in El Capitain, the Instant On audio interface will not work. for some reason RA puts the Instant On driver in the HAL plug-in folder - no other audio software I have does this including those that have drivers with similar functionality. Everything worked on my system with Yosemite but once I switched to El Capitain, the only thing that wouldn’t work is Audio Hijack. RA claims its because their IO driver goes in HAL and that perhaps with El Capitain HAL has some kind of security on it. in my system I symlink the entire Audio folder to another hard drive which is a perfectly legit thing to do. however RO insists that their driver has to be in HAL and for some reason under El Capitain, the OS doesn’t read the driver out of the symlinked HAL. RO claims that the other drivers in there for bluetooth and airplay for example will also not work. but they do. I’ve tested them. so I think this is another example of RO trying to weasel out of fixing a problem they caused.

3. Beware that AU plugins may not switch sample rates. for example I use a plugin that reports the sample rate its working at. it’s the only one I have that does this. whatever sample rate the plugin is set to on start up, stays that way regardless if you change the sample rate. for example, it might start up at 44.1k but I may switch the audio stream to 96k. the plugin will still be working at 44.1k - the impact of this is that there will be sample rate conversion going on and this is (horribly) audible. it means you can’t rely on AH to deliver a bit perfect stream and it’s hard to know exactly what sample rates are being used in AH. AH refused to address this despite my continued attempts to get them to understand the impact of this on professional audio work.

It does it what it does but it doesn’t do it well. My advice is look for a better option especially if you are using AH to route audio through plugins in your system and ultra-especially if you need to rely on a robust bit perfect data stream, you won’t get that with AH.

Log in to comment (TMO, Twitter or Facebook) or Register for a TMO account