Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try to match the initial atrac decode size #6935

Merged
merged 9 commits into from
Sep 23, 2014

Conversation

unknownbrackets
Copy link
Collaborator

This uses a buffer skips samples to align the output the same way the PSP aligns its output. Causes the audio/atrac/decode test to pass (though it needs to test more things.)

This may improve any game that accidentally relies on the first decode pass writing less data, and should improve how well the number of frames from decode match. I think there was a game JPCSP recently fixed that we suspected this was the case for?

-[Unknown]

@daniel229
Copy link
Collaborator

Resistance Retribution crashed
01

@daniel229
Copy link
Collaborator

fixes #3326 ,still missing bgm in the match.

@daniel229
Copy link
Collaborator

fixes #5631

@unknownbrackets
Copy link
Collaborator Author

Resistance demo is fixed, ATRAC3 was more different than I realized. Will need to contruct some good public domain samples with loops and stuff...

-[Unknown]

@daniel229
Copy link
Collaborator

Invalid addresses happen more early than before,and crash in Resistance.
02

@unknownbrackets
Copy link
Collaborator Author

Hmmm... can you get it to crash in the demo? In your output, outBytes is negative, this should've been fixed in my latest commit. Hmm, that's a new different screenshot now.

I did hit another crash in the demo though that appears completely unrelated (divide by zero in gpu memcpy)...

Anyway, the demo runs okay for me, at least, getting to the second area and then dying.

-[Unknown]

@daniel229
Copy link
Collaborator

I can't get crash in the demo,the invalid addresses happen at the beginning,if you don't skip anything in the demo.

@unknownbrackets
Copy link
Collaborator Author

No crashes or invalid addresses in the demo for me. Note: I am using PSP-1000 which I believe to much more closely replicate actual PSP behavior.

-[Unknown]

@daniel229
Copy link
Collaborator

whatever 1000 or 2000,I am still getting invalid addresses in this scene.
03

@daniel229
Copy link
Collaborator

I upload a savestate which 1 second before the invalid addresses happen.
https://drive.google.com/file/d/0BzGZGDfFE68zc2xjdXViWEhjdGs/edit?usp=sharing

@unknownbrackets
Copy link
Collaborator Author

Okay, got it. I must've accidentally skipped it, sorry. Hmm, strange...

Maybe I still have something wrong for mono audio. Grr, so many variations to test, need more sample audio. Hmm, or not? Maybe it's something else broken in sceAtrac.

-[Unknown]

@daniel229
Copy link
Collaborator

mono usually for voice.

@daniel229
Copy link
Collaborator

Nana Subete wa Daimaou no Omichibiki crashed
03

@daniel229
Copy link
Collaborator

Fixes GHA Ohase shifting hangup problem in tenchu4

@hdd60311
Copy link

Nice, glad to see the hanging issue with motostorm will be fixed finally.

@unknownbrackets
Copy link
Collaborator Author

Resistance problem seems to be caused by sceAtracGetNextSample() not matching up for some reason, possible it or endSample is wrong.

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

Ah, okay, more testing and looking at the decoded data - I think it's supposed to skip the first N samples, rather than deferring those to the next chunk. I suppose this makes more sense.

Also, I'm not sure, but it seems like the decoder always returns a full block of data or none at all (e.g. instead of 3 samples, it gives back 2048, then says it's out.) This is fixable too, will just have to truncate it based on our calculation.

-[Unknown]

@unknownbrackets
Copy link
Collaborator Author

Okay this works better.

I was comparing data, and the beginning of the decoded audio stream doesn't match. This might be a problem in the decoder or a problem in the way it seeks, but it's only for the first couple frames. This is true before my changes as well, though.

Resistance definitely works now. Hopefully those other games still do as well. In fact, this might fix more games now.

-[Unknown]

@daniel229
Copy link
Collaborator

