XMusic: A 10MB music player proving lightweight C++ is back

The modern desktop app ecosystem often prioritizes convenience over performance, leaving lightweight alternatives in the dust. High RAM usage, glacial startup times, and sprawling dependencies have become the norm—especially for apps built with Electron or similar frameworks. Enter XMusic, a cross-platform music player that defies this trend by delivering sub-second startup, a 10MB memory footprint, and a single 15-25MB executable that works everywhere.

XMusic isn’t just another media player; it’s a manifesto for what native development can achieve in 2024. By eschewing heavyweight runtimes and embracing modern C++ with a carefully curated stack, the project achieves what many assumed impossible: a music player that feels instant, even on decade-old hardware.

Why most music players feel heavy—and how XMusic fixes it

Traditional music players built on frameworks like Electron or Qt often suffer from three critical flaws:

• Memory bloat: Electron apps routinely consume 200-500MB of RAM, while even Qt-based players hover around 80-150MB. XMusic cuts that to a mere 10MB—roughly the size of a high-resolution image.
• Painfully slow starts: Launching an Electron app can take 5-10 seconds as it spins up a Chromium instance. XMusic boots in 710ms total, with its UI appearing in just 85ms after SDL audio initialization.
• Distribution nightmares: Shipping a Qt app requires bundling runtime libraries, plugins, and translation files. XMusic ships as a single executable—no dependencies, no installers, no fuss.

These aren’t minor improvements; they’re a fundamental shift in how desktop apps should behave. XMusic proves that lightweight software isn’t a relic of the past—it’s a viable, even superior, alternative to modern bloated development practices.

The architecture behind the speed: C++, SOUI4, and SDL3

XMusic’s performance stems from a deliberately minimalist architecture built around purpose-built tools rather than general-purpose frameworks. At its core, the app relies on three pillars: SOUI4 for the UI, SDL3 + SDL_mixer3 for audio, and a suite of specialized libraries for metadata and encoding.

SOUI4: A UI framework that doesn’t weigh you down

SOUI4 is a declarative, XML-based UI framework inspired by Android’s layout system but designed for desktop applications. Unlike traditional frameworks that rely on Win32 or GDI, SOUI4 uses a direct rendering pipeline, avoiding bottlenecks and enabling crisp rendering even at 4K resolutions.

Key advantages include:

• Clean separation: UI defined in XML, logic in C++, making maintenance straightforward.
• High DPI support: Automatically adapts to screen resolution without manual tweaking.
• Built-in animations: Smooth transitions require no additional code.
• Locale-aware: Detects system language and adapts text automatically.

A minimal XMusic layout might look like this:

<window width="800" height="600" title="XMusic">
  <window layout="vbox">
    <listView name="playlist" />
    <window layout="hbox">
      <button name="play" text="Play" />
      <button name="pause" text="Pause" />
      <slider name="volume" min="0" max="100" />
    </window>
  </window>
</window>

SDL3 + SDL_mixer3: Audio without compromise

Instead of building a custom audio engine, XMusic leverages SDL3 and SDL_mixer3, industry-standard libraries that support a vast array of formats—MP3, FLAC, OGG, WAV, MOD, OPUS, M4A/AAC, and even niche formats like WMA. The audio backend uses a ring buffer to ensure low-latency playback, a critical feature for music apps where timing matters.

Metadata and encoding: TagLib and LAME in action

For metadata handling, XMusic relies on TagLib, which provides full ID3v2 editing capabilities including reading/writing artist names, album titles, genres, and embedded album art. For encoding, it uses LAME, the gold standard for MP3 conversion, supporting bitrates from 128 to 320 kbps with multi-threaded batch processing.

Lyrics integration via LRCLIB

XMusic also fetches synchronized lyrics using the LRCLIB API, automatically retrieving LRC-format lyrics that highlight words in real time—a feature that elevates the listening experience without adding significant overhead.

Cross-platform done right: One codebase, three operating systems

XMusic runs natively on Windows, Linux, and macOS without any platform-specific changes, thanks to swinx, SOUI4’s compatibility layer that mimics the Windows API on non-Windows systems. This approach avoids the #ifdef spaghetti that plagues many cross-platform projects.

Windows (XP to 11)

• Native Win32 integration ensures perfect system tray support and theme adaptation.
• Works seamlessly on both legacy and modern systems.

Linux (Ubuntu, Fedora, Arch, etc.)

• Compatible with both X11 and Wayland.
• Supports PulseAudio and PipeWire audio backends.
• Distributed as a single static binary with no external .so dependencies.

macOS (10.15 and later)

• Uses Metal-accelerated rendering for smooth graphics.
• Supports Retina displays with crisp UI scaling.
• Integrates with macOS’s native Cocoa framework via swinx.

This level of consistency across platforms is rare in open-source projects, where Linux often gets short shrift or macOS support is an afterthought. XMusic treats all three ecosystems as first-class citizens.

Deployment simplicity: The magic of static linking

The most compelling aspect of XMusic isn’t just its performance—it’s how it’s delivered. Traditional cross-platform apps require distributing dozens of files:

• Executable
• Runtime libraries (qt5core.dll, libssl.so.1.1, etc.)
• Plugin directories
• Translation files
• Platform-specific binaries

XMusic, by contrast, ships as a single file. Every dependency—SDL3, TagLib, LAME, SOUI4—is statically linked into the binary. UI assets, fonts, and even translation strings are embedded directly into the executable via .rc files. At runtime, the app extracts these resources from its own binary sections, eliminating the risk of missing or tampered files.

This approach not only simplifies distribution but also enhances security. There’s no sprawling directory structure to audit, no external libraries to patch—just a single, self-contained file.

Why not Qt or Electron?

The question naturally arises: If Qt and Electron are so widely used, why does XMusic reject them? The answer lies in trade-offs.

Electron excels in rapid prototyping and ecosystem richness, but its reliance on Chromium makes it inherently heavy. A simple music player shouldn’t need a browser engine to function.

Qt, while more efficient than Electron, still carries significant baggage. Its modular design means even a minimal Qt app requires bundling dozens of libraries. Static linking with Qt is possible but complex, and the resulting binary size often exceeds 50MB—still far from XMusic’s 15-25MB ideal.

XMusic proves that for specific use cases—like a music player—specialized, lightweight tools outperform general-purpose frameworks. It’s not about rejecting Qt or Electron outright, but recognizing when they’re overkill.

The future of lightweight desktop apps

XMusic arrives at a pivotal moment. As users grow weary of bloated, slow, and resource-hungry applications, a quiet renaissance of lightweight native software is underway. Projects like XMusic, VimR (a native macOS Vim), and FeatherPad (a Qt-based text editor) demonstrate that performance and simplicity aren’t mutually exclusive.

The implications extend beyond music players. If a C++ app can deliver sub-second performance while consuming a fraction of the RAM of an Electron counterpart, why can’t other categories follow suit? Text editors, terminal emulators, even lightweight IDEs—all could benefit from this philosophy.

For developers, XMusic serves as both an inspiration and a blueprint. It shows that with the right tools and careful architecture, lightweight software isn’t just possible—it’s superior. The era of Electron fatigue may be giving way to a new age of efficient, responsive, and delightful desktop applications.

As the open-source community continues to explore these possibilities, XMusic stands as a testament to what happens when developers prioritize performance over convenience. In a world of ever-increasing bloat, it’s a breath of fresh air.