A focused bug-fix release after yesterday’s v0.6.0-beta1. Four under-the-hood fixes that close stability gaps in the audio capture path.
Audio capture no longer drops under thread contention.
The real-time audio callback was using NSLock to protect shared state. NSLock goes through the kernel, which can cause priority inversion against the main thread — under heavy load, the kernel would drop the audio callback. Replaced with os_unfair_lock, a userland primitive that’s safe in real-time threads.
Audio after a mid-recording device switch is now playable.
v0.6.0-beta1 closed Bug C for transcription continuity — if you yanked AirPods mid-meeting, the transcript stayed continuous. But the underlying .caf file was split across system.caf + system.continued-N.caf siblings, and MeetingDetailView only played the first one. v0.6.0-beta2 concatenates all the siblings into a single system.caf when you stop the recording. Playback now covers the whole meeting.
Sample-rate changes mid-recording no longer corrupt audio. If the aggregate device’s nominal sample rate changes mid-meeting (e.g., you change it in Audio MIDI Setup, or another app forces a different rate), the Process Tap now rebuilds itself for the new rate instead of writing garbage PCM. Shares the same re-entrance guard as the Bug C device-identity rebuild, so a simultaneous device + rate change doesn’t double-rebuild.
Settings beta-channel toggle now flips instantly.
Was lagging one frame because the toggle’s backing was a computed property over UserDefaults, which @Observable can’t track. Added a stored backing var; SwiftUI now invalidates the view on flip.
If beta1 worked for you, beta2 will too — this release is strictly bug fixes with no behavioral changes outside the audio-pipeline edge cases above.
Existing beta channel testers get this within 24 hours via Sparkle. Or trigger now: Minutiva Private → Check for Updates… from the menu bar.