Gripshift audio problems / errors #7601

sum2012 · 2015-03-15T23:32:46Z

There is a work around for USA version
http://forums.ppsspp.org/showthread.php?tid=1040&pid=104256#pid104256
@unknownbrackets
v1.0.1-177-g0b7ae3d
Music volume zero (good) log:
https://drive.google.com/file/d/0B3OaSdeV0L8kNXFlcEZXbXZIOFU/view?usp=sharing
Music volume full (bad) log:
https://drive.google.com/file/d/0B3OaSdeV0L8kYkd2VGIwcmdPLW8/view?usp=sharing

sum2012 · 2015-03-16T14:34:38Z

Merge #6976 still do not work

debug log:
https://drive.google.com/file/d/0B3OaSdeV0L8kcGdPUzlKSlVOZnM/view?usp=sharing

sum2012 · 2015-03-17T14:50:53Z

v1.0.1-178-g0dda098 Media log
https://gist.github.com/sum2012/7b456d7dd51d28570c56/raw/gistfile1.txt

JPCSPtrace log:
https://gist.github.com/sum2012/6d90112fdc1f897a0e14

These line lend to the problem
11:45:247 FMOD Streame I[ME]: HW\MediaEngine.cpp:85 FF: Invalid start bit!
11:45:247 FMOD Streame E[ME]: HLE\sceAtrac.cpp:377 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7
11:45:247 FMOD Streame D[ME]: HLE\sceAtrac.cpp:961 80630024=sceAtracDecodeData(0, 08cdf610, 0bfdedb0[00000000], 0bfdedb4[00000001], 0bfdeda0[0])

sum2012 · 2015-03-20T14:19:38Z

link to #7445 same sound problem

sum2012 · 2015-03-20T14:33:01Z

