Unfortunately, much more often than I’d like, the code I’m seeing from both groups breaks one or more of the cardinal rules of working with audio. My work with Audiobus and The Amazing Audio Engine tends to bring me up close and personal with a lot of other developers’ code, both newcomers to the field, and developers working for big-name companies. So, although there is a high horse present in this article, consider me standing beside it pointing at it, rather than sitting on top of it. I make mistakes, I let bugs slip through, although I try my darnedest to keep it to a minimum. All of the time.įirst of all, a quick aside: I’m not a perfect software developer - not by a long shot. So, it’s this duty of care that we audio developers have that I want to focus on in this article, because our music apps have to be solid and reliable. It’s an angry Facebook post to all of their musician friends waiting to happen the exact opposite of what anyone reading this would want. And so every app they’re using is indicted. The one thing they cannot troubleshoot in their setup is their apps, because it’s an opaque system. It can take just one glitch during a live performance for a musician to completely lose faith in their whole setup. And I’ll bet most music apps have a higher glitch rate than that. Two glitches a day if it has twenty thousand sessions a day. The audio engineer on The Tonight Show told me the main reason that they chose Loopy for the looping segments with guests was because he had been a Loopy user for years, and it has always been solid and reliable.Įven if there’s just a one-in-ten-thousand chance that an app will glitch during a typical session, well, that’s one glitch a day if your app sees ten thousand sessions per day, which is not uncommon. Imagine if Loopy HD had glitched in the middle of that? Now we’re living in a post-Audiobus/IAA world, where our users’ setups often span multiple apps, one bad actor can mess everything up, and it’s often impossible to tell from where the problem originates. Same goes for in private - if the user just nailed a take, only to discover that there’s a giant click in the middle of the recording, they’re going to be cursing our name. Nor will a performer whose backing drum machine clicks and crunches distractingly, throwing the performance. ![]() A DJ whose equipment emits an ear-piercing crunch mid set will not thank us (well, it depends on the club. As audio developers we have a responsibility to our users to, basically, not embarrass them in public. Making audio apps is enormous fun - it’s rewarding, there’s huge scope for creativity, and then when you’re done, other people use it to be creative too! There aren’t many fields that are like that, and I consider myself very fortunate to be able to work in this area.īut there’s also a serious side to working with audio. I introduce Realtime Watchdog, a diagnostic tool for developers, and provide a brief survey of popular audio libraries. ![]() It’s written primarily for developers, but should be accessible to non-developers too. I suppose another approach would be to just fill an 8 sec buffer in memory from your callbacks, and when it's full, have another thread write that file while you malloc a new buffer and start recording into that (obviously, the file writer would dispose the old buffer when it's done).Įdit: Also, I didn't see anything about Swift in your question, but any of this should work fine from Swift or C/Obj-C.This is a discussion of four common mistakes that audio developers make, how to do better, and how to detect whether there’s a problem. You could receive the raw PCM a number of ways (in AV Foundation: AVCaptureAudioDataOutput from an AVCaptureDevice, or AVAudioEngine with a processing tap inserted in Audio Toolbox: Audio Queue Services, the RemoteIO audio unit), then to write the file, you could use Audio Toolbox's AudioFile or ExtAudioFile, just counting up how many frames you've written and deciding when it's time to start a new 8 sec file.Īs Rhythmic Fistman notes above, it would be safer if you did something likeĬapture callbacks -pushes-to-> ring buffer <-pulls-from- file-writing codeīecause when you're closing one file and opening another, the capture callbacks are still going to be coming in, and if you block on file I/O you stand a very good chance of dropping some data on the floor.
0 Comments
Leave a Reply. |