Transcription stops recording after ~1 hour, Mac gets hot

[hyper-charlie]

Description

Transcription crashes/stops recording during long in-person meetings (approximately 1 hour or longer). The Mac becomes noticeably hot during the process.

Steps to Reproduce

1. Start a meeting recording in Hyprnote
2. Allow transcription to run for ~1 hour or longer
3. Observe transcription behavior

Expected Behavior

Transcription should continue recording for the full duration of the meeting without stopping.

Actual Behavior

• App stops recording after ~1 hour
• Transcription halts mid-meeting
• Mac CPU gets hot
• Issue occurs consistently/repeatedly on long meetings

Environment

• Platform: macOS (aarch64)
• OS Version: macOS 26.3
• App Version: 1.0.10
• Build: 58a816d
• Audio Input: Device microphone
• Meeting Type: In-person

Additional Context

This appears to be a CPU/memory resource issue causing the transcription service to halt under sustained load.

[devin-ai-integration]

Codebase Exploration — Relevant Files & Analysis

Architecture Overview

The transcription recording pipeline is an actor-based system (using ractor) with three main child actors managed by a session supervisor:

1. SourceActor (crates/listener-core/src/actors/source/) — captures mic + speaker audio, runs AEC, VAD masking, and dispatches to listener/recorder
2. ListenerActor (crates/listener-core/src/actors/listener/) — streams audio to a remote STT provider via WebSocket
3. RecorderActor (crates/listener-core/src/actors/recorder/) — writes WAV to disk, encodes to MP3 on stop

Key Files

Area	File	Relevance
Session supervisor	crates/listener-core/src/actors/session/supervisor.rs	Manages lifecycle of all 3 actors; restart budget of 3 restarts in 15s window
Audio source & pipeline	crates/listener-core/src/actors/source/pipeline.rs	Per-chunk AEC + VAD processing, buffering when listener unavailable
Stream timeout	crates/listener-core/src/actors/listener/mod.rs:22	LISTEN_STREAM_TIMEOUT = 15 minutes — stream is dropped if no response in 15 min
Stream processing loop	crates/listener-core/src/actors/listener/stream.rs	Main recv loop with timeout logic
AEC (ONNX)	crates/aec/src/onnx/mod.rs	Runs 2 ONNX neural network models (FFT + IFFT) on every audio chunk — significant CPU per frame
VAD masking	crates/vad-masking/src/streaming.rs	Earshot VAD classifier runs on every audio chunk
Mic capture	crates/audio/src/mic.rs	Ring buffer-based mic capture (fixed 64KB buffer)
Speaker capture	crates/audio/src/speaker/macos.rs	CoreAudio tap-based speaker capture
Recorder	crates/listener-core/src/actors/recorder/mod.rs	Continuous WAV write, flush every 1s
Audio pipeline optimization	Commit 90cc850	Very recent (Mar 4) — major refactor of ring buffers, mic/speaker capture

Likely Contributing Factors

1. AEC (Acoustic Echo Cancellation) — Primary CPU suspect

crates/aec/src/onnx/mod.rs — The process_streaming() method runs on every audio chunk in the pipeline (pipeline.rs:81). Each invocation:

• Allocates a new Vec<f32> output buffer (_process_internal line 257: vec![0.0f32; audio.len()])
• Creates a full ProcessingContext with multiple FFT buffers and ndarray allocations (line 269)
• Runs 2 separate ONNX inference sessions (run_model_1 + run_model_2) per block
• Performs forward FFT + inverse FFT per block

Over 1 hour of continuous audio at 16kHz, this is tens of thousands of ONNX inference calls with per-call heap allocations. This is the most likely cause of both CPU heat and potential memory pressure.

2. LISTEN_STREAM_TIMEOUT = 15 minutes (not 1 hour)

crates/listener-core/src/actors/listener/mod.rs:22 — The stream timeout is 15 minutes, not 1 hour. If the upstream STT provider goes silent for 15 minutes, the listener actor self-terminates with StreamTimeout. This puts the session into degraded mode (source + recorder keep running, but transcription stops). The user may perceive this as "transcription stopped" while the app is still recording audio.

However, for an in-person meeting the STT provider should be sending regular responses, so this timeout alone wouldn't explain the 1-hour mark.

3. Supervisor restart budget exhaustion

crates/listener-core/src/actors/session/supervisor.rs:23-27 — The restart budget allows 3 restarts within 15 seconds, with a reset after 30s. If the listener or source actor fails repeatedly (e.g., due to resource pressure), the supervisor triggers a meltdown (line 412-427) which stops all actors and kills the session.

4. WAV file growth — unbounded disk write

crates/listener-core/src/actors/recorder/mod.rs — The recorder writes stereo 32-bit float WAV at 16kHz continuously. Over 1 hour: 16000 samples × 4 bytes × 2 channels × 3600 seconds ≈ 440 MB of uncompressed WAV. The hound::WavWriter buffers internally and flushes every 1 second. This growing file could contribute to memory pressure.

5. Per-chunk allocations in the audio pipeline

In pipeline.rs:dispatch(), every audio chunk goes through:

• AEC processing (allocates output vec)
• Arc::from() conversions (lines 93-94) — allocates new Arc for each chunk
• f32_to_i16_bytes() conversion for listener (lines 160, 164, 168-169) — allocates Bytes per chunk
• These allocations happen at ~62.5 Hz (16kHz / 256 chunk size) for each channel

Recent Changes Worth Noting

• 90cc850 (Mar 4, today!) — "perf) various audio pipeline refactor and optimization" — Major rewrite of mic.rs, speaker/macos.rs, new async_ring.rs and rt_ring.rs. Introduced ring buffer-based capture replacing previous approach. If the user's build (commit 58a816d) predates this, they don't have these optimizations.
• 4d9583dd6 — "refactor aec, marginal optimize" — AEC refactoring
• 88567b85 — "allow disabling AEC at runtime with env" — Added NO_AEC=1 env var to disable AEC
• 47aa41830 — "create resampler crate & bump rubato to v1" — Resampler changes

Diagnostic Suggestions

1. Test with NO_AEC=1 to isolate whether AEC is the CPU/thermal culprit
2. Check if the user's build (58a816d) is before or after the recent audio pipeline optimization (90cc850)
3. The user should check if transcription UI shows a "degraded" state indicator when it stops — this would confirm whether the listener actor died vs. the entire session crashed
4. Consider adding telemetry for: session duration at termination, actor that triggered meltdown, and peak memory usage during long sessions

Potential Improvements to Investigate

• Pool/reuse the AEC ProcessingContext instead of allocating per-call — it's created fresh in _process_internal on every invocation
• Pool the output Vec<f32> in _process_internal (line 257) instead of allocating per-call
• Consider a streaming AEC budget/throttle that skips AEC processing under thermal pressure
• The LISTEN_STREAM_TIMEOUT of 15 minutes may need to be longer or have a keep-alive mechanism for long meetings