Why Daisy stopped hearing the other side — and what we changed

On September 23 two people wrote to us with the same complaint: Daisy was not recording the other side of their calls, and for one of them it “stopped recording after the eleventh minute.” Both sent their diagnostic logs. This is what the logs showed, what we changed, and what we still have not solved.

Reported

September 23, 2026 — two users, Mac

Symptom

The other side of a call missing from the transcript, from the start or partway through

Fixed in

1.0.8.2 (stable, September 23) and 1.0.8.11 (stable, September 24)

Still open

Bluetooth output on macOS 14.0–14.3

How Daisy hears the other side

Daisy records two things during a call: your microphone, and the sound your Mac plays — the other participants. The second track is what goes missing when the symptom appears. Your own voice was recorded correctly in every case we looked at; what was lost was everyone else.

Fault one: Daisy gave up after the third restart

On the first user's Mac, macOS stopped the system-audio stream every few minutes with the error “The system stopped the stream.” Daisy restarted it each time, and each restart worked — sound came back for another one to seven minutes. But Daisy allowed three restarts per recording. After the third stop it stopped trying, and recorded only the microphone until the end of the meeting.

“After the eleventh minute” was exactly that: the meeting started at 16:59:32, the third stop came at 17:10:22. The budget was meant to catch a stream that dies right after every restart. It fired instead on a stream that lived for minutes and died again — a stream that was worth restarting forever.

Fault two: a warning nobody could see

Daisy did notice. It showed “Daisy stopped hearing the other side” as a small pill on its floating widget, plus a toast inside the Daisy window that disappeared after 2.6 seconds. A macOS notification was sent only if the pill could not be shown. During a call people look at the call, not at a widget in the corner — so the one message that mattered went unseen, and both users learned what had happened from the transcript, afterwards.

Fault three: Bluetooth headphones gave Daisy silence

The second user wore Bluetooth headphones. Here the stream did not die — it never delivered a single frame. Daisy's log noted it 35 seconds in (“silent stream detected”) and then said nothing for the whole 43-minute meeting.

We first took this for a macOS limitation. It is not: other Mac note-takers record through Bluetooth headphones. The cause was ours. When a call app takes the headset's microphone, the headset switches into call mode — lower sample rate, a single channel, sometimes a different audio route. If that switch lands while Daisy is setting up capture, the stream binds to a route that no longer exists and stays silent. Daisy listened for output changes only after setup finished, and only for a change of device — while call mode keeps the same device and changes its format.

And one more: a new recording cancelled the last one's final pass

After a meeting ends, Daisy runs a slower, more accurate transcription pass over the saved audio. On the second user's Mac that pass was 88 seconds in when a new recording started — and the new recording cancelled it. The meeting kept only its live transcript. The audio was still on disk, so nothing was lost for good, but nothing told the user either.

And the fixes weren't reaching most people

While checking versions we found that our stable channel had been on 1.0.7.63 since August. Everything fixed in the month since was marked beta, and the website gave new users the August build. The second user had installed it the day before. Fixes that sit in beta do not help anyone on stable.

What shipped on September 23 — Daisy 1.0.8.2

• Restarts are budgeted per two-minute window, not per recording: up to three inside any 120 seconds. Past that, Daisy keeps retrying after 5, 15 and 30 seconds, then once a minute until the recording ends. It no longer gives up for the rest of a meeting. Replayed against the first user's own timestamps, all eight stops across both meetings would have been restarted.
• Losing the other side is loud: a macOS notification every time, alongside the pill; a toast that stays until you close it; and a Restart capture button in both, so the fix is not “stop and start again.”
• With Bluetooth output, if no sound arrives within 35 seconds Daisy says so straight away, with what to do.
• Repetition loops that a dying stream leaves behind (“I know that I know that I know…”) are removed from the text. The filter was checked against 49 real transcripts, 7,173 lines: it removed the loops and nothing else.
• An interrupted final pass goes back into the queue and finishes later, instead of being cancelled.
• When a downloaded update is waiting and nothing is recording, Daisy offers to install it — never during a recording.

1.0.8.2 went straight to the stable channel, skipping the intermediate builds: each extra update is one more moment when an older Daisy could restart in the middle of a meeting.

What shipped on September 24 — the Bluetooth fix

• Daisy starts listening for output changes before it builds the capture, so a switch during setup is seen and answered with a quiet rebuild.
• It also watches the output device's own sample rate and channel layout — the change call mode actually makes.
• On macOS 14.4 and newer, Daisy now captures system audio with a Core Audio process tap by default. The tap reads sound below device routing, so a headset flipping into call mode is not an event for it. It asks for its own, narrower permission — System Audio Recording, not Screen Recording — once, on its own screen rather than in the middle of a call.
• If the tap hears nothing for two minutes, the same recording moves to the previous method on the fly, with the timeline kept intact.
• The warning now clears itself when the other side comes back and says so. A third user found that in 1.0.8.2 it could stay on screen after switching from headphones to speakers — the recording was fine, the alarm was false.

We tested it on Bluetooth earbuds in call mode, and the other side was recorded. These changes reached the stable channel in 1.0.8.11 on September 24.

What is still open

• macOS 14.0–14.3 with Bluetooth output. The process tap needs macOS 14.4. On older versions Daisy now tells you within 35 seconds, but it still cannot hear the other side through Bluetooth: use wired headphones or the speakers, or update macOS.
• We have tested one pair of Bluetooth earbuds in call mode. More headsets, AirPods included, are next.
• The first user's stream stops correlate with an unstable USB headset, but the logs cannot prove the cause. The restart budget makes it harmless; we do not claim to know why macOS stops the stream.

What we take from it

A failure that costs the rest of a meeting has to be loud, and has to come with a way out. A retry costs seconds; giving up costs the meeting. And a fix is only a fix once it reaches the channel people actually use.