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

Handle audio SRC mixing more correctly #12147

Merged
merged 4 commits into from
Jul 5, 2019

Conversation

unknownbrackets
Copy link
Collaborator

This fixes some return values and handles sample rate conversion to a very basic degree.

Per tests in hrydgard/pspautotests#202, the SRC functions of course don't affect global audio frequency, and are just sample rate converted. As of master without this code, we ignore their sample rate which means we consume their samples at an incorrect rate, which affects both playback and timing.

These changes make the tests much closer, although some of the timing is still off.

Games probably using sample rate conversion:
https://report.ppsspp.org/logs/kind/715?status=any
(ignore it being set to 0, that means don't perform conversion.)

Have not tested any of those games, and obviously the experimental resampling is ugly.

-[Unknown]

sceAudioSetFrequency is kernel mode only, and it sounds like it changes
the audio controller clock (didn't test.)  SRC only affects the SRC
channel.

Currently, this doesn't actually use the sample rate yet, but at least
it's tracked appropriately.
@hrydgard
Copy link
Owner

hrydgard commented Jul 4, 2019

Yeah, definitely the right way to go. Do we know any games where this misinterpretation is actually causing issues? Either way should be fixed. Could we merge the first two in the meantime?

The problems of the experimental resampling could be fixed with the same two-sample buffer technique we use in SasAudio.

@unknownbrackets unknownbrackets marked this pull request as ready for review July 5, 2019 00:23
@unknownbrackets
Copy link
Collaborator Author

Did some quick testing finally - for example, Doodle Fit is unmistakably helped by this. Couldn't tell if there were timing problems (it's a simple puzzle game), but the music is so much better.

I think the experimental resampling is significantly better than current master for all cases. Maybe we should just merge as is for now? I was thinking of reusing the same resampler class, but there were some complexities.

A reformat of the reporting data:

Rate # Games Sample Games
22.05kHz 26 Several Minis, Dead or Alive, Arms' Heart, Convenience Store Portable
16kHz 9 Elminage series games
32kHz 8 GTA Vice City, X-Fighters, Kamen Rider, some visual novels
48kHz 8 Dead or Alive, Project Diva, PSPOKEMON (homebrew)
24kHz 4 Visual novel, idol clock
11.025kHz 2 PSPOKEMON (homebrew), Dead or Alive
12kHz 2 PSPOKEMON (homebrew), Dead or Alive
8kHz 1 PSPOKEMON (homebrew)

22.05kHz is by far the simplest case, since we'll just pull half the samples and double them up. I suspect some of the others are based on user-provided music, except Elminage (#9819.)

-[Unknown]

@hrydgard
Copy link
Owner

hrydgard commented Jul 5, 2019

Yeah, let's merge and see how it goes. We'll probably need to extend the savedata again for saving of the little buffers when the resampler is fully corrected, but predicting what will be needed is not really worth it since we might get it wrong.

@hrydgard hrydgard merged commit accccba into hrydgard:master Jul 5, 2019
@unknownbrackets unknownbrackets deleted the audio2-src branch July 6, 2019 02:23
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

2 participants