[Bug]: No sound from StemDeck when system audio is set at 24bits/192K. #575

Activity

1. wastedbits

   added

   bugSomething isn't workingSomething isn't working

   on Sep 5, 2026
2. pywkt commented on Sep 5, 2026

   

   pywkt

   on Sep 5, 2026

   Contributor

   More actions

   I think this is the same bug as #576, seen from a faster machine at a higher output rate.

   Every stem plays through the SoundTouch pitch worklet even at zero transpose, and on main the worklet runs twelve pitch chains on silence for the whole track (details and the fix in #576). The chains' windows are set in milliseconds, so their cost per second of audio climbs steeply with the AudioContext's sample rate, which follows the system output device.

   Measured with the real soundtouch-processor.js, offline render of 20 s, seven stems, no transpose, headless Chromium:

   Output rate	Only the unpitched bus wired (the fix)	All 13 wired (current main)
   44.1 kHz	0.5% of real time	13.0%
   48 kHz	0.4%	14.8%
   96 kHz	0.9%	53.0%
   192 kHz	1.6%	202%

   That lines up with your three observations: fine at 48 kHz, crackle at 88.2/96 kHz where the audio thread is spending half its budget on nothing, and silence at 176.4/192 kHz where it would need twice real time and cannot produce output at all.

   If you want to confirm on your machine before the fix lands: at 192 kHz, transpose is not the issue, so the branch at https://github.com/pywkt/stemdeck/tree/fix/idle-pitch-chains should play. It is a JavaScript-only change to static/js/audioEngine.js and static/js/chunkedAudioEngine.js.
3. wastedbits commented on Sep 6, 2026

   

   wastedbits

   on Sep 6, 2026

   Author

   More actions

   I confirmed on my machine with the JS changes. It works fine. Thanks
4. thcp

   self-assigned this

   on Sep 6, 2026
5. thcp commented on Sep 6, 2026

   

   thcp

   on Sep 6, 2026

   Last edited by thcp

   Collaborator

   More actions

   Hi @wastedbits
   Good to hear the first set of changes worked on your machine. That confirmation was genuinely useful, because I have no hardware above 48 kHz here and could not test the thing you were reporting.

   Your three observations are what cracked this open. Fine at 48, distorted at 88.2 and 96, silent at 176.4 and 192 is not three bugs, it is one cost that climbs with the sample rate. Without that ladder I would have read #576 as a slow laptop and stopped there.

   There is now a second fix on the branch, and it is aimed squarely at your setup. StemDeck was running its whole audio engine at whatever rate Windows had the output device set to. Every stem it produces is 44.1 kHz, so at 192 kHz it was upsampling and then doing four times the work on samples carrying no extra detail, and holding around 2.6 GB of audio in memory for a five minute track instead of 606 MB. The graph is now capped at 48 kHz. Your DAC still receives 192 kHz, Windows does that conversion, exactly as it already does for anything else playing 44.1 kHz material.

   Both fixes are in #577.

   Trying it

   Download the branch as a zip:

   https://github.com/stemdeckapp/stemdeck/archive/refs/heads/fix/idle-pitch-chains.zip

   Close StemDeck. From the zip, copy these five files into your StemDeck folder, keeping the same layout. Four go in backend\static\js and one in backend\static\mobile:

   backend\static\js\audioContext.js        (new file, did not exist before)
   backend\static\js\audioEngine.js
   backend\static\js\chunkedAudioEngine.js
   backend\static\js\player.js
   backend\static\mobile\app.js
   

   Then start StemDeck again. Worth keeping a copy of the originals so you can put them back.

   What I would like to know, at 24-bit/192 kHz

   1. Does a track play at all, and does it sound clean.
   2. Set a stem's key up or down a couple of semitones and play it. This is the expensive case, and the one I could not measure without your hardware.
   3. If you have the patience, 176.4, 96 and 88.2 as well, since those were distorted before.
   4. Most important: does anything sound worse than it did with just the first set of changes you tried? Slightly duller, or thinner, or any artefact on sustained notes.

   Restart StemDeck between each rate change, since the audio engine reads the device rate when it starts.

   Question 4 is the one that decides whether this ships as it stands. Capping the graph at 48 kHz means Windows now resamples 48 up to 192 for your DAC instead of StemDeck rendering at 192 directly. On paper that is the same conversion Windows already does for every 44.1 kHz file you play, and it should be transparent. But I cannot hear it from here, and "should be" is not the same as "is". If it costs you anything audible, I would rather find that out from you now than ship it and have you discover it later. There is a straightforward way to give you back the old behaviour as an option if it turns out to matter.

   Take your time, and thank you for testing this.
6. thcp

   closed this as completedin ddf7e5con Sep 6, 2026
7. thcp commented on Sep 6, 2026

   

   thcp

   on Sep 6, 2026

   Collaborator

   More actions

   This is on main now, in #577. Thanks for testing the branch and coming back
   with a clear answer, that is what let it move.

   Your three observations are what made this solvable. Fine at 48, distorted at
   88.2 and 96, silent at 176.4 and 192 is not three faults, it is one cost that
   climbs with the sample rate. Without that ladder I would have read the other
   report as a slow laptop and stopped there.

   What actually fixed it: the pitch worklet was running twelve chains on silence
   for the whole track even with nothing transposed. Their cost per second of audio
   scales with the output rate, so at 48 kHz it was survivable, at 96 it ate half
   the audio thread's budget, and at 192 it needed more than real time, which is why
   you got no sound rather than bad sound.

   One thing I want to be straight with you about

   There is a second change in there that you have not tried.

   StemDeck was running its audio graph at whatever rate Windows had the output
   device set to. Every stem it produces is 44.1 kHz, so at 192 kHz it was
   upsampling and then doing four times the work on samples carrying no extra
   detail, and holding about 2.6 GB of audio in memory for a five minute track
   instead of 606 MB. The graph is now capped at 48 kHz and Windows does the
   conversion up to your DAC, the same conversion it already does for any 44.1 kHz
   file you play.

   I asked you whether that would sound worse and then merged before you had a
   chance to answer. That was my call and you should know it was made.

   I am fairly confident it is transparent, and there is a good reason to think so:
   the fix for the silence does not depend on it. I reproduced your 192 kHz silence
   here by forcing the graph rate, and the first change alone made it play cleanly
   at a genuine 192 kHz, with no cap involved. So the cap is an optimisation sitting
   on top of the fix, not part of it.

   Which means if it costs you anything audible, it comes straight back out and your
   sound still works. That is the whole reason I was willing to merge it ahead of
   your answer.

   So when the next release lands, please do give it a proper listen at 24-bit/192
   kHz. If anything sounds thinner, duller, or off compared to how it sounded with
   just the JS files you tried, tell me and I will drop that commit. You are the
   only person testing this on hardware that actually runs at 192.

   Nothing to download yet, this is on main rather than in a release. I will
   mention it here when there is a build to try.

   Thanks again for the detail in that first report. It did most of the work.
8. pull

   added a commit that references this issue on Sep 7, 2026

   Stop the pitch worklet burning the audio thread at zero transpose and…

   ...

   ddf7e5c