The Android audio plane trusted AAudio, so a TV that opened a dead stream was silent all session #214

Merged

enricobuehler merged 2 commits from worktree-android-aaudio-shield-silence into main 2026-08-14 06:22:36 +00:00

Conversation 0 Commits 2 Files Changed 5

+756 -244

enricobuehler commented 2026-08-14 06:05:41 +00:00

Owner

Copy Link

Copy Source

Field report: no audio at all on an NVIDIA Shield Android TV, stereo, same host and settings that play fine on an Apple TV. Video unaffected. Turning off the client's low-latency mode — which gates the forced HDMI mode switch and the usage=Game tagging, the only two things that toggle controls — changed nothing, so both are exonerated.

This client opens AAudio directly, where the Apple one goes through AVAudioEngine and gets route-change handling for free. That difference is why this was Android-only.

What was wrong

Opening AAudio is a negotiation with a vendor HAL, and this plane treated it as a formality: one Exclusive attempt, one Shared retry, everything after the open taken on trust. Three distinct failures all presented as "the app has no sound" behind a perfectly ordinary log line, and none was detected:

• A configuration that opens but routes nowhere. Nothing ever checked that the device pulled a single sample, so the decode thread fed Opus into a dead stream indefinitely.
• request_start failing. We gave up on the spot rather than trying anything else, so one unhappy configuration disabled audio for the whole session.
• A disconnect. By AAudio's contract the stream is then dead and the only recovery is close + open a new one; the error callback logged a warning and did nothing. On a TV that is not rare — this client itself drives an HDMI mode switch on the video plane, and the platform's own match-content-frame-rate setting drives more.

What changed

• The open walks a ladder; every rung must prove the device is actually pulling before it is accepted.
• A supervisor owns the plane for the session and reopens on disconnect, with bounded retries across a route change's settling time so a reopen landing mid-switch cannot permanently disable audio.
• Granted rate/channels/format are checked rather than assumed. Not a likely root cause (the NDK contract is honoured-or-open-fails), but the realtime callback casts AAudio's buffer to f32 and writes num_frames × channels of them, so a HAL that disagreed was an out-of-bounds write on the audio thread.

⚠ Behaviour change: TV boxes now start at Shared, not Exclusive

Exclusive is MMAP, the lowest-latency path AAudio has and the one rung whose routing cannot be verified from inside the process. The latency it buys here was never actually banked — the jitter-ring depths are unchanged from the Shared-only era (JitterTuning::AAUDIO still primes at 25 ms) — so on a mains-powered HDMI box the few ms are worth less than betting the audio plane on it. Phones, tablets and handhelds are unchanged and still try Exclusive first.

If no rung proves itself, the first one that opened and started is used anyway: a watchdog must never be able to turn working audio into no audio.

⚠ Embedder-visible

NativeBridge.nativeStartAudio takes a third argument, isTv (FEATURE_LEANBACK, the same source the video plane already used) — ro.build.characteristics is not answered by every TV device, so the native-only check would have silently missed the Shield.

Field levers, no rebuild

Alongside the existing debug.punktfunk.no_av_sync:

adb shell setprop debug.punktfunk.audio_sharing shared   # or exclusive
adb shell setprop debug.punktfunk.audio_perf none        # or lowlatency
adb shell setprop debug.punktfunk.audio_reopen 0         # old give-up-on-disconnect

A stream that stops taking samples after it started now logs at error level instead of looking exactly like an app with no sound.

Verification

cargo fmt; clippy -D warnings clean on arm64-v8a and armeabi-v7a; :app:compileDebugKotlin and :app:testDebugUnitTest BUILD SUCCESSFUL; the API-28 JNI import floor check clean across all three ABIs.

🛑 Not verified on a Shield — no such device here, and the root cause is still unconfirmed. All three defects fixed are real independently of which one is biting the reporter. The sysprops above make the next field round-trip cost one setprop instead of a build.

