Skip to content

fix: error when playing notification sounds in quick succession#36

Open
Stone-Red-Code wants to merge 2 commits intodevfrom
dev_fix_notification_sound
Open

fix: error when playing notification sounds in quick succession#36
Stone-Red-Code wants to merge 2 commits intodevfrom
dev_fix_notification_sound

Conversation

@Stone-Red-Code
Copy link
Collaborator

@Stone-Red-Code Stone-Red-Code commented Feb 25, 2026

Summary

Fixes errors when playing notification sounds in quick succession.

This fix may cause notification sounds to be delayed if the previous sound is still playing, but it prevents errors and ensures all notifications are heard

Fixes #20

@Stone-Red-Code Stone-Red-Code self-assigned this Feb 25, 2026
}
catch (Exception ex)
{
_lock.Release();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The release should be moved to finally block
Currently we release it only on the exception, meaning the successful path will keep it locked (releasing on event is fragile)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with that is that await _player.Play(_resolvedSoundPath!); doesn't block until the audio has finished playing.

That's why I'm waiting for PlaybackFinished.

I know this isn't the best solution, but the library doesn't give us many options.

public NotificationSoundService(NotificationConfig config)
{
_config = config;
_player.PlaybackFinished += (s, e) => _lock.Release();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got some trust issues with that, lets just release the lock in finally block

Copy link
Owner

@HueByte HueByte Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall issues imo with event based release:

  • If Completed never fires -> deadlock
  • If Completed fires twice -> SemaphoreFullException
  • If the event handler throws before Release() -> deadlock
  • If someone refactors and changes event ordering -> subtle bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants