Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The current code spawns a dedicated thread to handle playing sound effects. This is unnecessary as the `simpleaudio` API already is non-blocking, i.e. calling `wave_obj.play()` returns immediately while the sound plays in the background (see https://simpleaudio.readthedocs.io/en/latest/capabilities.html#asynchronous-interface). At the worst, loading the sound file, which is synchronous, could block the calling thread for a few milliseconds but that happens only once and is unlikely to be an issue. The `AudioWorker.play` method does have a `blocking` argument that is supposed to support blocking the caller until the sound has finished playing, but this is never used in the current codebase. But more conclusively, it turns out that due to an oversight, practically no code currently executes on the audio player thread. The `AudioWorker` object is assigned to a new thread, but because the `AudioPlayer.play` method calls `__worker.play` without going through a signal, the `AudioWorker.play` method actually executes on the thread that called `AudioPlayer.play`. In practice this is the UI thread, because `audio.play` is called through a signal on `SignalReceiver`, which lives on that thread. Thus, the time-sensitive engine thread is already isolated from any slowness in reading or playing audio. This commit reduces the `AudioPlayer` class to a plain Python object whose only responsibilities are to load and play the application's sound effects. It also simplifies the file loading logic by removing the direct call to the `wave` library in favor of the `from_wave_file` helper method offered by `simpleaudio`, which in practice uses the exact same call to the `wave` library. A notable benefit of removing this thread is that the application no longer crashes with an `abort` call upon exit (issue #680), caused by improper termination of the audio thread.
- Loading branch information