WACUP

Preview Build Discussion => Preview Build Discussion => Topic started by: joy2303 on November 05, 2026, 10:59:02 AM

Title: Bug: Raw ADTS .aac: pause freezes the position but the audio keeps playing
Post by: joy2303 on November 05, 2026, 10:59:02 AM
Build: WACUP 1.99.57.25452 (x86), reproduced on 1.99.56.25346 as well
OS: Windows 11 Pro 10.0.26200, shared mode output, out_notsodirect.dll active
Plug-ins: in_mp4.dll 2.15.5.0, in_mp3.dll 4.103

Checked on the current preview 25452 (4 Nov 2026) as well - it behaves exactly like
25346, so this is not something already fixed in the newest build.

Summary

For raw ADTS AAC files (.aac, no MP4 container) pause does not stop the audio. The player
reports Paused and the position freezes, but the decoder keeps feeding the output - I
measured 45 s of uninterrupted playback at normal level.

The same build pauses .mp3 and .m4a correctly, and the same .aac played over HTTP behaves
like the local file. I bisected old preview builds: the last one that pauses raw AAC
correctly is 1.99.16.19516, the first broken one in my sample is 1.99.27.21136.

Steps to reproduce

[list=1]

Actual behaviour


stopped, only the reporting did.
[/list]

Measured output

RMS of the active output device (WASAPI loopback, 48 kHz stereo, 1.5 s window).
0.00000 is exact silence.

Code: [Select]
content              before   +1 s    +6 s   +16 s   +30 s   +45 s
raw ADTS .aac         0.275   0.216   0.177   0.215   0.179   0.304
.mp3 control          0.124   0.000   0.000       -       -       -
.m4a control          0.128   0.000   0.000       -       -       -
same .aac over HTTP   0.361   0.265   0.229   0.226       -       -

Position at pause vs. after resume:

Code: [Select]
file     position at pause   pause length   position after resume
.aac          19.4 s             15.1 s       34.5 s  (expected 19.4 s)
.mp3          16.0 s              9.4 s       16.3 s  (correct)

Bisect over old builds

Each build installed as a separate portable copy, same file, state read via Winamp IPC,
audio via loopback.

Code: [Select]
build             date         in_mp4.dll   .aac pause
1.99.16.19516     2024-07-23   2.7.12.0     works (3/3 runs)
1.99.27.21136     2025-04-03   2.8.14.0     fails (2/2)
1.99.31.21622     2025-05-10   2.9.1.0      fails (2/3, one run fine)
1.99.34.22022     2025-06-30   2.9.3.0      fails
1.99.36.22278     2025-07-30   2.9.4.0      fails (3/3)
1.99.41.22982     2025-11-04   2.10.0.0     fails
1.99.55.25130     2026-10-05   2.15.2.0     fails
1.99.56.25346     2026-10-23   2.15.5.0     fails
1.99.57.25452     2026-11-04   2.15.5.0     fails (same 3860 ms signature)

in_mp4 swap check

Code: [Select]
host build        in_mp4.dll          .aac pause        .m4a playback
1.99.27.21136     2.7.12.0            works             works
1.99.36.22278     2.7.12.0            works             crashes
1.99.31.21622     2.7.12.0            does not load     does not load
1.99.55.25130     2.7.12.0 / 2.8.14.0 crashes on open   -

The old plug-in restores the pause in 21136, and the container path changed later
(2.7.12.0 plays .m4a in 21136 but crashes in 22278). Dropping a newer in_mp4 into an older
build does not work either - 21136 does not load 2.15.5.0 at all.

Two hints


start and the value moves. In the broken case it reports 3860 ms and the value stays
frozen. That looks like two different ADTS code paths, and only the second one ignores
the pause.

install (2 broken, 1 fine), which is consistent with those two paths being entered
non-deterministically.
[/list]

Who owns the aac extension

In 21136 the installed in_mp4 2.7.12.0 does not register the aac extension, so raw AAC is
decoded by in_mp3 - and it pauses fine. Handing aac to in_mp4 in that build
([in_mp4] extensionlist=...;AAC) makes the file refuse to play at all (IPC_ISPLAYING = 0,
output stays at 0.00000). In 25346 in_mp4 owns the extension unconditionally, and that is
exactly where the pause breaks.

What I already ruled out


it still plays the file and still refuses to pause.

Question

Is this a known regression in the real-time ADTS path? Since .m4a through the same plug-in
pauses fine, my guess is that the ADTS reader runs outside whatever the core suspends on
pause: the position stops being updated but the decoder thread keeps pushing samples. A
fix in the ADTS read loop (stop reading/feeding on pause) would also cover the streamed
case without needing the missing seek support.

Repackaging the files into MP4 is the workaround I know about, but these are synced across
devices, so renaming or recontainering them is not free.

Sample attached

DJ-Phalanx-396-aac-sample.aac - 60 s cut, 0.9 MB, raw ADTS, AAC-LC, 44.1 kHz stereo,
first bytes FF F1 50 80. It is frame aligned (no re-encoding, no container), taken from
60 s into the original file, and it reproduces the bug on both 25346 and 25452.
Title: Re: Bug: Raw ADTS .aac: pause freezes the position but the audio keeps playing
Post by: dro on November 05, 2026, 11:52:57 PM
I appreciate reporting the issue though I'm going to admit that I didn't read most of what was posted but trying to use plug-ins from older builds of wacup with newer ones often is not going to work due to internal api changes in the years between the builds (I don't do like winamp so I can change things).

I instead mainly just made use of the provided example file to resolve pausing not working (2 issues led to it) & seeking not behaving due to it not correctly syncing to the start of the adts-aac frames correctly which the aac decoder would reject especially if doing a seek during playback starting.

The next build will have what is now working for me with the provided example file & a few others I'd used previously for adding the support sans in_mp3 handling things.