Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

MediaPlayer race condition in audio annunciator

Offen
  • Stimmt etwas nicht?
#3,966 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
audio-video-rtc, desktop

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Java
Sterne
130
Forks
132
Ø Merge
2 T. 11 Std.
Gemergte PRs (30 T.)
23

Entwicklungsumgebung

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus ControlSystemStudio/phoebus

Alle Issues in ControlSystemStudio/phoebus

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.