Andromeda audio bridge: audio+video recording in Android apps intermittently fails (AudioRecord overruns/stalls)

[spollard]

Summary

Recording video with audio through an Android app in Andromeda fails intermittently (~1 in 3 attempts); recording with audio disabled always succeeds. Reproduced with two unrelated apps on two different recording stacks, both failing from the same cause — the bridged microphone capture (AudioRecord) is unreliable:

• Open Camera (MediaRecorder / Stagefright): the mic delivers data faster than it is consumed, AudioRecord logs repeated overruns, the AAC track finalizes malformed, and MediaRecorder.stop() returns -1007 (ERROR_MALFORMED) — the whole MP4 is discarded even though the H.264 video track encoded fine.
• Aperture (LineageOS default camera; CameraX / Jetpack Recorder): the mic delivers no samples at all — the audio source and AAC encoder start, but the first audio sample never arrives, so the muxer never starts (video keyframes are cached then dropped), the audio encoder times out, and the recording finalizes with ERROR_NO_VALID_DATA → no file is written, and the in-app recording timer never advances past 0.

Either way the bridged audio is lost and takes the whole recording with it; the video encoder is never at fault. The common root cause is the Andromeda audio bridge / Android AudioRecord capture path — depending on timing it either overruns (Open Camera) or stalls completely (Aperture).

Affected component

Andromeda audio bridge (host audio ↔ Android audio HAL / AudioRecord). This is not an app bug — it is confirmed with two unrelated apps on two different recording APIs (Open Camera via MediaRecorder/Stagefright, Aperture via CameraX/Jetpack Recorder). Any Android app that captures audio while recording video is affected.

Device / build

• Device: FuriPhone (radon)
• SoC: MediaTek MT6877 (Dimensity 900)
• FuriOS: forky 14.0
• Kernel: 4.19.325-furiphone-radon (aarch64)
• Andromeda: 1.5.0, vendor type HALIUM_12L
• Apps used to reproduce: Open Camera 1.55 (net.sourceforge.opencamera, F-Droid) — MediaRecorder/Stagefright; Aperture (org.lineageos.aperture, LineageOS default camera) — CameraX/Jetpack Recorder. Two different recording APIs, same audio failure.

Camera/codec hardware (host, for reference)

• Camera sensors: Sony IMX586 (main) + IMX350; AF motor DW9800WAF (per dmesg).
• Camera is bridged into Android via v4l2loopback (virtual /dev/video4–video7); host hardware V4L2 nodes: video0→1b100000.dvp (sensor/DVP), video1→1602f000.vdec, video2→17020000.venc, video3→17030000.jpgenc.
• Video encoder used by the Android recorder: c2.mtk.avc.encoder (MediaTek H.264) — works correctly.

Steps to reproduce

1. Open Camera in Andromeda, ensure Record audio = ON (default).
2. Record several short videos.
3. Roughly 1 in 3 fails: on‑screen "video halted" / "video file may be corrupted", and no valid file is saved (0‑byte .pending-*VID_*.mp4 orphan in DCIM/OpenCamera, or no file at all).
4. Set Record audio = OFF and repeat → recordings save reliably every time (silent video).
5. Trying every other Audio source option (Default / Mic / Camcorder / Unprocessed / Voice recognition) does not help — all of them still corrupt with audio on.

Expected vs actual

• Expected: video+audio records to a playable MP4 every time.
• Actual: intermittent failure — the recording is aborted and lost (MediaRecorder.stop() → -1007 in Open Camera; Finalize [ERROR_NO_VALID_DATA] with the timer frozen at 0 in Aperture).

Evidence (logcat)

Open Camera — MediaRecorder, fails with -1007 ERROR_MALFORMED