Great that Resistance fixed,But Tenchu 4 seems not like the change,It loop in a sound or hangup.
This game #3122 in that battle,the BGM stop more early.
this games #2539 in that spot missing bgm and still hangup.

@daniel229
Copy link
Collaborator

Nana Subete wa Daimaou no Omichibiki doesn't crash now,but would lost bgm in a few second and hangup.

@unknownbrackets
Copy link
Collaborator Author

Okay, how about that? It should improve games that have GHA phase shifting issues, and generally games that hung.

-[Unknown]

@daniel229
Copy link
Collaborator

Tenchu 4 no problem now,Nana Subete wa Daimaou no Omichibiki still hang on title when bgm lost.

@unknownbrackets
Copy link
Collaborator Author

There's no demo of course, right? That's this one? http://forums.ppsspp.org/showthread.php?tid=6273

It wasn't locking up before or losing the background music? Does the log show anything useful?

-[Unknown]

@daniel229
Copy link
Collaborator

the game should be no demo.before not hang on title,it hangs on the match.now it look like hang when bgm stopped,if you click button quickly,you can go far.

the info log
01

the debug log full of these
34:16:235 snd_thread_m D[ME]: HLE\sceAtrac.cpp:776 80630024=sceAtracDecodeData(1, 08b0113c, 09fbda68[00000000], 09fbda64[00000001], 09fbda60[0])

ppsspplog (rename jpg to rar)

@daniel229
Copy link
Collaborator

#4595 and #5353 are fixed

@daniel229
Copy link
Collaborator

#3122 and #2539 bgms are back now same as before.

@sum2012
Copy link
Collaborator

sum2012 commented Sep 23, 2014

#6824 game don't like this change

Already shown in decode test to be valid.
@unknownbrackets
Copy link
Collaborator Author

Does that improve the hanging at all?

There are a lot of funcs that don't return exactly the right data, I don't want to create one pull request that changes every single last function in sceAtrac, it will be a nightmare.

-[Unknown]

@daniel229
Copy link
Collaborator

Yes,also fixes the issue #6802

@sum2012
Copy link
Collaborator

sum2012 commented Sep 23, 2014

Yes fix #3552
#2539 same as v0.9.9.1-523-g199e6bc problem.
I think can merge this :)

This seems to be what the PSP actually does, although not sure.  The first
result is always smaller by this amount (numerous atrac files tested.)
Not sure the very start is right though, arg.
Some games depend on / expect this, or else they'll let important data get
overwritten.
We could probably insert frames instead for GHA phase shifting, but this
will solve other bugs too, I think.
I think it's meant to be the last *valid* sample.
@sum2012
Copy link
Collaborator

sum2012 commented Sep 23, 2014

Just a note JPCSP draft implementation for GHA Phase shifting in
http://code.google.com/p/jpcsp/source/detail?r=3633

@hrydgard
Copy link
Owner

Alright, let's give it a shot. Looks like solid improvements, nice work.

hrydgard added a commit that referenced this pull request Sep 23, 2014
Try to match the initial atrac decode size
@hrydgard hrydgard merged commit 2aed007 into hrydgard:master Sep 23, 2014
@daniel229
Copy link
Collaborator

Test with master.#6802 ,#4595 ,#5353 ,#5631 ,those issues are fixed by this branch.

@unknownbrackets
Copy link
Collaborator Author

Well, my workaround for GHA phase shifting is by far not a fix or implementation, I'm staying out of ffmpeg. It just makes it less visible to the game.

-[Unknown]

@vsub
Copy link

vsub commented Sep 24, 2014

About Radiant Mythology 3,the music doesn't disappear where it was always disappearing here but when you start a new game and carefully listen to the music and voices,you will notest that the music and the voices are like skipping half a second of the song and something like that happens when you go to another area.

I can't explain it very well...in sort,there is still something wrong.

@sum2012
Copy link
Collaborator

sum2012 commented Sep 24, 2014

@unknownbrackets I just think that we might need improve ffmpeg to fix sound bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants