Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MediaPlayer race condition in audio annunciator

Open
  • Is something wrong?
#3,966 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
audio-video-rtc, desktop

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
Java
Stars
130
Forks
132
Avg merge
2d 11h
Merged PRs (30d)
19

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ControlSystemStudio/phoebus

All issues in ControlSystemStudio/phoebus

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.