Tag Archives: Audio

Thirteen Months of Audiobus: Part 2

This is the long awaited sequel to the tale of Audiobus’ development. I’m completing this article now, on the day we say an emotional farewell to our motorhome Nettle, who has today been sold to a new family in the UK. It seems like a fitting time to tie off some loose ends as we start the next chapter of our lives in our new home in Australia.

In Part 1 of this article, I wrote about the early stages of the technology which was to become Audiobus, our inter-app audio platform, now supported by over 500 great music apps. Part 1 ended just as Sebastian had one of his genius moments, which I obnoxiously left as a cliffhanger. So, onwards:

It was winter in the south of France, and I was buried in the best kind of work: A new project, and one that brought together a bunch of different interests into a challenging, exciting heap.

But first, it was time to move on and find a more satisfying place to spend the rest of the winter.

Read More »

Also tagged , , , , , , | 1 Comment

Help! iOS 7 broke my microphone input!

We hear a lot about people having problems with their music apps on iOS 7 no longer receiving audio. I thought it was time I posted an article describing why this is happening, and how to fix it.

iOS 7 introduced a bunch of new security and privacy features and restrictions. In particular, when an app wants to record audio, iOS 7 will block the app from doing so until the user gives permission. Usually this happens via an alert dialog in the app:

Screen Shot 2013 10 23 at 12 41 10

However, if one taps “Don’t Allow”, the system won’t ask again — ever. That can spell confusion and frustration (and support emails, and 1-star App Store reviews!) for users who tapped the dialog away without reading it, and then discovered they’re unable to record audio.

Alas, there’s not much that can be done about that from our end, except for explaining how to fix the issue once this happens.

The trick is to open Privacy Settings for the device, and enable Microphone access for the app. The controls can be found in the system Settings app:

Screenshot 2013 10 23 12 55 54

Screenshot 2013 10 23 12 29 13

Once you’ve turned this on, the app should begin receiving audio. Depending on certain factors, you may need to quit and restart the app.

Also tagged , | Comments closed

The Amazing Audio Engine is here, and it’s open source and Audiobus-ready


I’m very pleased to announce that The Amazing Audio Engine has pulled into the station. It’s been a long time in the making, and there have been one or two minor distractions along the way, but I’m proud of the result:

A sophisticated and feature-packed but very developer-friendly audio engine, bringing you the very best iOS audio has to offer. We’re talking audio units, block or object-based creation and processing, filter chains, recording and monitoring anything, multichannel input support, brilliant lock-free synchronization and rich Audiobus support.

You’ll find The Engine, a bunch of documentation and the brand-new community forum at

It’s also open source. And it’s ready for Audiobus.

Also tagged , , | Comments closed

Thirteen Months of Audiobus

Tomorrow, Monday December 10, my friend and partner-in-crime Sebastian Dittmann and I are launching a project over twelve months in the making: Audiobus. We’re very proud of what we’ve managed to do, and we both firmly believe that Audiobus is going to fundamentally alter the way people create music on the iPad and iPhone.

You can find out more about Audiobus itself at, but I wanted to take a moment to breathe, look back, and explain why the hell I’ve been so quiet over the last year. Read More »

Also tagged , , , , , , | Comments closed

The Amazing Audio Engine: Funky Remote IO-based Core Audio Engine Coming Soon

The Amazing Audio EngineHuzzah! I’m announcing a new project which will be launching over the next couple of months.

It’s called The Amazing Audio Engine, and it represents the product of years of experience with iOS audio. It’s a sophisticated iOS audio engine that lets developers skip the Core Audio learning curve, and get on with writing great software.

The tech behind this is what drives Loopy and Loopy HD, as well as the in-development Audiobus app.

Subscribe at to be kept in the loop as it approaches launch time.

Some of the features:

  • Automatic mixing of multiple audio signals with per-channel volume and pan controls.
  • Built-in support for audio filtering and effects, including the ability to form complex filter chains, constructing channel groups, or even whole trees of groups, and filtering them as one composite signal.
  • Built-in support for audio input, including optional use of the Voice Processing IO unit, for automatic echo removal – great for VoIP.
  • Record or monitor the output of the whole audio system, for in-app session recording, or get the output of one channel, or any group of channels in the processing tree.
  • Support for any audio format (AudioStreamBasicDescription) that the hardware supports: Interleaved, non-interleaved, mono, stereo, 44.1kHz or any other supported sample rate, 16-bit, 8.24 fixed floating-point – whatever you need for your project.
  • Very light, efficient engine, designed from the ground up for speed. All Core Audio code is pure C; no Objective- C or BSD calls, no locks, no memory allocation.
  • Efficient mixing of input signals, using Apple’s MultiChannelMixer.
  • Fast, lock-free synchronisation mechanism, enabling developers to send messages to the main thread from the Core Audio context, and vice versa, without locking or memory allocation from the Core Audio thread. Message sending from the main thread is two-way, and can be asynchronous, with a response block, or synchronous.
Also tagged , , , , | Comments closed

Some updates to TPCircularBuffer

I’ve recently made some updates to TPCircularBuffer (on GitHub), my C circular/ring buffer implementation, which add a memory barrier on read and write, inline the main functions for a potential performance boost, and add support for use within C++ projects.

If you’re using TPCircularBuffer at all, I recommend updating!

Also tagged , , , , | Comments closed

Circular (ring) buffer plus neat virtual memory mapping trick

I’ve just updated my C circular buffer implementation, adopting the trick originally proposed by Philip Howard and adapted to Darwin by Kurt Revis: A virtual copy of the buffer is inserted directly after the end of the buffer, so that you can write past the end of the buffer, but have your writes automatically wrapped around to the start — no need to manually implement buffer wrapping logic.