Field report: **no audio at all on an NVIDIA Shield Android TV**, stereo, same host and settings that play fine on an Apple TV. Video unaffected. Turning off the client's low-latency mode — which gates the forced HDMI mode switch and the `usage=Game` tagging, the only two things that toggle controls — changed nothing, so both are exonerated. This client opens AAudio directly, where the Apple one goes through AVAudioEngine and gets route-change handling for free. That difference is why this was Android-only. ## What was wrong Opening AAudio is a negotiation with a vendor HAL, and this plane treated it as a formality: one Exclusive attempt, one Shared retry, everything after the open taken on trust. **Three distinct failures all presented as "the app has no sound" behind a perfectly ordinary log line**, and none was detected: - **A configuration that opens but routes nowhere.** Nothing ever checked that the device pulled a single sample, so the decode thread fed Opus into a dead stream indefinitely. - **`request_start` failing.** We gave up on the spot rather than trying anything else, so one unhappy configuration disabled audio for the whole session. - **A disconnect.** By AAudio's contract the stream is then dead and the only recovery is close + open a new one; the error callback logged a warning and did nothing. On a TV that is not rare — this client itself drives an HDMI mode switch on the video plane, and the platform's own match-content-frame-rate setting drives more. ## What changed - The open walks a **ladder**; every rung must **prove the device is actually pulling** before it is accepted. - A **supervisor** owns the plane for the session and **reopens on disconnect**, with bounded retries across a route change's settling time so a reopen landing mid-switch cannot permanently disable audio. - Granted rate/channels/format are **checked rather than assumed**. Not a likely root cause (the NDK contract is honoured-or-open-fails), but the realtime callback casts AAudio's buffer to `f32` and writes `num_frames × channels` of them, so a HAL that disagreed was an out-of-bounds write on the audio thread. ### ⚠ Behaviour change: TV boxes now start at Shared, not Exclusive Exclusive is MMAP, the lowest-latency path AAudio has and the one rung whose routing cannot be verified from inside the process. The latency it buys here was never actually banked — the jitter-ring depths are unchanged from the Shared-only era (`JitterTuning::AAUDIO` still primes at 25 ms) — so on a mains-powered HDMI box the few ms are worth less than betting the audio plane on it. **Phones, tablets and handhelds are unchanged and still try Exclusive first.** If no rung proves itself, the first one that opened and started is used anyway: a watchdog must never be able to turn working audio into no audio. ### ⚠ Embedder-visible `NativeBridge.nativeStartAudio` takes a third argument, `isTv` (`FEATURE_LEANBACK`, the same source the video plane already used) — `ro.build.characteristics` is not answered by every TV device, so the native-only check would have silently missed the Shield. ## Field levers, no rebuild Alongside the existing `debug.punktfunk.no_av_sync`: ``` adb shell setprop debug.punktfunk.audio_sharing shared # or exclusive adb shell setprop debug.punktfunk.audio_perf none # or lowlatency adb shell setprop debug.punktfunk.audio_reopen 0 # old give-up-on-disconnect ``` A stream that stops taking samples after it started now logs at `error` level instead of looking exactly like an app with no sound. ## Verification `cargo fmt`; clippy `-D warnings` clean on `arm64-v8a` and `armeabi-v7a`; `:app:compileDebugKotlin` and `:app:testDebugUnitTest` BUILD SUCCESSFUL; the API-28 JNI import floor check clean across all three ABIs. 🛑 **Not verified on a Shield — no such device here, and the root cause is still unconfirmed.** All three defects fixed are real independently of which one is biting the reporter. The sysprops above make the next field round-trip cost one `setprop` instead of a build.

enricobuehler added 1 commit 2026-08-14 06:05:43 +00:00

fix(client/android): the audio plane trusted AAudio, so a TV that opened a dead stream was silent all session ... 38631d43df

Field report: no audio at all on an NVIDIA Shield Android TV, stereo, same
host and settings that play fine on an Apple TV. Video unaffected. Turning
off low-latency mode — which gates the forced HDMI mode switch and the
usage=Game tagging, the two things that toggle controls — changed nothing.

This client opens AAudio directly, where the Apple one goes through
AVAudioEngine and gets route-change handling for free; that is why this was
Android-only. Opening AAudio is a negotiation with a vendor HAL and this
plane treated it as a formality: one Exclusive attempt, one Shared retry,
everything after the open taken on trust. Three separate failures all came
out as "the app has no sound" behind a perfectly ordinary log line:

  - a configuration that opens but routes nowhere — nothing ever checked
    that the device pulled a single sample, so the decode thread fed Opus
    into a dead stream indefinitely;
  - request_start failing — we gave up on the spot rather than trying
    anything else, so one unhappy config disabled audio for the session;
  - a disconnect — by AAudio's contract the stream is then DEAD and the
    only recovery is close + open a new one, but the error callback logged
    a warning and did nothing. On a TV that is not rare: this client drives
    an HDMI mode switch on the video plane, and the platform's own
    match-content-frame-rate setting drives more.

The open now walks a ladder, every rung must prove the device is pulling
before it is accepted, and a supervisor owns the plane for the session and
reopens it when the device goes away — with bounded retries across the
settling time of a route change, so a reopen landing mid-switch cannot
permanently disable audio. Granted rate/channels/format are checked rather
than assumed: the realtime callback casts AAudio's buffer to f32 and writes
num_frames * channels of them, so a HAL that disagreed was an out-of-bounds
write on the audio thread, not just a mistuning.

TV boxes now start at Shared. Exclusive is MMAP, the lowest-latency path
AAudio has and the one rung whose routing cannot be verified from inside
the process; the latency it buys was never banked, since the ring depths
are unchanged from the Shared-only era (AAUDIO still primes at 25 ms). On a
mains-powered HDMI box that trade is not worth betting the audio plane on.
Phones keep Exclusive first. If no rung proves itself the first one that
opened and started is used anyway — a watchdog must never be able to turn
working audio into no audio.

nativeStartAudio takes isTv (FEATURE_LEANBACK, the source the video plane
already used) because ro.build.characteristics is not answered by every TV.

debug.punktfunk.audio_sharing / audio_perf / audio_reopen bisect all of it
with setprop, for the device that reports silence and cannot be handed a
custom build. A stream that stops taking samples after it started now says
so at error level instead of looking exactly like an app with no sound.

Not verified on a Shield — no such device here.

enricobuehler added 1 commit 2026-08-14 06:07:32 +00:00

Merge remote-tracking branch 'origin/main' into worktree-android-aaudio-shield-silence ... e2239fd964

# Conflicts:
#	CHANGELOG.md

enricobuehler merged commit b6cc76c472 into main 2026-08-14 06:22:36 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#214