Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

MediaPlayer race condition in audio annunciator

Đang mở
  • Có gì không ổn?
#3,966 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 2 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
48/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ệ
java
Lĩnh vực
audio-video-rtc, desktop

Hướng nghiên cứu

Start by locating speakAlone and the MediaPlayer::stop and MediaPlayer::play calls mentioned in the issue, then trace how player status changes are handled. Reproduce with a 1-second nag period and a 100ms beep, checking whether play runs before the player reaches STOPPED. Done means repeated short beeps are no longer missed and the playback transition is handled reliably.

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

Mô tả

I am trying to get the audio annunciator to work with a very short nag period (1 second) and a short clip (100ms) of a beep sound. I have encountered an issue where beeps are frequently missed. I traced this to what appears to be a race condition between MediaPlayer::stop and MediaPlayer::play. In speakAlone, stop is called on every alarm media player, and then play is called on the correct media player. This is all well and good except it would appear that stop does not actually appear to block until the media player status has transitioned to stopped even if the audio clip has finished playing.

Adding a log statement just before play is called e.g.

try {
    logger.log(Level.SEVERE, "grioejgoijq " + alarm.getStatus());
    alarm.play();
} catch (Exception e) {
    logger.log(Level.SEVERE, "Failed to play alarm sound", e);
}

does two things: firstly it more or less randomly logs 'PLAYING' or 'STOPPED' indicating the race condition, and secondly it stops beeps from being missed (yes - adding a log statement fixes the bug). I think this is just because there is more time for the player to stop and so by the time it gets to play it has actually been stopped.

I have looked into fixing this but really not sure how to do it in a simple way - ideally I think we'd just block until the status returns to stopped which can be done with completable futures but it feels like there should be an easier solution - so please let me know any thoughts

Ngôn ngữ chính
Java
Star
130
Fork
132
Merge trung bình
3 ngày 1 giờ
Pull request đã merge (30 ngày)
24

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

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

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 ControlSystemStudio/phoebus

Tất cả issue của ControlSystemStudio/phoebus

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.