I run a Morse Code translator website that allows users to convert text into Morse code, decode Morse messages, and listen to Morse code audio generated directly in the browser. The website is heavily dependent on JavaScript and browser audio APIs because users can hear the timing differences between dots, dashes, character gaps, and word gaps while learning Morse code. Recently, I began receiving reports from users running GNOME-based Linux distributions that the audio playback experience is inconsistent compared to what users experience on other operating systems. Since the audio component is a core educational feature of the website, I am trying to better understand whether the issue is related to browser integration, GNOME audio infrastructure, or something within my implementation.
The primary problem is that Morse code audio sometimes starts with a noticeable delay when users click the playback button. In some situations, the first few Morse characters are skipped entirely, while the remainder of the sequence plays normally. The issue appears more frequently when the website has been idle for several minutes before playback begins. Because Morse code relies heavily on timing accuracy, even a small delay at the beginning of playback can make the output confusing for learners. I have not been able to consistently reproduce the behavior on every Linux system, which makes troubleshooting particularly difficult.
While investigating the issue, I noticed that some users report different behavior depending on whether they are using GNOME Web, Firefox, or Chromium-based browsers. The website generates tones using browser audio APIs rather than pre-recorded audio files, and initialization timing appears to vary across environments. In certain cases, audio contexts seem to remain suspended longer than expected, requiring additional user interaction before sound begins. I am unsure whether this is caused by browser-specific policies, desktop environment integration, audio backend differences, or a combination of these factors.
Another challenge involves power-saving and resource-management behavior. Several users reported that Morse code playback becomes less reliable after a laptop resumes from suspend or after the system has been idle for an extended period. In some cases, audio timing becomes inconsistent, resulting in gaps between Morse symbols that are longer than intended. Because the application depends on precise timing to teach Morse code accurately, these variations create a poor user experience. I am interested in understanding whether GNOME’s power management or multimedia handling could influence browser-based audio applications in situations like this.
I have already attempted a number of optimizations, including pre-initializing audio contexts after user interaction, reducing latency settings where available, minimizing background processing, and testing across multiple browser versions. These improvements appear to help in some cases but do not completely eliminate the reports of delayed or inconsistent playback. Since the issue seems to affect only a subset of Linux users and appears to be influenced by system state, browser choice, and desktop environment behavior, identifying the root cause has been challenging.
I would greatly appreciate feedback from GNOME users and developers who have experience with browser-based audio applications on Linux desktops. For an educational Morse Code website that relies on accurate real-time audio generation, are there known considerations related to GNOME, PipeWire, browser audio APIs, power management, or multimedia integration that could contribute to these symptoms? Any suggestions for debugging, testing, or improving reliability across GNOME-based systems would be extremely valuable. Sorry for long post!