Update the log to v1.0.1-195-g87f31d0
(Just in menu don't do anything)
https://gist.github.com/sum2012/f3a0c4d40dc1a982f2bd
JPCSPtrace log:
https://gist.github.com/sum2012/30205334ec15bcab14c6/raw/gistfile1.txt

@unknownbrackets
A new finding - sceAtracGetStreamDataInfo write wrong value in writableBytesAddr in sceAtracGetStreamDataInfo
PPSSPP log:
24:20:180 FMOD Streame D[ME]: HLE\sceAtrac.cpp:1198 sceAtracGetRemainFrame(0, 0bfdeda0[109])

24:20:180 FMOD Streame D[ME]: HLE\sceAtrac.cpp:1279 sceAtracGetStreamDataInfo(0, 0bfdeda4[08ce3180], 0bfdeda8[0001e000], 0bfdedac[0001e000])

24:20:181 FMOD Streame I[KERNEL]: HLE\sceKernelThread.cpp:2176 735=sceKernelCreateThread(name=FMOD async FILE thread, entry=089ab078, prio=64, stacksize=4096)

24:20:181 FMOD Streame I[KERNEL]: HLE\sceKernelThread.cpp:2275 sceKernelStartThread(thread=735, argSize=4, argPtr=00000000)

24:20:181 FMOD Streame D[ME]: HLE\sceAtrac.cpp:788 sceAtracAddStreamData(0, 0001e000)

JPCSPTrace log:
23:36:32.996505 FMOD Streamer thread - -> sceAtracGetStreamDataInfo 0x0, 0x09FDA2A4(0xFFFFFFFF), 0x09FDA2A8(0xFFFFFFFF), 0x09FDA2AC(0xFFFFFFFF) = 0x0
23:36:32.996570 FMOD Streamer thread - <- sceAtracGetStreamDataInfo 0x0, 0x09FDA2A4(0x8CE31CC), 0x09FDA2A8(0xF0F8), 0x09FDA2AC(0x1E000) = 0x0
23:36:32.996697 FMOD Streamer thread - -> sceKernelCreateThread 0x08A80420('FMOD async FILE thread'), 0x89AB078, 100, 0x1000, 0x0, 0x0 = 0x0
23:36:32.997180 FMOD Streamer thread - <- sceKernelCreateThread 0x08A80420('FMOD async FILE thread'), 0x89AB078, 100, 0x1000, 0x0, 0x0 = 0x4677B4F
23:36:32.997335 FMOD Streamer thread - -> sceAtracAddStreamData 0x0, 0xF0F8 = 0x0
23:36:32.997415 FMOD Streamer thread - <- sceAtracAddStreamData 0x0, 0xF0F8 = 0x0

Another new finding will discuss in pull request

unknownbrackets · 2015-03-20T14:51:11Z

Yes, I already know that sceAtracGetStreamDataInfo (and several other funcitons) return and write very different values from what the PSP actually writes. A large portion of sceAtrac in PPSSPP does not function the way that sceAtrac works on PSP firmware - basically all of the buffer management, which is most of it, plus some of the context management.

Unfortunately, it's hard to even tell if that's causing this problem or not. What's for sure is that if sceAtrac behaved exactly like it did on a PSP, more games would work more correctly. It's not for sure that it would even fix this issue, though it probably would.

Because it affects an extremely large percentage of sceAtrac's code, the only way I know how and have time to fix it is incrementally, with information, reports, and testing from each step of the change. Certain games will, doubtless, break during the process, since all the wrong parts of sceAtrac are subtly relying on everything else that is also broken. It's a house of cards that has to be slowly transplanted, and some cards will definitely fall to the ground in the process - but they can be picked up.

Nevertheless, no one wants / is willing for games to be broken. This means it all has to be changed at once, and has to be perfect (breaking no even kinda brokenly working games.) Unfortunately, this is completely and far beyond my abilities. Which means I'm not capable of fixing this.

I could maybe add all kinda of crazy paths and game specific hacks to make certain games work, so I guess it's "within my abilities" to do it a horribly bad way, or just spend a ton of time on it slaving away, but since this is something I'm doing in my free time to (ideally) reduce my stress, I'm not interested.

-[Unknown]

sum2012 · 2015-03-20T14:55:06Z

It is okay,I just share what I find.
If it is fixed by me,I would be very happy.

I'm not capable of fixing this.

Fix GTA no sound and Fix hrydgard#7601

unknownbrackets · 2015-12-29T21:37:34Z

Okay, well, we've begun breaking some games in a long-term plan for sceAtrac now.

What does this look like now? A more updated log may help.

-[Unknown]

sum2012 · 2015-12-29T22:11:27Z

Same before (this time I use eur version)
v1.1.1-488-g368eef5
https://gist.github.com/sum2012/2b942ecec17d6968907a

unknownbrackets · 2015-12-29T22:26:39Z

You're right that the sceAtracGetStreamDataInfo result is important.

D[ME]: HLE\sceAtrac.cpp:1129 00000000=sceAtracDecodeData(0, 08d87800, 09fdedb0[00000800], 09fdedb4[00000000], 09fdeda0[109])
D[ME]: HLE\sceAtrac.cpp:1393 0=sceAtracGetRemainFrame(0, 09fdeda0[0000006d])
D[ME]: HLE\sceAtrac.cpp:1482 sceAtracGetStreamDataInfo(0, 09fdeda4[08d69700], 09fdeda8[0001e000], 09fdedac[0001e000])
I[KERNEL]: HLE\sceKernelThread.cpp:1943 790=sceKernelCreateThread(FMOD async FILE thread, 089b3108, 00000064, 4096, 00000000, 00000000)
I[KERNEL]: HLE\sceKernelThread.cpp:2014 0=sceKernelStartThread(790, 4, 00000000)
D[ME]: HLE\sceAtrac.cpp:968 0=sceAtracAddStreamData(0, 0001e000)
D[ME]: HLE\sceAtrac.cpp:1129 00000000=sceAtracDecodeData(0, 08d622b0, 09fdedb0[00000800], 09fdedb4[00000000], 09fdeda0[327])

When it runs out of the original data it had (109 remaining frames), it gets to 218. That's where it dies:

D[ME]: HLE\sceAtrac.cpp:1129 00000000=sceAtracDecodeData(0, 08d622b0, 09fdedb0[00000800], 09fdedb4[00000000], 09fdeda0[219])
D[ME]: HLE\sceAtrac.cpp:1393 0=sceAtracGetRemainFrame(0, 09fdeda0[000000db])
I[ME]: HW\MediaEngine.cpp:87 FF: Invalid gain location: ch=0, sb=3, pos=1, val=6
E[ME]: HLE\sceAtrac.cpp:479 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7
D[ME]: HLE\sceAtrac.cpp:1129 80630024=sceAtracDecodeData(0, 08d87800, 09fdedb0[00000000], 09fdedb4[00000001], 09fdeda0[0])
I[ME]: HLE\sceAtrac.cpp:1778 sceAtracSetData(0, 08d69700, 0001e000)
W[ME]: HLE\sceAtrac.cpp:1710 This is an atrac3+ stereo audio
D[ME]: HLE\sceAtrac.cpp:1869 sceAtracSetLoopNum(0, -1)
D[ME]: HLE\sceAtrac.cpp:1393 0=sceAtracGetRemainFrame(0, 09fbf750[000000da])
D[ME]: HLE\sceAtrac.cpp:1129 00000000=sceAtracDecodeData(0, 08d61310, 09fbf760[00000000], 09fbf764[00000000], 09fbf750[218])

But another thing is happening here: sceAtracSetData isn't resetting the decode error. Actually, #7638 fixes that, which might allow this game to "recover" (or might not), but there's still a bug here outside that.

I think this might be reading the data AFTER calling sceAtracAddStreamData, just like I think #3650 is doing. That would explain it, since it would've loaded in garbage.

-[Unknown]

unknownbrackets · 2016-01-02T20:35:33Z

Does #8356 help this at all? Although this might be streaming, I'm not sure.

-[Unknown]

sum2012 · 2016-01-02T22:26:04Z

v1.1.1-577-gefc1768 still not fixed
log:
https://gist.github.com/sum2012/fadb300d0ed9b1de13d4

sum2012 · 2016-01-17T10:55:06Z

v1.1.1-698-g98c779c
can in-game but I cannot test further
media log:
https://gist.github.com/sum2012/b05954603151a86a70c8

GE debugger

hrydgard · 2016-01-17T11:14:48Z

Heh, that looks terrible. Looks like we'll be opening some new issues about this game now that it renders..

Does the music work okay?

sum2012 · 2016-01-17T11:16:38Z

Yes
edit:It is okay to close this issue first

daniel229 · 2016-01-17T11:19:12Z

Just waiting on the title,still 17:14:208 FMOD Streame E[ME]: HLE\sceAtrac.cpp:527 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7

sum2012 · 2016-01-17T11:24:06Z

edit:This time I use USA version
Yes,the sound in the title still have problem (I test in the loading save screen)
https://gist.github.com/sum2012/069586b1f3b8dd517d78

unknownbrackets · 2016-01-17T18:35:13Z

Progress is good. That's interesting.

It fails right around when the data added here is decoded:

22:43:490 FMOD Streame D[ME]: HLE\sceAtrac.cpp:1593 0=sceAtracGetStreamDataInfo(0, 09fdeda4[08ce31cc], 09fdeda8[0000f0f8], 09fdedac[0001e000])
22:43:490 FMOD Streame I[KERNEL]: HLE\sceKernelThread.cpp:1943 735=sceKernelCreateThread(FMOD async FILE thread, 089ab078, 00000064, 4096, 00000000, 00000000)
22:43:490 FMOD Streame I[KERNEL]: HLE\sceKernelThread.cpp:2014 0=sceKernelStartThread(735, 4, 00000000)
22:43:490 FMOD Streame D[ME]: HLE\sceAtrac.cpp:1072 0=sceAtracAddStreamData(0, 0000f0f8)

Hmm:

22:17:909 user_main I[ME]: HLE\sceAtrac.cpp:1835 0=sceAtracSetData(0, 08ce3180, 0001e000): atrac3+ stereo audio

Size seems right. So, I'm thinking it may be that it's writing asynchronously to the buffer, which still isn't supported.

-[Unknown]

mrcmunir · 2018-03-17T13:27:16Z

Update Is happen in the actual master code test it in 1.5.4-692-g940d8b458
Freeze after first level

19:40:790 user_main    I[ME]: HLE/sceAtrac.cpp:1671 0=sceAtracReleaseAtracID(0)
19:40:807 user_main    I[ME]: HLE/sceAtrac.cpp:1910 0=sceAtracSetDataAndGetID(08ac6980, 00001000): atrac3+ stereo audio
19:40:817 user_main    I[ME]: HLE/sceAtrac.cpp:1910 0=sceAtracSetData(0, 08ce3180, 0001e000): atrac3+ stereo audio
19:51:041 FMOD Streame I[ME]: HW/MediaEngine.cpp:86 FF: Frame data doesn't match channel configuration!
19:51:041 FMOD Streame E[ME]: HLE/sceAtrac.cpp:570 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7

takeshineale128 · 2020-01-01T14:56:04Z

still not working and soft locking. v19.3-164-g0a5ec4838

takeshineale128 · 2020-01-04T15:29:02Z

Update: on the latest update it now crashes the emulator (exit to the home screen) v1.9.3-170-g6a196c04a on Android 9

sum2012 · 2020-05-17T10:00:40Z

USA version test
ppsspp-v1.9.3-830-g9e5be91bf-windows-amd64
The sound still bad when
6:24:149 FMOD Streame I[ME]: hw\mediaengine.cpp:86 FF: Frame data doesn't match channel configuration!
56:24:149 FMOD Streame E[ME]: hle\sceatrac.cpp:570 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7

full log:

https://gist.githubusercontent.com/sum2012/6c5f8607fbde6d5e30596fcb4c2d911c/raw/649235db7714daa6607fc5c9b3cef8fdbf5bd16e/gistfile1.txt

sum2012 · 2020-05-17T11:30:52Z

#7638 don't work
modify log
https://gist.github.com/sum2012/929a17c91df6ab41f4487abfb34abb28

sum2012 · 2020-12-18T15:02:08Z

v1.10.3-1330-g73da378ef-windows-amd64 same problem.
The sound bad when
00:24:953 FMOD Streame E[ME]: hle\sceatrac.cpp:571 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7
full log: https://gist.github.com/sum2012/3a3fb9005b1d53c1804a790a4f972eb4

sum2012 · 2020-12-18T15:10:51Z

I try to seek data when AddStreamData
sum2012@061a598
Fix this but break Code Lyoko Quest for Infinity USA
Both games atrac->bufferState are same ATRAC_STATUS_STREAMED_LOOP_FROM_END

sum2012 · 2020-12-21T12:43:04Z

@eltomas2003 edit: or others
This is windows 64 bit test build 2
Can you test whether any game regression of music ? Thanks
https://drive.google.com/file/d/1kKVEwousMWlkHlMbN2X3B13tOxsR4VbZ/view?usp=sharing

anr2me · 2021-10-19T08:22:06Z

ppsspp/Core/HLE/sceAtrac.cpp

Line 1093 in 1cd520a

first_.writableBytes = bufferPos_ - bufferStartUsed;

I'm not familiar with audio/atrac3, just being curious why is this not first_.writableBytes = bufferEnd - bufferStartUsed; ?

mrcmunir · 2021-10-24T23:55:56Z

ppsspp/Core/HLE/sceAtrac.cpp

Line 1093 in 1cd520a

first_.writableBytes = bufferPos_ - bufferStartUsed;

I'm not familiar with audio/atrac3, just being curious why is this not first_.writableBytes = bufferEnd - bufferStartUsed; ?

Not helped and this weird bug its very old bug
I have tested since 0.9.5 and the error must be introduced somewhere in 0.9.1 and 0.9.5 commit.

unknownbrackets · 2021-10-25T00:37:09Z

I'm not familiar with audio/atrac3, just being curious why is this not first_.writableBytes = bufferEnd - bufferStartUsed; ?

So, bufferPos_ is the next byte position to decode a frame from. Also, bufferValidBytes_ is the number of bytes that contain valid frames to decode, starting at position (but potentially wrapping around.)

Importantly, bufferEnd is, if the buffer were theoretically full, the position of the end of the last possible frame in the buffer. Note this isn't related to valid bytes - this is just, literally, the end of the buffer. It might not match the size of the buffer, if the size of the buffer is not properly aligned to the frame size (plus header.)

Here's a diagram:

    bufferPos \
|++++----------O++++++++++|
^ BufferStart()           ^ StreamBufferEnd()

So, this if here is determining the size and position the game could provide more bytes for the music. There's two possible locations:

From the start of the buffer, until the current buffer position. This contains data that has already been played, so we can overwrite it.
After the last valid frame, until the end of the buffer. This is data we potentially haven't read yet.

This is just a "circular buffer", which is common in streaming.

In the diagram above, the + is valid data. There are 10 frames to the right of the current position, plus another four from the start. A total of 14 valid frames. The next place we could write data would be at the first -, which is case 1 above.

first_.writableBytes = bufferEnd - bufferValidExtended; is for when we could write more data after the last valid frame but before the end of the buffer (right of our position.) So we figure out how many bytes are left after the valid size until the end (the if makes sure this isn't zero or negative.)

Otherwise, the else uses first_.writableBytes = bufferPos_ - bufferStartUsed; because that's how many bytes are already used before the current position. That's the size of the -s in the diagram.

If we used first_.writableBytes = bufferEnd - bufferStartUsed; in that else, it would tell the game it could overwrite not just the -s, but also the O and +s to the right of the -s, overwriting music data we haven't played yet.

-[Unknown]

sum2012 · 2022-08-13T12:17:04Z

Can we have a hack option to work around it ?

ghost · 2022-08-13T13:46:53Z

Can we have a hack option to work around it ?

Yeah 👍

AryzenRS · 2022-08-21T09:22:31Z

I left a comment on #15838 but I should mention it here as well, the music doesn't loop in the correct spot using that hack, it loops about 8 bars for the title screen and then jumps to a later part and loops there instead. It's the same for in game music.

unknownbrackets · 2022-08-21T14:09:56Z

That's basically exactly what the hack seems to be intending to do, looking at its code.

-[Unknown]

AryzenRS · 2022-08-21T23:28:07Z

Ah I see. After some deliberation with someone else we decided I should say that’s what’s happening. If that’s as intended, I can say it works as intended!

takeshineale128 · 2022-10-16T10:05:42Z

no longer crashes/freezes after the first level (v1.13.2-1546) tested on windows 11 pc and android 12 phone

takeshineale128 · 2022-12-04T02:08:35Z

No longer crashes/freezes after the first level (v1.13.2-2289) tested on windows 11 pc and android 12 phone please close this issue (ULES00117) European version.

unknownbrackets · 2022-12-04T02:14:02Z

That's #15838 right? Does the whole song actually play?

-[Unknown]

takeshineale128 · 2022-12-04T02:15:27Z

yes the whole song does play and can exit the level when time ran out

unknownbrackets · 2022-12-04T02:17:11Z

Well, I do think that's a hack still, but I guess wen can close this given the game is working... at some point we'll be forced to create ppmpeg and eventually this hack will get fixed, one way or another. Thanks for testing and confirming.

-[Unknown]

sum2012 added a commit to sum2012/ppsspp that referenced this issue Mar 23, 2015

loop back first sample when decode fail in _AtracDecodeData

b4e8e8d

Fix GTA no sound and Fix hrydgard#7601

sum2012 mentioned this issue Mar 23, 2015

Loop back the Atrac sound when decode fail in _AtracDecodeData unknownbrackets/ppsspp#5

Closed

unknownbrackets added the Atrac3+ Issue involves sceAtrac features. label Dec 30, 2015

unknownbrackets mentioned this issue Jan 3, 2016

Gripshift USA - Stuck/Hang Randomly #8372

Closed

unknownbrackets changed the title ~~Gripshift freeze in-game~~ Gripshift audio problems / errors Jan 18, 2016

unknownbrackets mentioned this issue Mar 7, 2019

Grip Shift Not Loading Levels #11871

Closed

sum2012 mentioned this issue Dec 19, 2020

Atrac addStream:SeekToSample when RemainingFrames > 2 #13793

Closed

Panderner mentioned this issue Dec 20, 2020

Gripshift crashes a lot #13801

Closed

hrydgard added this to the Future milestone Dec 20, 2020

mrcmunir mentioned this issue Oct 8, 2021

GripShift™ Timing/Rendering Issue? #14992

Closed

5 tasks

ghost mentioned this issue Oct 14, 2021

Gripshift Euro - audio lockup #15018

Closed

5 tasks

sum2012 mentioned this issue Aug 14, 2022

Add atrac looping hack for 4 games #15838

Merged

ghost mentioned this issue Aug 17, 2022

Silverfall (ULES00808) soundtrack loop after a while #7708

Open

anr2me mentioned this issue Sep 9, 2022

Need for Speed games crash after a while since 1.13. version #15788

Closed

5 tasks

unknownbrackets closed this as completed Dec 4, 2022

unknownbrackets modified the milestones: Future, v1.14.0 Dec 4, 2022

Gripshift audio problems / errors #7601

Gripshift audio problems / errors #7601

Comments

sum2012 commented Mar 15, 2015

sum2012 commented Mar 16, 2015

sum2012 commented Mar 17, 2015

sum2012 commented Mar 20, 2015

sum2012 commented Mar 20, 2015

unknownbrackets commented Mar 20, 2015

sum2012 commented Mar 20, 2015

unknownbrackets commented Dec 29, 2015

sum2012 commented Dec 29, 2015

unknownbrackets commented Dec 29, 2015

unknownbrackets commented Jan 2, 2016

sum2012 commented Jan 2, 2016

sum2012 commented Jan 17, 2016

hrydgard commented Jan 17, 2016

sum2012 commented Jan 17, 2016

daniel229 commented Jan 17, 2016

sum2012 commented Jan 17, 2016

unknownbrackets commented Jan 17, 2016

mrcmunir commented Mar 17, 2018

takeshineale128 commented Jan 1, 2020

takeshineale128 commented Jan 4, 2020 • edited Loading

sum2012 commented May 17, 2020

sum2012 commented May 17, 2020

sum2012 commented Dec 18, 2020

sum2012 commented Dec 18, 2020

sum2012 commented Dec 21, 2020 • edited Loading

anr2me commented Oct 19, 2021

mrcmunir commented Oct 24, 2021

unknownbrackets commented Oct 25, 2021 • edited Loading

sum2012 commented Aug 13, 2022

ghost commented Aug 13, 2022

AryzenRS commented Aug 21, 2022

unknownbrackets commented Aug 21, 2022

AryzenRS commented Aug 21, 2022

takeshineale128 commented Oct 16, 2022 • edited Loading

takeshineale128 commented Dec 4, 2022 • edited Loading

unknownbrackets commented Dec 4, 2022

takeshineale128 commented Dec 4, 2022

unknownbrackets commented Dec 4, 2022

takeshineale128 commented Jan 4, 2020 •

edited

Loading

sum2012 commented Dec 21, 2020 •

edited

Loading

unknownbrackets commented Oct 25, 2021 •

edited

Loading

takeshineale128 commented Oct 16, 2022 •

edited

Loading

takeshineale128 commented Dec 4, 2022 •

edited

Loading