1
General Discussion / Re: Bug Report: NotSoDirect plugin freezes on 24bit flac files above 48khz
« on: Today at 01:51:31 AM »
Update, I uninstalled the 32bit version and re-installed the 64bit version and the problem is now gone..
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
General Discussion / Re: Bug Report: NotSoDirect plugin freezes on 24bit flac files above 48khz
« on: Yesterday at 01:56:05 PM »
As i said in the original note.. I have them already. still broken.
3
General Discussion / Bug Report: NotSoDirect plugin freezes on 24bit flac files above 48khz
« on: Yesterday at 02:34:23 AM »
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.
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.
Pages: [1]