mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
If you will indulge me in letting me put on my technical writing hat only -- would folks be willing to take a look at the Troubleshooting RetroArch Audio Skew Issues doc I have drafted?
I'm looking especially for feedback on mistakes in how I characterize the feature and the fix. Also for any specific games that are known to have audio issues that can be affected by
audio_max_timing_skew.I hope that the payoff will be being able to say "read the docs" next time this comes up :)
-
RetrArch includes a setting called audio_max_timing_skew. The audio timing skew feature is helps RetroArch know when to resample the audio when it is making adjustments like resampling NTSC console games that display at rates like 60.0988Hz to sync on displays that run at 60.0Hz
my understanding is that it 'resamples' (perhaps not the right word) the fps as well. that is, a 57.4fps game on a display of 60Hz:
- is sped up so it becomes true 60fps (ie, does not tear (v sync off), or does not hold the occasional frame for 2 frames (v sync on))
- the audio is resampled to the new fps as you say.
a game running faster than 60fps, yet still within your skew threshold, will be slowed + pitched down.
Issues with Audio Skew in mame2003-plus
again, audio skew has no effect on mame2003-plus. see my above post. it does on mame2003 vanilla (and i guess any other core).
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
my understanding is that it 'resamples' (perhaps not the right word) the fps as well. that is, a 57.4fps game on a display of 60Hz:
is sped up so it becomes true 60fps (ie, does not tear (v sync off), or does not hold the occasional frame for 2 frames (v sync on))
the audio is resampled to the new fps as you say.That makes sense! I will add. And I will move the wiki to mame2003 instead. Fun!
Now it's here: https://github.com/libretro/mame2003-libretro/wiki/Troubleshooting-RetroArch-Audio-Skew-Issues
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
me that should (according to the default settings) be skewed to 60.
so, any testing you do would have to be with mame2003 vanilla.your not set to 60 fps your at game rate fps unless im miss understanding something here
-
I think you need to use vsync loosely in this scenario. I'm not sure on the Pi (does it have vsync capabilities even?) but usually on a PC when you're under the monitor refresh rate you leave vsync off as it isn't going to do anything. Except maybe lower the refresh to match the video capabilities in multiples. When the framerate is above the monitor refresh rate frames get "throttled" and sent to video purgatory.
-
I doubt there will be any difference for audio scew and how we are doing it. if there is we can change it just dont see any problems at all if there is a diffence between audio scew and the way we are doing it ill change it. If audio scew is smoother at 57 fps id be surprised but pleasantly if it does improve things cant see it though never say never!
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
me that should (according to the default settings) be skewed to 60.
so, any testing you do would have to be with mame2003 vanilla.your not set to 60 fps your at game rate fps unless im miss understanding something here
yes, exactly. if you set at 60 then audio skew does nothing, because it thinks your game is 60 fps and just dropping frames. if you report the game as 57.4fps (as mame2003 vanilla does) it will skew it.
-
@riverstorm said in mame2003-plus: 250 new games, new input system, new features, new bugs:
I think you need to use vsync loosely in this scenario. I'm not sure on the Pi (does it have vsync capabilities even?) but usually on a PC when you're under the monitor refresh rate you leave vsync off as it isn't going to do anything. Except maybe lower the refresh to match the video capabilities in multiples. When the framerate is above the monitor refresh rate frames get "throttled" and sent to video purgatory.
pi has vsync and it’s on by default. yes, retroarch will always send 60 fps to your 60 fps display, but (with the skew feature) it will speed up a 57.4 fps game to true 60, rather than hold ~3 frames every second to for 2 frames, to judder it to an effective 57.4 speed.
-
Am I right at the big picture level that -- when this feature kicks in -- it's boiling down to a choice between:
- Pitch changes to the emulated audio OR
- Judder/held drames/dropped frames in the video
In yet other words: There is no way to avoid either audio inaccuracy or issues with video frames when displaying 57.whatver Hz in a 60hz video environment.
-
mark try both see if one is any better than the other its all theory atm pitch only changes because the game runs too fast you run faster the pitch will change. I would like to hear feedback from users on this one :) is audio scew on any better than the way mame2003+ is doing it
-
@markwkidd 1. also includes changes to game speed. but yes, unless you turn off v sync and skew i guess (then u get tearing)
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
mark try both see if one is any better than the other its all theory atm
how? i’ve tested it quite a bit grant.
-
@dankcushions what audo scew setting should i put in for 2003 i just want to se if its smoother video wise if its better we will just use that way not a debate here just want the best way implemented im 0n 0.05 just now. I changed it to 0.03 restarted retroatch game reprots the right fps but is playing too fast. Well i had to restart it does seem to settle speed wise but i see no real difference in this and the original mame2003+ . I hope we can get some feebakc on this from users and see if they have a preference
-
@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:
Judder/held drames/dropped frames in the video
I've updated my draft here: https://github.com/libretro/mame2003-libretro/wiki/Troubleshooting-RetroArch-Audio-Skew-Issues
Do with it what you will, folks.
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions what audo scew setting should i put in for 2003 i just want to se if its smoother video wise if its better we will just use that way not a debate here just want the best way implemented im 0n 0.05 just now
assuming something 57.4fps
0.01. this will effectively disable skew functionality so it will be less smooth, right speed, right pitch.
the default 0.05 will skew it.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
pi has vsync and it’s on by default. yes, retroarch will always send 60 fps to your 60 fps display, but (with the skew feature) it will speed up a 57.4 fps game to true 60, rather than hold ~3 frames every second to for 2 frames, to judder it to an effective 57.4 speed.
If the FPS are being delivered slower or faster than the monitor refresh rate then tearing can occur. It's really about being out of sync. If they are delivered slower vsync will try to match the FPS to a multiple of the monitor say 30, 60 or 120. If faster then vsync isn't doing much usually. I believe what you're saying but I think this could be better explained or use different words possibly? Slowing down the FPS makes sense but speeding up FPS isn't really what vsync does and seems more like a core/code thing.
Maybe it doesn't matter but once you go down the road of using words "loosely" when they don't seem to be correct then it becomes the gospel and everyone starts using incorrect terminology. Such as vsync is speeding up FPS when really that just sounds silly as vsync can't make your hardware run faster but tries to sync the two. Doing some fancy coding can work magic for your FPS it seems though.
I see a lot of threads of people writing buffers for vsync on the Pi or messing with timings in scripts but where are you getting your Pi vsync information from? Do you have some links by chance?
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions what audo scew setting should i put in for 2003 i just want to se if its smoother video wise if its better we will just use that way not a debate here just want the best way implemented im 0n 0.05 just now
assuming something 57.4fps
0.01. this will effectively disable skew functionality so it will be less smooth, right speed, right pitch.
the default 0.05 will skew it.
ok will retest with 0.01 0.03 seemed to work after a restart
-
@riverstorm said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
pi has vsync and it’s on by default. yes, retroarch will always send 60 fps to your 60 fps display, but (with the skew feature) it will speed up a 57.4 fps game to true 60, rather than hold ~3 frames every second to for 2 frames, to judder it to an effective 57.4 speed.
If the FPS are being delivered slower or faster than the monitor refresh rate then tearing can occur. It's really about being out of sync. If they are delivered slower vsync will try to match the FPS to a multiple of the monitor say 30, 60 or 120. If faster then vsync isn't doing much usually. I believe what you're saying but I think this could be better explained or use different words possibly? Slowing down the FPS makes sense but speeding up FPS isn't really what vsync does and seems more like a core/code thing.
right - this is what audio skew does. it changes the game + audio speeds to match the vsync fps, within the skew threshold. please see the new wiki page.
-
@grant2258 0.03 will work also. it’s a simple calculation - it’s the limit of the change the skew will do. 60/57.4 = 1.045. therefor any skew from 0.04 and below will mean a 57.4 game will not skew.
-
@dankcushions said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@grant2258 0.03 will work also. it’s a simple calculation - it’s the limit of the change the skew will do. 60/57.4 = 1.045. therefor any skew from 0.04 and below will mean a 57.4 game will not skew.
ok that makes sense what ive found is visually i dont see a difference when the audio screw is set and mame2003+ way of doing it.
They have the same effect as each other. What i can do is put both options in the core i personally cant see any difference could just be me though. how far can we go with the scew @dankcushions i just want to check framerates and such make sure skew can cover them all.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.