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

[wastedbits]

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 have my system audio at 24bits/192Khz as I use that high bit rate with Apple Music and Spotify Hi-Def
StemDeck shows the waveform markers moving t but no sound.

Would be good to have it working on 24bits/192Khz.hrough the timeline but get no sound

Steps to reproduce

Here's my observations with StemDeck. I changed system audio to various settings metions below. In between each change, I restarted StemDeck

1. StemDeck plays fine with system audio at 24bits/48Khz
2. StemDeck plays with distortion when system audio is 24bits/88.2Khz and 24bits/96Khz. Distortion sounds like an old record player sound with crackle
3. No sound when system audio 24bits/176.4Khz and my setting of 24bits/192Khz

Operating system

Windows

StemDeck version

v0.17.0

How did you install it?

Windows ZIP

Logs / screenshots

No response

[pywkt]

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.

[wastedbits]

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

[thcp]

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.

[thcp]

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.