Bug Report: NotSoDirect plugin freezes on 24bit flac files above 48khz

[KungFuNat]

Bug Report: NotSoDirect plugin freezes on cold-start playback of FLAC files at sample rates ≥ 88.2 kHz
Build: WACUP v1.99.50.24472 (x86) — public preview, with post-release updates as of May 7, 2026
OS: Windows 11
Hardware: Intel i7-10700K, 32GB RAM
Audio device: Drop SDAC Balanced (USB DAC, AKM-based)
Output plugin: Not So Direct (default DirectSound replacement)
Windows default audio format tested: 24-bit/48 kHz, 24-bit/96 kHz, and 32-bit/192 kHz — bug behavior is identical across all settings

Summary
When using the Not So Direct output plugin, FLAC files at sample rates ≥ 88.2 kHz freeze playback when started from a "cold" state (direct click in playlist, or seeking within an already-playing file). The track timer stops advancing, no audio output, but WACUP itself remains fully responsive. The same files play correctly when reached by advancing from a previous track in continuous playback.
Not So Yasapi plugin will play the same files correctly.

Reproduction steps:

Output plugin set to "Not So Direct"
Load a playlist containing files at multiple bit depth / sample rate combinations
Click directly on a 24-bit/96 kHz or 24-bit/192 kHz FLAC file in the playlist

Expected: File plays normally.
Actual: Track timer does not move, no audio output, player remains responsive.

From frozen state, click on a 16-bit/44.1 kHz, 24-bit/44.1 kHz, or 24-bit/48 kHz file in the playlist

Result: Playback resumes normally — the freeze is per-track, not a persistent player state.

Start playback on a 24-bit/44.1 kHz or 24-bit/48 kHz file, allow playback to advance into a 24-bit/96 kHz or 24-bit/192 kHz track

Result: The high-sample-rate file plays correctly.

While the high-sample-rate file is playing successfully (from advance), attempt to seek within the track

Result: Playback freezes (timer stops, no audio). Same recovery: switching to a lower-rate file works normally.
Test matrix
Tested with both pink noise test files (from 24bit96.com) and music files from my collection. Behavior is consistent across both:

The bug appears to be in the "cold start" of Not So Direct.

I have not been able to test 88.2 kHz directly (no source files available), but the breakpoint is somewhere between 48 kHz (works) and 96 kHz (broken) for 24-bit content.

Notes:

This is reproducible with both real music files and pink noise test files
Verified the affected files play correctly in other applications on the same hardware (foobar2000, etc.), so it's not a file integrity or driver issue
The current public Known Issues page for build 24472 mentions "playback will be stuttering if the default NotSoDirect output plug-in is being used" with a post-release fix referenced — I have the post-release-updated build as of 7 May 2026, so this may be a separate or remaining issue not covered by that fix
"Allow 24-bit" is enabled in WACUP playback preferences; toggling it off does not resolve the freeze


Thank you for WACUP and for keeping the classic Winamp experience alive on modern Windows. Happy to provide any additional info that would help.

[Eris Lund]

Apply the post-release updates in the preferences in the "About | Updates" node.

[KungFuNat]

As i said in the original note..  I have them already.  still broken.

[dro]

I've quickly tried all of the example pink noise files from the site mentioned & for my main win10 dev setup all up to & including 192kHz work as expected be it as part of a first play in the process or being done after something else. The ones above that samplerate won't play due to directsound not supporting them which is expected. If notsoyasapi is working for you & you're tending to use higher bitrate audio then it might be better to use that anyway as there's little I can do until I can replicate this.

[KungFuNat]

Update,   I uninstalled the 32bit version and re-installed the 64bit version and the problem is now gone..