mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
yea need to get that magic number to test it out. The think that confusing though is games like mk and stonebal (i just found out about this one) are working ok on mame2003 without the audio scew it just seems the 57 fps are getting chomped by this. On our end 2003 what we are doing is only playing 57.4 worth of sample time its the audio timing of 48k taking the 60fps time that pushing the framerate up with the audio scew as is. I originally thought the timing changes the samplerate it doesnt. The only way you can change the sample rate is with ra settings as far as i can tell
-
OK I will locate the libretro forum thread about the audio skew and see if RetroArch is amenable to a PR lowering the default. If not maybe it's worth a note somewhere in the mame2003-plus docs.
On this theme, in a general way:
@dankcushions I would also really like to help create a PR to add the "RetroPie udev ordering patch" to RetroArch as an option in the cfg. I know there is an issue about it that you participated in but I think that's could be another example where a PR is the best way to communicate with RetroArch.Unfortunately I haven't yet added a RetroArch cfg option so I'll need to learn.
-
@markwkidd we dont need an audio screw for mame2003+ only 2003 needs its atm setting it shouldnt effect us at all we are within the ra timing system not fooling anything just playing the sames sample frames per second to what it shoud be can add both options as a core setting if you like though. Midway will have to be the new way 30fps is too much for audio scew as far as im aware
-
@grant2258 and @dankcushions can you take a look at the post James-F makes here: https://forums.libretro.com/t/default-audio-rate-control-delta-value-0-005-is-bad-and-quite-audible/15129/36
That is the key message -- that this audio_rate_control_delta is only used when there the frontend does not have accurate refresh rate about the user's monitor or when then monitor's refresh rate is varying wildly. There are other posts on this theme here and there in the thread including some from Dwedit that might be relevant.
James-F describes a procedure to manually set the refresh rate. Is anyone willing to try this?
If I understand James-F, then that maximum skew amount should never be necessary because the feature is more intended to adjust between 60fps and the framerate/refresh rate supported by the user's monitor than it is meant to be adjusting between the framerate of the emulated game and 60fps.
If the refresh rate is not getting set automatically accurately by something in the RetroArch-Rasbian-Hardware monitor path then the audio winds up getting compromise when the total difference reaches a certain point.
So if that's true, the solution really isn't lowering the maximum skew which would fix the audio but introduce video problems, but do a better job to set the refresh rate for the user's system. Anyway this is yet another area I'm not familiar with.
Hmm.
-
@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:
That is the key message -- that this audio_rate_control_delta
different setting. the one that affects us here is
audio_max_timing_skewit's a very simple setting and you can see the effects very easily. i encourage you to test with it.
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
we are within the ra timing system not fooling anything
if a 57.4fps game is not reporting 57.4fps to timing.fps, it's fooling the system. if it's reporting it correctly, the default audio skew will skew a 57.4fps game to 60fps, every time.
-
@dankcushions im not doing that teh fps is set to 60 the audio is changeing the timing because it takes 60fps to play a 48k sample. Im just playing the correct samples per frame
-
Thanks hehe. I'll tell you -- it blows my mind when people post in here and they know that such and such game's audio is off. Or that a sprite is screwed up.
On one hand: I have a stupidly large record collection and a pretty good recall of music that's in it. I would know instantly if there were problems like this with my music.
But I only play a handful of video games personally. I don't know what they are supposed to sound like! I can certainly tweak settings to some extremes and see what happens though.
-
@grant2258 said in mame2003-plus: 250 new games, new input system, new features, new bugs:
@dankcushions im not doing that teh fps is set to 60 the audio is changeing the timing because it takes 60fps to play a 48k sample. Im just playing the correct samples per frame
then you need to change your sample segment for a 57.4fps frame, i believe. @barbudreadmon was looking into this in fbalpha. not sure how far they got.
-
@dankcushions fba had problems i sent a message to him he did fix it all i am doing is sample segment for a 57.4fps frame
-
@markwkidd said in mame2003-plus: 250 new games, new input system, new features, new bugs:
Thanks hehe. I'll tell you -- it blows my mind when people post in here and they know that such and such game's audio is off. Or that a sprite is screwed up.
On one hand: I have a stupidly large record collection and a pretty good recall of music that's in it. I would know instantly if there were problems like this with my music.
But I only play a handful of video games personally. I don't know what they are supposed to sound like! I can certainly tweak settings to some extremes and see what happens though.
personally i like some of my records at the wrong speed ;) with the skew, i found it easiest to test with robocop (57.4fps) and have a savestate in the level, and hum the music. then reload with a 0.01 skew set, and you can hear the pitch of the music change very slightly.
personally i prefer the slightly wrong speed/pitch and no juddering from a 57.4fps, but i'm at the stage now where i'd sooner just have it at a lower threshold so we don't have to talk about it ever again :P
-
(@dankcushions I'm reading your history of work on github about this skew setting)
Edit for more content: My approach is often to create a doc -- in some cases the doc explains why no action was taken and gives the users some ideas on how to proceed on their own. I'm trying to figure out if that's better in this case or whether it's better to submit a PR to RetroArch.
In general, I've been told that cores shouldn't be coded "to" RetroArch. I think we're all agreeing for now that there's nothing going on in mame2003/plus here so we don't want to code some workaround.
Beyond that I'm leaning towards a very brief write-up on
audio_max_timing_skewthat summarizes what we've just covered here with some of your discussion with hunterk on github. -
On one hand: I have a stupidly large record collection and a pretty good recall of music that's in it. I would know instantly if there were problems like this with my music.
But I only play a handful of video games personally. I don't know what they are supposed to sound like! I can certainly tweak settings to some extremes and see what happens though.
I have to agree. I'm impressed how people pick up the subtle differences and even games I commonly played I miss too. I didn't notice the ga2 shadows until someone else pointed it out. Nostalgia trumps I suppose. Any music genre from the 70s or 80s though I can tell you album, artist, track and if it's been remastered or altered in any way. Except boy bands, I had to draw the line somewhere.
@markwkidd - Is there'a a mame2003_plus Wiki somewhere that you're adding this information or mainly posting on the Github main page?
-
@markwkidd i think that's a good approach.
it was a frustrating subject for me as windale/zappautopia (same person) had blinkers on with it - all they cared about that the sound was wrong. the fact that this was a retroarch feature, working as designed, and could be configured to suit them did not seem to get any traction.
anyway, as far as i'm aware audio_timing_skew is relevant to mame2003 vanilla only, as plus reports everything below 60 as 60: https://github.com/libretro/mame2003-plus-libretro/blob/6ab5d92c00a02b1ea1fd9c1dc8880e4a36811089/src/mame2003/mame2003.c#L565 - this will bypass timing skew - retroarch will presume your game is a 60fps game that is dropping frames, and not a 57.4 fps game that should (according to the default settings) be skewed to 60.
so, any testing you do would have to be with mame2003 vanilla.
-
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!
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.