SasAudio: Implement linear interpolation #8950
Conversation
|
Just a reminder: a previous attempt by me caused pops in certain areas, as reported by some users. May be something to test here. #5509. IIRC it seemed like the PSP used trilinear. -[Unknown] |
| for (int i = delay; i < grainSize; i++) { | ||
| while (sampleFrac >= PSP_SAS_PITCH_BASE) { | ||
| voice.resampleHist[0] = voice.resampleHist[1]; | ||
| voice.ReadSamples(&voice.resampleHist[1], 1); |
There was a problem hiding this comment.
Hmm, I wonder if this could have a significant impact to VAG decode speed (I know you mentioned this can't be terribly fast)? I guess would need to measure... a good thing it can be on a separate thread now...
-[Unknown]
There was a problem hiding this comment.
Actually I think I want to go back to reading many samples at a time, but I wanted to switch to a known good algorithm first, before I try making it more efficient.
|
I've been requesting that feature a looong time ago. Thanx alot. I hope it can be applied to samples that PSP doesn't apply any interpolation either (like voice clips and sfx in GTA/Monster Hunter/KH games). But seriously, linear is the best, no aliasing so no extra metalic harmonics. Very happy. |
Not sure about the performance impact, but calling ReadSamples with 1 as an argument can't be terribly fast. So this might need some redesign before merge, but should be a good starting point.
hrydgard
force-pushed
the
audio-linear-interpolation
branch
from
02cea9e
to
1e09595
Compare
|
I removed the overhead one verifiable step at a time, and now it's really fast and correct :) Or at least should be. Merge time once the builds pass. |
hrydgard
changed the title
| @@ -38,6 +38,7 @@ enum { | |||
| PSP_SAS_PITCH_MAX = 0x4000, | |||
|
|
|||
| PSP_SAS_VOL_MAX = 0x1000, | |||
| PSP_SAS_MAX_GRAIN = 1024, // VERY conservative! 256 is quite common but don't think I've ever seen bigger. | |||
There was a problem hiding this comment.
__sceSasInit allows grainSize of 2048 at most, any higher values fail with ERROR_SAS_INVALID_GRAIN. But 2048 is allowed.
-[Unknown]
There was a problem hiding this comment.
Oh right, that's a pretty compelling argument. I'll change it.
PPSSPP's audio has always been a little bit harsher and brighter than the real thing, because interpolation was missing in the mixer. This implements linear interpolation, which I believe is what the PSP also uses. Higher order interpolation could be implemented but I don't think it'll be very noticable, the big difference is from none to linear.
Currently this is a straightforward unoptimized implemenation. Not sure about the performance impact, but calling ReadSamples with 1 as an argument can't be terribly fast. So should probably restore the resampleBuffer but make sure the results are exactly the same as from this (the old calculation had issues which is why we needed the smoothness "hackery" which has now been removed).