MediaPlayer race condition in audio annunciator
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- java
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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
- 主要语言
- Java
- 星标
- 130
- 派生
- 132
- 平均合并
- 3 天 1 小时
- 30 天内合并 PR
- 24
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ControlSystemStudio/phoebus 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
ControlSystemStudio/phoebus#3979 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 80/100
ControlSystemStudio/phoebus#3962 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
ControlSystemStudio/phoebus#3865 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 52/100
ControlSystemStudio/phoebus#3980 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
ControlSystemStudio/phoebus#3978 ·
维护者通常 2 天内回复
查看 ControlSystemStudio/phoebus 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 70/100
NationalSecurityAgency/ghidra#9997 · 2 条评论 ·
维护者通常 2 天内回复
-
[Bug] DefaultSerializationExceptionWrapper does not implement Cleanable, so cleanup() is never invoked by codecs可能已有人在做 @binbin0325 今天认领。 未关闭component/need-triage type/need-triage
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
2026 Error Report
难度 2/5 1-3 小时 新手友好度 68/100
triplea-game/triplea#15096 ·
维护者通常 1 天内回复
-
[Bug][API] Switching workflow versions leaves schedules online可能已有人在做 @zhuangchong 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
apache/dolphinscheduler#18731 ·
维护者通常 1 天内回复