ppsspp
ppsspp copied to clipboard
hrydgard
Gripshift audio problems / errors
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
Merge #6976 still do not work
debug log: https://drive.google.com/file/d/0B3OaSdeV0L8kcGdPUzlKSlVOZnM/view?usp=sharing
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])
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
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]
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.
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]
Same before (this time I use eur version) v1.1.1-488-g368eef5 https://gist.github.com/sum2012/2b942ecec17d6968907a
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]
Does #8356 help this at all? Although this might be streaming, I'm not sure.
-[Unknown]
v1.1.1-577-gefc1768 still not fixed log: https://gist.github.com/sum2012/fadb300d0ed9b1de13d4
v1.1.1-698-g98c779c can in-game but I cannot test further media log: https://gist.github.com/sum2012/b05954603151a86a70c8
GE debugger
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?
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
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
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]
v1.3-98-g492bda6 still has the audio problems it has a thick flashing line down the bottom of the screen and it froze up when it went to load level 2
using v1.3-697-gdfae4b6 still happens here is a JPCSP trace log of all the SceAtrac functions rename txt to zip JPCSPtracelog.txt
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
Update: on the latest update it now crashes the emulator (exit to the home screen) v1.9.3-170-g6a196c04a on Android 9
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
#7638 don't work modify log https://gist.github.com/sum2012/929a17c91df6ab41f4487abfb34abb28
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
I try to seek data when AddStreamData https://github.com/sum2012/ppsspp/commit/061a598e9b3c6dbe122e9d0cd5b75383f8a4452d Fix this but break Code Lyoko Quest for Infinity USA Both games atrac->bufferState are same ATRAC_STATUS_STREAMED_LOOP_FROM_END
@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
https://github.com/hrydgard/ppsspp/blob/1cd520ae3174680b98d5e442dc55e5e7378d02af/Core/HLE/sceAtrac.cpp#L1093
I'm not familiar with audio/atrac3, just being curious why is this not first_.writableBytes = bufferEnd - bufferStartUsed; ?
https://github.com/hrydgard/ppsspp/blob/1cd520ae3174680b98d5e442dc55e5e7378d02af/Core/HLE/sceAtrac.cpp#L1093
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.
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]
