Audio problem (Kaitou Apricot)

[glitchengineer]

Game or games this happens in

Kaitou Apricot (ULJM05276)

What area of the game / PPSSPP

A single audio track (Track 14 - Smile Brightly) plays around 8 seconds before cutting off, while all the other tracks play normally. This happens in both cutscenes and the music player in the game.

What should happen

I've tested the game on an actual psp and it plays normally on it.

Logs

The Log Console had these pop up when the track stopped:

49:30:300 ATRAC3 play E[ME]: HLE\sceAtrac.cpp:600 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7 49:30:300 ATRAC3 play E[ME]: HLE\sceAtrac.cpp:1527 UNIMPL sceAtracGetInternalErrorInfo(0, 09efea20)

Platform

Windows

Mobile phone model or graphics card

NVIDIA GeForce GTX 1070

PPSSPP version affected

v1.12.3

Last working version

No response

Graphics backend (3D API)

OpenGL / GLES

Checklist

• [X] Test in the latest git build in case it's already fixed.
• [X] Search for other reports of the same issue.
• [X] Try resetting settings or older versions and include if the issue is related.
• [X] Try without any cheats and without loading any save states.
• [X] Include logs or screenshots of issue.

[Panderner]

@glitchengineer can you record the audio?

[glitchengineer]

@Panderner

Sure. The sound in the beginning is just a sound effect from choosing the song.

ULJM05276_2021-12-13_22-20-14.zip

[sum2012]

ppsspp-v1.13.1-347-g6cc8ca517 log: https://gist.githubusercontent.com/sum2012/5f8261e0ccba21cdfbf346e75846d565/raw/7246a1cf0748a5dfb0b206d732b6bb96f17d3678/gistfile1.txt

A small note:jpcsp emulator (version b7e383b) play the song no problem. Can we ignore the error for the "I[ME]: HW\MediaEngine.cpp:87 FF: Invalid gain location: ch=1, sb=5, pos=1, val=0" for atrac->remainFrames == 0 ? Or just this game ?

[sum2012]

JPCSPTrace (Real PSP log): https://gist.github.com/sum2012/114745df24936c15abf81e7e8a356720 01:05.994 ATRAC3 play thread - sceAtracDecodeData 0x0, 0x88F5D6C, 0x09EF9A2C(0x800), 0x09EF9A28(0x0), 0x09EF9A24(0x0) = 0x0 NOTE: sample number is 0x800,finish flag 0,remainframe flag 0

[unknownbrackets]

https://github.com/FFmpeg/FFmpeg/blob/2d764069be3b4092dc986467660607d922023332/libavcodec/atrac3plus.c#L1241

If you play the atrac3+ file in an audio player or ffplay or similar, does it log this error? I think the question is - is this an error in the file, or is it a problem in when the buffer data is being read?

-[Unknown]

[sum2012]

ffplay now required add "SDL_AUDIODRIVER" ,"directsound " ,in "Environment Variables" https://stackoverflow.com/questions/46835811/ffplay-wasapi-cant-initialize-audio-client-ffmpeg-3-4-binaries Anyway ,it play the atrac3+ file no error\no warning

[unknownbrackets]

Then it's probably one of these cases:

• A bug in buffer management accounting (reading RAM not populated yet by the game from the file.)
• An issue with reading from a copy rather than the source data, or reading too early (games could actually call add stream data, and copy the data afterward as long as the playback didn't catch up.)
• Some CPU/caching/other HLE bug that confuses the game into not populating the buffer with the correct content.

I haven't really dug into Atrac in a while, but I remember originally it was all built to try to reconstruct the file in a copy in memory, which was very incorrect and error prone. I think for some buffer types we still do that, rather than using the game RAM directly. I suspect that's the most likely cause.

-[Unknown]

[sum2012]

Just a note:The game's atrac->bufferState_ = ATRAC_STATUS_STREAMED_LOOP_FROM_END

[sum2012]

I get a work around of this game but need pull request 18392 merged first

[glitchengineer]

That's great to hear! Thanks for creating a workaround for it.

[sum2012]

You can test the windows 64 bit build in https://github.com/hrydgard/ppsspp/actions/runs/6761291714#artifacts

[sum2012]

Just a note, in the new version my hack doesn't work

[sum2012]

Can @hrydgard or anyone can make a pspautotest that 01:13:559 user_main I[SCEKERNEL]: HLE\sceKernelThread.cpp:2019 424=sceKernelCreateThread(ATRAC3 play thread, 0880f8dc, 00000010, 32768, 00000000, 00000000) 01:13:560 ATRAC3 play W[SCEKERNEL]: HLE\sceKernelThread.cpp:2577 SCE_KERNEL_ERROR_ILLEGAL_THID=sceKernelWakeupThread(424): unable to wakeup current thread 01:13:560 ATRAC3 play D[ME]: HLE\AtracCtx.cpp:375 Additional chunk data (beyond 16 bytes): 22 00 00 08 03 00 00 00 bf aa 23 e9 58 cb 71 44 a1 19 ff fa 01 e4 ce 62 01 00 28 5c 00 00 00 00 00 00 00 00 01:13:560 ATRAC3 play D[ME]: HLE\AtracCtx.cpp:237 ATRAC analyzed: AT3Plus channels: 2 filesize: 1545452 bitrate: 125 kbps jointStereo: 0 01:13:560 ATRAC3 play D[ME]: HLE\AtracCtx.cpp:238 dataoff: 164 firstSampleOffset: 3749 endSample: 4249578 01:13:560 ATRAC3 play D[ME]: HLE\AtracCtx.cpp:239 loopStartSample: 4117 loopEndSample: 4253695 01:13:560 ATRAC3 play I[ME]: HLE\AtracCtx.cpp:731 Atrac::SetData (buffer=08905cc0, readSize=131072, bufferSize=131072): atrac3+ stereo (2 channels) audio 01:13:560 ATRAC3 play D[ME]: HLE\sceAtrac.cpp:572 0=sceAtracSetDataAndGetID(08905cc0, 00020000) 01:13:560 ATRAC3 play D[ME]: HLE\sceAtrac.cpp:449 00000000=sceAtracGetRemainFrame(0, 09efea24[000000ae]) sceAtracGetRemainFrame() will get less 1 frame when it is missing to call sceAtracSetLoopNum() before ?

[hrydgard]

I've just set things up to work on new pspautotests again, and I'm starting with an atrac3+ streaming test, which we haven't had a good test for before. The idea is to guide the planned re-implementation of sceAtrac that will work more like the real thing.

I will of course test in detail how GetRemainFrame works when streaming.

I want to get 1.19 out in April, so depending on how quickly I make progress, the results of this work may have to wait to 1.20 though. We shall see...

[hrydgard]

Fixed since #20138 (though really fixed by #20098).