extension AVPlayer {
    func fadeAudio(from startVolume: Float, to endVolume: Float, duration: Double) {
        let audioMix = AVMutableAudioMix()

        audioMix.inputParameters = (player.currentItem?.tracks ?? [])
                                    .compactMap(\.assetTrack)
                                    .filter({ $0.mediaType == .audio })
                                    .map { track in
            let currentTime = player.currentTime()

            let parameters = AVMutableAudioMixInputParameters(track: track)

            parameters.setVolumeRamp(fromStartVolume: startVolume,
                                     toEndVolume: endVolume,
                                     timeRange: CMTimeRange(start: currentTime,
                                                            duration: CMTime(seconds: duration,
                                                                             preferredTimescale: currentTime.timeScale)))

            return parameters
        }

        player.currentItem?.audioMix = audioMix
    }
}

I’m not certain what curve this implements, but to my ears it doesn’t sound quite as harsh as a naive linear ramp, so perhaps it’s an S-curve or similar.

Edge cases not handled

Where there’s less than duration time left in the track(s).

How you want to handle that might vary depending on context. e.g. you could clamp the duration to the remaining duration (but you have to think about whether your individual tracks all have the same duration, whether they match the duration of the overall playback item, and whether they’re all aligned within the playback sequence), or wrap it around to the beginning (if you’re looping), or carry the fade through to the next item (if you’re playing a sequence of items), etc. Alas this must be left as an exercise to you, the reader.

Starting a fade while another one is still in progress.

It will halt the previous fade, immediately jump to startVolume, and perform the new fade. If you know that a prior fade is in progress you could potentially extrapolate the current volume and start from there instead (though beware of non-linear ramping).

If you move the playhead backwards (e.g. skimming, or looped playback).

The mix will stay in place, and result in wonky volume levels on the subsequent plays through. To work around that, you can add:

player.currentItem?.audioMix = nil
player.volume = endVolume

…wherever you restart playback at the beginning or move playback earlier than the end of the fade.

Future work?

You can work around these limitations by doing a timer-based fade (i.e. player.volume += smallIncrement at regular, short intervals). However, the problem with that approach is that it’s not synchronised to actual playback – e.g. if the audio is paused, stutters, or faces an initial loading delay, your fade won’t wait for it, potentially resulting in no fade at all (e.g. it takes five seconds to buffer the audio before playback starts, at which point your five second “fade” has run to completion, so your audio starts playing abruptly at full volume).

There’s very likely a third option that addresses all these shortcomings, but I explored that a bit and concluded that it’d be a lot more work. If someone wants to explore that all the way, I’d be interested to see the result. But for many purposes the above code is quite sufficient.

Five minutes of some trivial testing shows that this is just not true.

Noise is still affected by input gain

Here’s a composed recording of four 3-second clips recording the room tone in my office. They are (in order): Auto gain, 57dB, 35dB, 0dB:

As you can hear, auto and maximum input gain in this case have very similar noise levels (which is to say, perceptually none), but as you reduce the recorder’s input gain (and instead apply the gain in post) the noise increases substantially and becomes very noticeable.

Granted this is a very big gain application – 57dB – which you would hopefully never need to apply to a real recording, but nonetheless it demonstrates that Tascam’s claims are exaggerations at best; if you actually had the Portacapture X8’s input gain set to 0dB and recorded quiet sounds, you would in fact have problems with noise – problems that would be avoided with a correct input gain setting.

Clipping still happens if input gain is too high

The recorder clearly applies actual analog amplification and can still saturate its ADCs, as shown in this composite of three gain levels. They are (in order): Auto gain, 35dB, 57dB.

Warning: annoying, distorted sound.

It only went over by about 3dB (at 57dB input gain), but that was enough to destroy the input signal and make the recording unusable.

Auto Gain still affects the recording

In the above tests I included the Auto Gain setting, even though it doesn’t exhibit particularly high noise nor does it clip in these simple sound environments (basically constant sound levels). And it worked pretty well (not optimal input gain levels, but close enough for my taste).

But, I was curious if it had any effect at all – again, reading about 32-bit floating-point recording online, you’d be forgiven for thinking Auto Gain has no impact on the actual recorded data. Many people liken the format to camera raw files, and some explicitly state that Auto Gain has no impact on the bits that get written to disk.

This is completely false, at least in the case of this Tascam Portacapture X8. It’s trivial to see why:

Auto Gain still does exactly what it always does – it changes the gain in response to the input. That change is baked into the recorded audio track(s).

So in a nutshell, 32-bit floating-point recording might provide slightly more flexibility in some situations, but it does not mean you can ignore your input level settings, it does not mean you can use Auto Gain in every scenario, and it does not mean you cannot clip.

Addendum: Technical details

I tested post-production gain changes in Final Cut Pro, Logic Pro, & Audacity. All produced the exact same results (to my ears). I had read that Final Cut Pro sometimes ‘bakes in’ clipping with 32-bit float inputs, as if it’s pre-rendering them down to some smaller dynamic range, so I wanted to rule out some Final Cut Pro-specific stupidity. It’s possible that all these editors are doing that, but I’d be flabbergasted if that’s true.

The “industrial noise” sample I used was my dehumidifier, which is about 66dB according to DecibelX on my iPhone 14 Pro. My office room tone is about 42dB according to the same app.

I used Sennheiser K6 modules with an ME65 and ME66 attached, plugged into the Tascam Portacapture X8 via 3′ Cable Matters XLR cables.

I recorded at 96kHz because that’s what I’ll use most often. I like the aliasing headroom above 48kHz (even though of course my final outputs are almost always 44.1kHz or 48kHz), but don’t see evidence that 192kHz provides meaningful additional benefit (and it also hurts the frequency response significantly, compared with 48kHz and 96kHz, according to Tascam).

They even put a picture of me on the cover, which seems mean [to their readers].

This was the follow-up to an article a year earlier that announced we three were set to intern at Apple.

I’m posting it here now because I apparently never did prior, and I’d just like to include it in my records. I actually remember reading the article, although oddly not providing any of the quotes used in it (I’m sure I did; I genuinely have just forgotten).

I’m not sure what I was referring to – if anything specific – regarding “so that’s how they do that!” but I do vaguely recall that it was indeed a real pleasure to have access to a lot of Apple frameworks’ source code. I dove into a whole bunch of it purely out of curiosity. Of course, fifteen years later I don’t remember anything about it.

I had forgotten – until I chanced upon this Wheels for the Mind article a few weeks ago – about Brett’s project entirely. I did vaguely remember that Ashley worked in the Core Audio team, although in my mind it was “FireWire audio” specifically that he was involved with. I vaguely recall some discussions about isochronous transport support – something unique to FireWire at the time, notably as opposed to its competitor USB – and its huge benefits for live audio. We [Apple fans] were all particularly bullish on FireWire and quite offended by the mass-market success of the comically inferior USB. So we relished specific examples where FireWire embarrassed USB, in terms of not just its speed but its basic capabilities (like live media).

I haven’t spoken with Ashley or Brett in what must be at least a decade – probably since about when our internship ended and we all separated once more on our return to Oz. We’d barely met before the internship – perhaps just at the AUC 2005 conference in Hobart; I know at least Brett was there for that – and being thrown together into a two-bedroom apartment in Cupertino. 😆

Where are they now?

I’m here now, obviously. 😜

Ashley interned at Apple at least twice more – in fact I think we ran into each other once or twice as a result, as I was there full-time by the time of his third internship at least. He eventually joined for real, as a full-time employee. And that’s where he still is! And still doing audio – from his early days with IEEE presentations to working on Milan (for synchronising clocks over a network, for AV media purposes specifically) to at least as recently as 2020 with work on IEEE 1722 (AVTP, Audio Visual Transport Protocol). As well as some AV timing-related working on 802.11 (wifi). And possibly more – digging through IEEE papers & websites is not the most entertaining nor rapid escapade. 😝

Brett appears to have done some iOS consulting and fitness coaching, of all things! That’s particularly poetic because – when we were Apple interns – we were all a bit plump; very stereotypical computer nerds. As his coach bio says:

Brett started at VidaFit doing an Overhaul back in 2014 as a self-proclaimed overweight, headache prone, generally sluggish computer geek.

He’s also been fighting Motor Neurone Disease on behalf of his sister and all its sufferers, which it seems led him into social media consulting and general computer support under the business name Little Brown Monkey – an ironic name, given how search-engine-hostile it is 😆. Apparently it’s based on sentimental value. Still, it’s particularly funny since “Brett Brooks” is a fairly common name – with multiple minor celebrities using it – so he is already a little hard to find.