Audible gap (~1.5–2 s) after every seek with passthrough (direct) audio because DefaultAudioSink releases the AudioTrack on flush

Aperta
  • Qualcosa non va?
#3,522 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, java
Ambito
audio-video-rtc, backend

Direzione di ricerca

Start with DefaultAudioSink.flush() and the AudioTrack initialization and release paths named in the report; compare the flush behavior for direct audio tracks with the seek flow. The report suggests preserving the track across flushes, but device and encoding behavior may constrain that choice. Done means seeks during passthrough no longer cause the reported output teardown and audible re-lock gap, with relevant sink behavior covered by tests.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug needs triage
Version

Media3 1.11.1

More version details

Behaviour is in DefaultAudioSink.flush() of the current release (AudioTrack is released on flush and recreated on the next write). Observed on a device through Emby for Android TV 2.5.05g, which bundles the ExoPlayer 2.x-era DefaultAudioSink (exact bundled version unknown). Device: Ugoos SK4 Pro, Amlogic S905X5M, Android 14 AOSP (userdebug). Audio path: HDMI -> Denon AVC-X3800H. Format: Dolby TrueHD 7.1 passthrough (AUDIO_FORMAT_DOLBY_TRUEHD), HAL stream flags DIRECT|COMPRESS_OFFLOAD, tunneling off. Same with E-AC3 JOC.

Devices that reproduce the issue
  • Ugoos SK4 Pro (Amlogic S905X5M) running Android 14, HDMI to Denon AVC-X3800H
Devices that do not reproduce the issue

None known. Any sink that must re-lock onto a bitstream (AVR or soundbar) will show it.

Reproducible in the demo app?

Not tested

Reproduction steps
  1. Play an MKV with TrueHD (or E-AC3) audio in passthrough to an AVR over HDMI.
  2. Press skip forward (seekTo) once.
  3. Audio is silent for roughly 1.5–2 s; the AVR display shows it re-locking to the bitstream. Video resumes ~1 s later than it could.
Expected result

A seek inside the same stream should keep the existing direct AudioTrack (flush it, keep it open), so the HDMI bitstream is not torn down and the AVR does not need to re-sync. Silence should be limited to the decoder/renderer restart, i.e. a few hundred ms at most.

Actual result

On every seekTo the sink closes the HDMI output stream and opens a new one. Android audio HAL log (audio_hw_hal_primary, Amlogic) for one seek:

22:57:02.663 out_flush_new            io 181 out:0xe6484210
22:57:02.664 out_standby_new          io 181 streamType:RAW_DIRECT
22:57:02.665 adev_close_output_stream io 181 dev:OUT_HDMI flags:0x11 streamType:RAW_DIRECT
22:57:03.367 adev_open_output_stream  io 189 format:DOLBY_TRUEHD(0xe000000) flags:0x11 (DIRECT,COMPRESS_OFFLOAD)
22:57:03.926 out_flush_new            io 189
22:57:03.989 aml_alsa_output_open_new (ALSA device reopened, ~1.3 s after close)

So the direct output is closed, a new output is created 0.7 s later, and ALSA is reopened 1.3 s after the close. Only then does the AVR get a bitstream to lock onto (another ~0.5-1 s on a Denon AVC-X3800H). The same cycle repeats on every seek. This matches DefaultAudioSink.flush() releasing the AudioTrack (releaseAudioTrackAsync) and initializeAudioTrack() running again on the next handleBuffer.

Issue #3407 ("Permanent BUFFERING after a seek on a direct (passthrough) AudioTrack") was caused by the same release-and-recreate cycle and was closed with a fix for the position-wrap symptom only (commit 4c95cd9). Its reporter also pointed at "not releasing the AudioOutput on flush (b/143500232)" as the longer-term fix. This issue is about the user-visible consequence of that design for passthrough: an audible gap on every seek.

Suggested change: for direct/passthrough tracks (and ideally all tracks where the format does not change), keep the AudioTrack across flush(): pause, AudioTrack.flush(), reset the position tracker and continue writing, instead of releasing and recreating. If a full release is needed on some devices or encodings, make it configurable (e.g. DefaultAudioSink.Builder.setReleaseAudioTrackOnFlush(boolean)) so TV apps doing passthrough can opt out.

Note: I am a normal user, not an Android developer. So AI was used for everything in this post, also to debug why it happened. The HAL log above and the timings are measured on my device; the analysis of DefaultAudioSink behaviour and the suggested change were created with an AI.

Media

Any MKV with a Dolby TrueHD or E-AC3 track played in passthrough to an AVR. The issue does not depend on the specific file; I can email a sample on request.

Bug Report
  • You will email the zip file produced by adb bugreport to [email protected] after filing this issue.
Lingua principale
Java
Stelle
3.1k
Fork
1k
Merge medio
7g 12h
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di androidx/media

Tutte le issue di androidx/media

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.