DEV Community: Thales Brederodes

macOS Still Has No Volume Mixer, So I Built One

Thales Brederodes — Wed, 17 Jun 2026 20:24:30 +0000

macOS has never had a proper per-app volume mixer.

On Windows, this is basic. You can lower Spotify, mute a browser, keep a meeting app loud, and leave the rest of the system untouched.

On macOS, you usually get two options:

change the entire system volume
hope each app has its own volume control

That always felt strange to me.

So I built Mimir a macOS menu bar app that lets you control the volume of individual apps.

Full source code is on GitHub: github.com/ThalesBMC/Mimir

The interesting part is that this is now possible without kernel extensions, virtual audio drivers, or routing hacks.

Starting with macOS 14.2, Apple introduced the Core Audio Process Tap API. It lets you capture and process audio from individual apps directly.

This article is a technical breakdown of how I used it to build a per-app volume mixer in Swift.

The basic idea is simple: capture audio from a process, mute the original output, process the stream yourself, apply gain, and send it back to the output device.

The flow looks like this:

App audio output
-> Process Tap
-> Aggregate Device
-> IOProc callback
-> Default output device

The key detail is .mutedWhenTapped. When this mode is enabled, the app audio no longer goes directly to the output device. Instead, it is routed through your tap, where you can apply volume changes, mute it, or measure levels in real time.

First, you need to find the process AudioObjectID, because Core Audio does not work directly with PIDs:

static func findProcessObjectID(for pid: pid_t) -> AudioObjectID? {
    var propertyAddress = AudioObjectPropertyAddress(
        mSelector: kAudioHardwarePropertyProcessObjectList,
        mScope: kAudioObjectPropertyScopeGlobal,
        mElement: kAudioObjectPropertyElementMain
    )

    var propertySize: UInt32 = 0

    guard AudioObjectGetPropertyDataSize(
        AudioObjectID(kAudioObjectSystemObject),
        &propertyAddress,
        0,
        nil,
        &propertySize
    ) == noErr else {
        return nil
    }

    let count = Int(propertySize) / MemoryLayout<AudioObjectID>.size
    var objectList = [AudioObjectID](repeating: 0, count: count)

    guard AudioObjectGetPropertyData(
        AudioObjectID(kAudioObjectSystemObject),
        &propertyAddress,
        0,
        nil,
        &propertySize,
        &objectList
    ) == noErr else {
        return nil
    }

    for objectID in objectList {
        var processPID: pid_t = 0

        var pidAddress = AudioObjectPropertyAddress(
            mSelector: kAudioHardwarePropertyProcessPID,
            mScope: kAudioObjectPropertyScopeGlobal,
            mElement: kAudioObjectPropertyElementMain
        )

        var pidSize = UInt32(MemoryLayout<pid_t>.size)

        let err = AudioObjectGetPropertyData(
            objectID,
            &pidAddress,
            0,
            nil,
            &pidSize,
            &processPID
        )

        if err == noErr, processPID == pid {
            return objectID
        }
    }

    return nil
}

Once you have the process object, you can create a tap for that app:

@available(macOS 14.2, *)
func createProcessTap(for processObjectID: AudioObjectID) throws -> AudioObjectID {
    let tapDescription = CATapDescription(
        stereoMixdownOfProcesses: [processObjectID]
    )

    tapDescription.uuid = UUID()
    tapDescription.muteBehavior = .mutedWhenTapped

    var tapID: AudioObjectID = kAudioObjectUnknown
    let err = AudioHardwareCreateProcessTap(tapDescription, &tapID)

    guard err == noErr else {
        throw NSError(domain: NSOSStatusErrorDomain, code: Int(err))
    }

    return tapID
}

At this point, you have a Core Audio object representing the audio stream of a specific app. But you still cannot attach an IOProc directly to the tap. For that, the tap needs to be wrapped in an aggregate device together with the real output device:

func buildAggregateDescription(
    outputUID: String,
    tapUUID: UUID,
    name: String
) -> [String: Any] {
    [
        kAudioAggregateDeviceNameKey: name,
        kAudioAggregateDeviceUIDKey: "SoundManager-\(tapUUID.uuidString)",
        kAudioAggregateDeviceTapListKey: [[
            kAudioSubTapUIDKey: tapUUID.uuidString,
            kAudioSubTapDriftCompensationKey: true
        ]],
        kAudioAggregateDeviceSubDeviceListKey: [[
            kAudioSubDeviceUIDKey: outputUID
        ]],
        kAudioAggregateDeviceMainSubDeviceKey: outputUID,
        kAudioAggregateDeviceIsPrivateKey: true
    ]
}

Then create the aggregate device:

var aggregateDeviceID: AudioObjectID = kAudioObjectUnknown

let err = AudioHardwareCreateAggregateDevice(
    description as CFDictionary,
    &aggregateDeviceID
)

guard err == noErr else {
    throw NSError(domain: NSOSStatusErrorDomain, code: Int(err))
}

One subtle detail: after AudioHardwareCreateAggregateDevice returns, the device may not be ready immediately. In practice, you should wait or poll before starting the IOProc, otherwise audio can fail silently or behave inconsistently.

The actual volume control happens inside the real-time audio callback:

AudioDeviceCreateIOProcIDWithBlock(
    &deviceProcID,
    aggregateDeviceID,
    queue
) { [weak self] _, inInputData, _, outOutputData, _ in
    self?.processAudio(inInputData, to: outOutputData)
}

The callback should stay boring and predictable: no allocations, no locks, no Objective-C calls, no logging, and no work that could block. It should only read samples, apply gain, and write the result:

private func processAudio(
    _ input: UnsafePointer<AudioBufferList>,
    to output: UnsafeMutablePointer<AudioBufferList>
) {
    let inABL = input.pointee
    var outABL = output.pointee

    guard inABL.mNumberBuffers > 0,
          outABL.mNumberBuffers > 0 else {
        return
    }

    let inBuffer = inABL.mBuffers

    let frameCount = Int(inBuffer.mDataByteSize) /
        (MemoryLayout<Float32>.size * 2)

    guard let inData = inBuffer.mData?.assumingMemoryBound(to: Float32.self),
          let outData = outABL.mBuffers.mData?.assumingMemoryBound(to: Float32.self) else {
        return
    }

    for i in 0..<(frameCount * 2) {
        currentVolume += (targetVolume - currentVolume) * rampCoefficient
        outData[i] = inData[i] * currentVolume
    }
}

The ramp is important. Changing gain instantly can create audible clicks, so smoothing the transition over a few milliseconds makes the app feel much better:

let rampTimeSeconds: Float = 0.030

rampCoefficient = 1 - exp(
    -1 / (Float(sampleRate) * rampTimeSeconds)
)

Output device changes are another important part of the implementation. When the user connects headphones or switches audio output, the aggregate devices need to be recreated using the new default output device. Otherwise, audio may stop working silently.

You can listen for changes to kAudioHardwarePropertyDefaultOutputDevice:

func startDeviceChangeListener() {
    var propertyAddress = AudioObjectPropertyAddress(
        mSelector: kAudioHardwarePropertyDefaultOutputDevice,
        mScope: kAudioObjectPropertyScopeGlobal,
        mElement: kAudioObjectPropertyElementMain
    )

    AudioObjectAddPropertyListenerBlock(
        AudioObjectID(kAudioObjectSystemObject),
        &propertyAddress,
        queue
    ) { [weak self] _, _ in
        self?.handleDeviceChange()
    }
}

When the output device changes, the safest approach is to save state, invalidate the current taps, recreate everything against the new output device, and restore the previous volume and mute state:

func handleDeviceChange() {
    for (pid, tap) in activeTaps {
        tapStates[pid] = (
            volume: tap.volume,
            muted: tap.isMuted
        )
    }

    for tap in activeTaps.values {
        tap.invalidate()
    }

    activeTaps.removeAll()

    for pid in tapStates.keys {
        guard let tap = ProcessTapController(pid: pid) else {
            continue
        }

        if let state = tapStates[pid] {
            tap.volume = state.volume
            tap.isMuted = state.muted
        }

        try? tap.activate()
        activeTaps[pid] = tap
    }
}

Modern apps also make process detection tricky. Browsers, Electron apps, and WebKit-based apps often play audio through helper processes. For a good user experience, those helpers should be grouped under the main app instead of showing duplicate or confusing sliders.
In short, the Core Audio Process Tap API finally makes per-app volume control on macOS possible in a much cleaner way than older approaches.

The implementation comes down to:

Find the audio process.
Create a process tap.
Wrap it in an aggregate device.
Attach an IOProc.
Apply gain in real time.
Recreate everything when the output device changes.

The hard parts are not the main concept, but the details around permissions, tap lifecycle, helper processes, device changes, and staying real-time safe inside the audio callback.

That is how I built Mimir!

Source code: github.com/ThalesBMC/Mimir

How to Block Twitter (X) Feed on Safari on macOS

Thales Brederodes — Sun, 11 Jan 2026 14:53:11 +0000

If you’re looking for a way to block Twitter (X) on Safari and stop doomscrolling on macOS, you’ll quickly notice that Safari doesn’t offer any built-in way to hide or limit the feed.

Once you open X, the algorithm takes over — and minutes (or hours) disappear.

Why Blocking Twitter Feeds Is So Hard

Most solutions rely on willpower:

“Just don’t scroll”
“Be more disciplined”
“Use focus mode”

But the problem isn’t discipline — it’s design.

Social feeds are built to keep you scrolling indefinitely, especially on platforms like X (formerly Twitter).

Do Website Blockers Actually Work?

Traditional website blockers are too extreme:

They block the entire site
They break workflows
They force you to unblock everything just to check messages or notifications

In practice, people disable them after a few days.

Blocking everything is rarely sustainable.

A Better Approach: Hide the Feed, Not the Platform

Instead of blocking X entirely, a better solution is to remove the feed itself.

That way, you can:

Check notifications
Read messages
Post when needed

Without getting trapped in the endless timeline.

A Safari Feed Blocker for X (Twitter) on macOS

LockBird is a Safari extension for macOS that hides the feed on X to stop doomscrolling directly in your browser.

Once enabled:

The timeline disappears
The visual loop is broken
You naturally close the tab sooner

No system-wide blockers.

No VPNs.

No tracking.

How to Stop Doomscrolling on X in Safari

The most effective way to stop doomscrolling isn’t resisting temptation — it’s removing the trigger.

By hiding the feed entirely, LockBird adds just enough friction to make scrolling impossible, while still letting you use X intentionally.

Is There a Safari Extension to Block Twitter Feeds?

Yes. LockBird is a Safari extension for macOS that hides the algorithmic feed on X (Twitter), helping you stay focused without blocking the entire site.

Everything runs locally in Safari, and no data is collected or shared.

If you’ve been searching for a way to block Twitter feeds on Safari and stop doomscrolling on macOS, this is one of the simplest approaches available.

How to Limit Open Tabs on Safari on macOS

Thales Brederodes — Sun, 11 Jan 2026 14:45:47 +0000

If you’re looking for a way to limit open tabs in Safari on macOS, you’ll quickly notice that Safari doesn’t offer a built-in tab limit.

You can open unlimited tabs, which often leads to tab overload, loss of focus, and cluttered workflows.

Why Safari Doesn’t Let You Limit Open Tabs

Safari is designed to be flexible, but that flexibility comes at a cost. By default, there’s no restriction on how many tabs you can open, which makes it easy to postpone decisions and keep everything “just in case.”

