diff options
| author | Craig Jennings <c@cjennings.net> | 2026-07-09 13:48:06 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-07-09 13:48:06 -0500 |
| commit | e022368a8d640aca9e5700249d70bacf948cfa7a (patch) | |
| tree | 3775db77089394f8b01e38b299a834ebf133d181 /.github/workflows | |
| parent | cccc205f0163395366f54f83011a161bfce3129c (diff) | |
| download | chime-e022368a8d640aca9e5700249d70bacf948cfa7a.tar.gz chime-e022368a8d640aca9e5700249d70bacf948cfa7a.zip | |
fix: play the chime through an external player when one is available
Emacs' play-sound-file opens an ALSA device directly, so it fails with "No usable sound device driver found" wherever ALSA's default PCM doesn't resolve. That's every PipeWire system where nothing points pcm.!default at the sound server. It also blocks Emacs until the clip finishes, and on macOS it isn't compiled in at all.
chime now hands the file to the first of pw-play, paplay, afplay or aplay found on exec-path, spawned asynchronously. I put aplay last because it speaks raw ALSA and shares play-sound-file's failure mode, so falling back to it from a broken default PCM would buy nothing. With no external player installed, play-sound-file still runs, now taking chime-sound-device as its DEVICE argument.
Two new defcustoms: chime-sound-player (auto, emacs, or a command name) and chime-sound-device. Both default to today's behavior for anyone whose sound already works.
A player that spawns and then exits non-zero is reported through a process sentinel rather than failing silently. The sentinel doesn't fall back to play-sound-file, which would reintroduce the blocking ALSA call this change avoids.
I pinned the notify tests to emacs so they mock one function and never spawn a real player.
Diffstat (limited to '.github/workflows')
0 files changed, 0 insertions, 0 deletions