18:53:42.974 I/MediaCodecSource: MediaCodecSource (audio) started
18:53:43.707 W/AudioSource:     AudioRecord reported overrun!      (repeats ~7x)
18:53:46.123 I/MediaCodecSource: puller (audio) reached EOS        (audio ends abnormally)
18:53:53.451 D/MPEG4Writer:     Audio track stopped. Status:-1007. Stop source
18:53:53.451 W/MPEG4Writer:     Condition trackErr == OK failed  Audio track stopped with an error
18:53:53.454 I/MPEG4Writer:     MOOV atom was written to the file  (video track was fine)
18:53:53.510 E/MediaRecorder:   stop failed: -1007

• -1007 = ERROR_MALFORMED.
• The MediaTek H.264 encoder c2.mtk.avc.encoder configures and encodes correctly and writes a valid MOOV atom — video is not the problem.

Aperture — CameraX, fails with ERROR_NO_VALID_DATA

Different recording stack, same audio fault — here the bridged mic delivers zero samples, so the muxer never starts:

07:28:44.210 D/Recorder:     Set up new audio source
07:28:44.233 D/AudioEncoder: mMediaFormat = {sample-rate=48000, mime=audio/mp4a-latm, channel-count=2, bitrate=256000, aac-profile=1}
07:28:44.257 D/Recorder:     Transitioning audio state: INITIALIZING --> ENABLED
07:28:44.264 D/AudioSource:  startSendingAudio
07:28:44.452 D/Recorder:     Cached video keyframe while we wait for first audio sample before starting muxer.
   ... repeats for ~8 s — the first audio sample never arrives ...
07:28:52.455 D/Recorder:     Transitioning Recorder internal state: RECORDING --> STOPPING
07:28:53.457 W/AudioEncoder: The data didn't reach the expected timestamp before timeout, stop the codec.
07:28:53.482 D/Recorder:     Sending VideoRecordEvent Finalize [error: ERROR_NO_VALID_DATA]

• The audio source and AAC encoder configure and start normally, but no audio sample is ever delivered from the bridge.
• CameraX caches video keyframes waiting for that first audio sample to start the muxer; it never comes, so all video is dropped and the muxer never starts.
• The recording finalizes with ERROR_NO_VALID_DATA, no file is written (so no orphan on disk), and the in-app recording timer stays frozen at 0 because no muxed data is ever produced.

Kernel side (dmesg) is clean

During a failed recording the kernel camera/codec path is healthy — sensor (imx586/imx350) power‑on, MediaTek DIP/ISP open, autofocus (DW9800), and clean teardown, with no encoder/ISP/IOMMU/DMA errors. This confirms the fault is entirely in the Android userspace audio capture/bridge, invisible to the kernel log.

Why it's intermittent

The bridged mic's behavior depends on scheduling/load timing and on how long the container has been running. When the bridge keeps up, the recording succeeds; when it overruns (Open Camera) or stalls and never delivers a first sample (Aperture), the audio track is lost and the whole recording with it.

Scope and lifecycle (Android-side, stateful, cleared only by container restart)

The fault is stateful inside the Android container's audio bridge and appears to accumulate with container uptime:

• Host audio is unaffected — the same Bluetooth device plays cleanly from host (Phosh/PipeWire) apps; only audio routed through the Android container breaks.
• Restarting Bluetooth does not help; restarting the app does not help. Only andromeda container restart (or a full reboot, which restarts the container) clears it.
• Beyond recording, the same bad state also shows up as glitchy Bluetooth playback from Android apps — audio crackles, plays too fast in bursts, stalls, then repeats. This is the playback-side counterpart of the capture overruns/stalls, consistent with a single underlying clock / pacing / resampler fault in the host↔Android audio bridge (PipeWire ↔ AudioFlinger). (Playback-side logcat not yet captured.)

This points to a drifting audio clock / buffer accounting in the Android audio HAL bridge that degrades over time until both capture and playback break, and is reset only when the container (and thus AudioFlinger/HAL) restarts.

Workaround

• Record video with audio disabled (e.g. Open Camera → Settings → Video → Record audio = OFF) — reliable, but produces silent video.
• When audio has already gone bad, andromeda container restart restores it until it drifts again.

Notes

• The native FuriOS camera app is unaffected, since it records audio via the host (PipeWire/Pulse) directly and never goes through the Android audio‑HAL bridge — further pointing at the Andromeda bridge as the root cause.
• Failed recordings do not always leave a 0‑byte orphan; the app sometimes deletes the MediaStore entry on the stop() error, leaving no file.

[spollard]

Update 2026-06-02 — bug persists after andromeda container restart, plus a new deadlock variant

Two more reproductions today, with the same Open Camera 1.55 (F-Droid build, freshly uninstalled and reinstalled in case it mattered — it doesn't) and the failure-mode picture got messier.

Variant A: MediaRecorder.start() deadlocks the UI on the audio HAL

First attempt today. Tapping record didn't fail the recording — it deadlocked the app. Open Camera main thread blocked for 11+ s, then ANR.

From the ANR trace (/data/anr/anr_2026-06-02-10-58-06-259):

Open Camera main thread (blocked in MediaRecorder.start()):

ioctl(binder)
android::IPCThreadState::talkWithDriver()
android::BpMediaRecorder::start() +280
android::MediaRecorder::start() +160
android_media_MediaRecorder_start (JNI)
at android.media.MediaRecorder.start(Native method)
at net.sourceforge.opencamera.preview.Preview.startVideoRecording(Preview.java:6139)
at net.sourceforge.opencamera.MainActivity.clickedTakePhoto (UI thread)

So Open Camera made the synchronous binder call MediaRecorder::start() to mediaserver and that call never returned.

Where the call wedged: audioserver has no RecordThread / AudioIn thread at all in the trace — i.e. AudioFlinger::openInput never finished creating the capture path. The fresh binder pool thread in audioserver (binder:138_5) is sitting in talkWithDriver — outbound HwBinder call to /vendor/bin/hw/android.hardware.audio.service that hasn't returned. So the wedge is in the audio HAL's IDevice::openInputStream while it's talking to host PipeWire.

Net effect: a MediaRecorder.start() call on the UI thread can hang the UI long enough to ANR.

Variant B: andromeda container restart does NOT prevent the original -1007 failure

After Variant A, ran sudo andromeda container restart (audio HAL + audioserver + mediaserver respawned, host PipeWire untouched). On the very first audio+video record attempt afterwards — audio HAL was only ~3 minutes old — back to the canonical bug in this issue:

11:38:58.700  I/MediaCodecSource: MediaCodecSource (audio) started
11:39:00.140  I/MediaCodecSource: encoder (audio) stopping        ← only 1.44 s later
11:39:00.178  I/MediaCodecSource: puller (audio) reached EOS      ← audio aborted abnormally
11:39:00.391  V/MediaWriter:      Track event ... type:100, val:-1007
11:39:00.779  D/MPEG4Writer:      Audio track stopped. Status:-1007
11:39:00.835  E/MediaRecorder:    stop failed: -1007

One subtle difference from the original report: this run had no AudioRecord reported overrun! lines at all — the audio source went silently from "started" to EOS-with-error, no overrun warnings preceded it. Final outcome the same (-1007 / ERROR_MALFORMED, file deleted).

Implication

The "audio bridge drifts over container uptime, container restart resets it" hypothesis no longer fits cleanly. The bug fired within ~3 min of a freshly-spawned audio HAL, on the first record attempt, with a then-clean host PipeWire. So either:

• the fault is structural / always present and the perceived uptime correlation was incidental, or
• the bridge enters a bad state extremely quickly after spawn (within seconds), independent of container uptime.

Either way andromeda container restart is not a reliable workaround for "make recording work right now" — it just sometimes coincidentally helps. The audio-disabled workaround is still the only one that's actually reliable.

Device / setup

• Same as the original report (FuriPhone radon, FuriOS forky 14.0, Andromeda 1.5.0, HALIUM_12L).
• Host audio HAL: /vendor/bin/hw/android.hardware.audio.service (container) ↔ /usr/bin/pipewire -c /usr/share/pipewire/pipewire-droid.conf (host).