Over time, this creates cognitive overload rather than helping productivity.

Do Safari Tab Groups Solve Tab Overload?

Tab Groups help organize tabs, but they don’t actually prevent overload. You can still open unlimited tabs inside each group, which means the core problem remains: there’s no guardrail.

Organization is not the same as limitation.

A Simple Tab Limit Extension for Safari on macOS

Instead of managing tabs after the chaos starts, a better approach is to stop the chaos before it happens.

A tab limit creates a clear boundary: once you reach a certain number of tabs, Safari simply won’t open more.

How to Stop Opening Too Many Tabs in Safari

The most effective way to stop opening too many tabs isn’t relying on willpower — it’s adding a hard constraint.

When new tabs are blocked after a limit, you’re forced to either close existing ones or finish what you started.

Is There a Safari Extension to Limit Tabs?

Yes. TabCap is a Safari extension for macOS that lets you set a maximum number of open tabs. Once the limit is reached, Safari won’t open new tabs until you close existing ones.

If you’ve been searching for a way to limit tabs in Safari on macOS, this might be the simplest solution available.

I Built a 3D Global Radio Map with Next.js and Three.js

Thales Brederodes — Sat, 26 Apr 2025 03:38:32 +0000

I want to share how I developed Vibe Radio, a project that places radio stations from around the world on an interactive 3D globe.
It was a fascinating journey where I learned a lot about 3D visualization, Three.js, and managing geographic data.

Tech Stack

Next.js for the frontend
Three.js via React Three Fiber for 3D graphics
TypeScript
Radio Browser API for station data
Tailwind CSS for styling

The Most Interesting Challenges

Creating the 3D Globe
The core of ViberRadio is the interactive 3D globe. Building it involved several fascinating challenges:

// Earth component with continuous rotation and stations
const Earth = ({ stations }: { stations: Station[] }) => {
  const earthRef = useRef<THREE.Mesh>(null);
  const globeGroupRef = useRef<THREE.Group>(null);

  // Load textures
  const textures = useTexture({
    earthTexture: "/earth-texture.jpg",
    cloudsTexture: "/clouds-texture.png",
  });

  // Continuous rotation animation
  useFrame(() => {
    if (globeGroupRef.current) {
      // Rotate the entire group
      globeGroupRef.current.rotation.y += 0.0005;
    }
  });

  // ...rest of the component
}

Mapping Coordinates to 3D Space
One of the most interesting technical challenges was converting latitude and longitude coordinates to positions on the 3D sphere:

const latLngToPosition = (
  lat: number,
  lng: number,
  radius: number = 1
): [number, number, number] => {
  const phi = (90 - lat) * (Math.PI / 180);
  const theta = (lng + 180) * (Math.PI / 180);

  const x = -radius * Math.sin(phi) * Math.cos(theta);
  const y = radius * Math.cos(phi);
  const z = radius * Math.sin(phi) * Math.sin(theta);

  return [x, y, z];
};

This mathematical transformation takes a station's geographic coordinates and places it precisely on the globe's surface.
It was exciting to see stations appear exactly where they should be in the world!

What I Learned

This project taught me a powerful lesson: everything is possible today.

With the right mindset, AI tools like Cursor and Claude 3.7 Sonnet, and a willingness to build step-by-step, you can create projects that once felt out of reach.

Even complex applications like 3D visualization, real-time data management, and interactive maps become achievable if you break the process down and trust the journey.

You don't have to know everything from the start, you just have to start.

If you have an idea in your mind, go for it. Build it, experiment, and let the tools and technology help you evolve along the way.

Try It Out!

Visit Vibe Radio to explore radio stations from around the world.
Click on any dot to tune in to that station!

The project is fully open-source:
👉 GitHub Repository

If you enjoyed this project, feel free to leave a ❤️, follow me here or on GitHub, and share your ideas or feedback! 🚀

Would love to hear what you think or see your own creations too!
Happy listening! 🎶🌎