This dramatically simplifies the use of a circular buffer — you can use chunks of the buffer without any need to worry about where the wrap point is.

See the new implementation, which is thread-safe with one consumer and one producer, with no need for locks, making it perfect for use with high-priority Core Audio threads, on GitHub: TPCircularBuffer.

There’s a basic example of its use over on the original post.

Also tagged , , , | Comments closed

Experiments with precise timing in iOS

iOS is by no means a realtime operating system, but I’m aware that NSTimer and NSObject’s performSelector:withObject:afterDelay: mechanism aren’t particularly accurate, and I was curious to see whether I could do better.

Hands up, backing away

Disclaimer: I am not at all an expert in realtime programming, or Mach, or iOS-device optimisation, so this is pretty much a fumble in the dark. I won’t be at all offended if anyone wishes to shoot me down and offer a more sensible solution — in fact, please do! Until then, watch as I stumble on…

Also note that there are often ways to eliminate the need for precise timing of this nature, by architecting code appropriately — when it comes to audio, for example, CoreAudio provides a very accurate time base in render callbacks. For things like metronomes or audio synthesizers, it’s always better to establish a starting time, and use the difference between the current time and the starting time in order to determine state, rather than using a timer to advance the state. Still, sometimes, you just need a timer…

What the blazes?

So, I’m working on an update to Loopy, which uses a shared clock object to synchronise tracks and a variety of events (like user interface updates or timed track manipulations). A tester noted that the mute/unmute quantisation feature that I’ve recently implemented, which will mute or unmute a loop at its starting point (rather than whenever you tap it), tends to overshoot a little, resulting in a small part of the beginning of the loop being audible.

Of course, there are other solutions to this particular problem (like stopping or starting playback from the audio render callback, and using Core Audio’s timestamps for exact timing), but I use timers in other places outside Core Audio’s domain, which makes Core Audio’s timing mechanism unavailable, and I wanted to see how accurate I could get the timing.

Our friend, mach_wait_until

I read in several places mention of the Mach API utility mach_wait_until (from mach/mach_time.h), which is very low-level and supposedly fairly accurate. So, based on that lead, I put together an Objective-C singleton class that launches a high-priority thread, and uses said thread to schedule events.

An NSArray of events are maintained, and a scheduleAction:target:inTimeInterval: routine creates and adds events to this array, then pokes the thread.

The thread grabs the next event in sequence, then uses mach_wait_until to sleep until the time of the next event arrives, then performs the specified action on the target. It’s kinda a DIY NSRunLoop.

Here’s a comparison between this technique, and just using performSelector:withObject:afterDelay: (which schedules a timer on the NSRunLoop), observed while performing various scheduled events within Loopy running on my iPhone 4 with the debugger, and derived by comparing the time of event execution with the event’s scheduled time:

MechanismAverage discrepancyMinimum discrepancyMaximum discrepancy

That was attempt number 1: This seems to give us about 11.4ms better accuracy on average (three times more accurate).

Not bad, but it turns out mach_wait_until isn’t really that accurate, particularly if there’s a bunch of other stuff going on in other threads.

Spinning, for fun and profit

For my second attempt, the thread performs a mach_wait_until until just before the event is due, then performs a spin lock until the time arrives, using mach_absolute_time to compare the current time with the target time.

This gave further improved results — here’s that table again, but with the new scheme added, with a few different spin lock times:

MechanismAverage discrepancyMinimum discrepancyMaximum discrepancy
TPPreciseTimer (original)5.5ms0.033ms72.0ms
TPPreciseTimer (10ms spinlock)6.0ms0.002ms76.5ms
TPPreciseTimer (100ms spinlock)3.7ms0.002ms44.8ms
TPPreciseTimer (200ms spinlock)2.91ms0.002ms74.1ms

It appears that the more stuff there is going on in other threads, the more likely the mach_absolute_time call is to overshoot. So, the more time spent in the spin lock, the more leeway mach_absolute_time has to wait too long. Of course, that’s at the cost of making the CPU twiddle its thumbs for the duration.

Better than a punch in the knee

The results weren’t quite as fantastic as I’d hoped — still within the same order of magnitude, that’s for sure — but the average case for the 200ms spinlock approach is 14ms, or 5.8 times, more accurate than the traditional approach, and the minimum case is dramatically better.

You know, I think if I was aware of the results in advance, I might not bother, but I’ll stick with my hard-won 14ms now that I’m here (that’s 617 audio samples, I’ll have you know).

If anyone’s curious about the implementation (or wants to take a stab at doing better), here it is, along with a wildly simplistic commandline test app:

Now to get back to some real work.

Addendum: GCD follow-up

Chris in the comments below suggested trying a GCD-based approach, using dispatch_after. Curious, I rigged it up, and these are the stats, collected the same way as above, added to the prior table:

MechanismAverage discrepancyMinimum discrepancyMaximum discrepancy
TPPreciseTimer (original)5.5ms0.033ms72.0ms
TPPreciseTimer (10ms spinlock)6.0ms0.002ms76.5ms
TPPreciseTimer (100ms spinlock)3.7ms0.002ms44.8ms
TPPreciseTimer (200ms spinlock)2.91ms0.002ms74.1ms
dispatch_after (main queue)14.8ms0.16ms161.2ms
dispatch_after (dedicated queue)19.2ms0.1ms174.9ms
dispatch_after (dedicated queue + 100ms spinlock)22.4ms0.002ms306.8ms

So, they appear pretty much the same as the NSRunLoop stats.

Also tagged , , | Comments closed