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

Đang mở
  • Có gì không ổn?
#3,522 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
38/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
android, java
Lĩnh vực
audio-video-rtc, backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Java
Star
3.1k
Fork
1k
Merge trung bình
7 ngày 12 giờ
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của androidx/media

Tất cả issue của androidx/media

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.