Repository navigation
[Bug]: Waveforms and playback do not work on Linux version (hardware dependent?) #343
Description
Before reporting
- I'm on the latest release and the issue still happens.
- I searched existing issues and didn't find a duplicate.
What happened?
I've been using StemDeck on my laptop, but when I switched to my desktop (also on CachyOS) all of the sudden the waveforms and playback do not work. I downloaded the newest version on my laptop to see if this was the issue and it appears not to be since it still works fine on my laptop. My best guess is that it's a hardware problem since my laptop is an almost fresh install and my desktop has been around awhile, so I don't imagine it's a missing package, they are both up to date. My laptop is an i7-5600U with integrated graphics and my desktop is a Ryzen 7 3700x with an Intel Arc a380 GPU. This is not a big deal for me at all since the previous I only want StemDeck to get the stems out of it into REAPER, but I figured I would mention that this is something I'm experiencing, and given my laptop is intel based and the desktop is AMD, I am suspecting hardware variance is the problem. Though do what you will with that since this would probably be a very difficult issue to reproduce. Like I said, it doesn't bother me, I just wanted it to be known that I experienced this.
Steps to reproduce
1: Install latest build of StemDeck
2: Open any previous project or split a new song.
3: Wait for waveforms to load
Operating system
Linux (Arch)
StemDeck version
v0.8.0-alpha17
How did you install it?
Linux tar.gz
Logs / screenshots
Waveforms loaded but clearly broken and playback will not start.
Activity
thcp commentedon Aug 12, 2026
Hey @MetalMan1245 thanks for taking the time to write this up, and for the screenshot, it turned out to be the most useful part.
I don't think this is your GPU. The screenshot rules it out: the whole interface renders correctly, and a broken WebView renderer doesn't paint a UI that cleanly. The giveaway is elsewhere. Your header reads DURATION 03:09, but the transport underneath reads 0:00 / 0:00. The analysis came back from the backend fine; the player thinks the audio is zero-length. Empty waveforms and a dead play button are both downstream of that one fact.
Here is where that can come from. Playback parses the WAV headers itself, and it only looks at the first kilobyte of each stem to find where the audio starts. If it doesn't find it there, the track is marked unplayable , silently, which is why you got no error. That's now #358, and the fact that it told you nothing at all is #359.
Whether that is what bit you depends on how the stems on that machine were written, and one command will tell us. On the desktop that fails:
xxd -l 64 "$(ls ~/Documents/StemDeck/jobs/*/stems/vocals.wav | head -1)"(If your stems live somewhere else, point it at any
vocals.wavStemDeck produced on that machine.)Paste the output here. If
dataappears near the start, my theory is wrong and I'll look again -- the interesting part will be whether the same command on your laptop, where it works, gives a different layout.It would also help to know: does a track that works on the laptop also fail if you copy it across to the desktop? That separates "the files are different" from "the machine is different".
Either way both bugs are worth fixing on their own, so this was a useful report even if it turns out to be something else.
fix(player): read the whole WAV header, and say so when a track canno…
Report a failure from the notification centre (#372)
thcp commentedon Aug 21, 2026
hey @MetalMan1245 any news on this ? i will be closing this one for inactivity in 48h :)