Mesen Core

Libretro Cores
#108

Decided to give the core a go and I really like it so far!

The only thing that didn’t work for some reason were the Famicom 2nd controller Microphone button no matter what I configured it too.

This works in standalone Mesen with no problems at all so either this option is broken or I have missed some vital setting or something.

Input is set to 2 and I see the option under Input 2 but not even keyboard buttons seems to work nor my Famicom controller buttons.

I can configure this option and set it with either keyboard or controller just fine but once I go live to kill the Pols voices in Zelda, dungeon 5 it doesn’t work.

Thanks in advance!

#109

Seems like something is very wrong here as I still can’t get the Famicom Microphone Button to work at all.

User Input 2, L3 Button becomes Famicom Microphone Button when Mesen starts which is understandable.

I have configured this with keyboard key C and the actual L3 Button on my DualShock 2 PlayStation 2 controller.

No matter how many times I press C or L3, nothing happens and no Pols Voices gets killed in Zelda.

This function works perfectly fine in the Nestopia core and the standalone version of Mesen.

I’m playing the Japanese Famicom Disk System version of Zelda no Densetsu - The Hyrule Fantasy so killing Pols Voices with Microphone Button should be 100% possible.

#110

Thanks - I’ll take a look when I get the chance. As far as the code itself goes, it seems to be hooked up properly. Keep in mind the bindings have it set as a P2 button, so you need to map player’s 2 L3 key, not player 1’s. This isn’t ideal though, I should probably move that particular binding to P1 (even though the microphone itself is on P2’s controller)

#111

Thanks for your reply!

I have indeed mapped the Player 2 L3 button (Famicom Microphone button) properly, there’s no mistake there.

Nestopia have this on Player 1’s mappings instead of Player 2’s, so moving it to Player 1 might actually be a good idea despite the Microphone being on Player 2’s controller on the Famicom.

When I set keyboard key C to the Famicom Microphone button in Nestopia it doesn’t take more than one or two presses for the Pols Voices to be killed.

When I set the same keyboard key in Mesen, nothing happens but I have more free time today so I’m going to try this out some more just in case I have totally missed something.

#112

Hi Sour,

Thanks for your great Mesen core :grinning:

There is one minor issue which I hope you could look into.

The Wasapi audio driver in Retroarch is able to get very low audio latency, but unfortunately when using the Wasapi audio driver with Mesen there are tiny glitches every now and then.

I have no issues when using the XAudio driver on the other hand, it works perfect with Mesen, but since the Wasapi driver should be capable of much lower latency audio and also with less cpu load (it’s event driven), I was rather eager to try it with the Mesen core.

Some background:

It’s a known issue that the Retroarch Wasapi driver is not compatible with all cores. It can be read here in the development thread: https://github.com/libretro/RetroArch/issues/2771

For example the Mednafen PCE fast core works perfect with the Wasapi driver, giving audio latency as low as 10ms without issues. On the other hand when using the Wasapi driver with for example the bsnes cores there are glitches/issues. So it’s a kind of hit and miss per core.

In the above mentioned thread Casdevel (who developed the driver) commented on what he thinks is one of the possible causes of these incompatibility issues: https://github.com/libretro/RetroArch/issues/2771#issuecomment-302953437

Most important stat’s are average input chunk lengths and average blocking times. If input data duration is shorter than device period (reported after client initialization) and intermediate buffer is off, there probably will be issues. The same goes for blocking periods that are longer than device period. Unfortunately audio driver can’t influence either of those two things.

I tested bsnes-mercury-balanced core and data chunks are too small (below 100 frames) while device period is 480 frames (in shared-mode on my machine). This is why WASAPI driver have problems with this core.

I’m not sure whether anything can be done on the Mesen libretro core side, but possibly you can look into it?

#113

I’m not too familiar with WASAPI, but libretro-wise, I’m not sure there’s anything inherently wrong with what the Mesen core does at the moment? It sends audio samples to Retroarch in extremely small packages, roughly 1800 times a second - so it seems unlikely that the issue would be due to the core waits too long to send samples, etc.

Someone from the Retroarch team would probably know better than me whether or not there’s anything I can change on my end to improve this.

#114

Thanks for looking at it :grinning:

There’s one quote from casdevel that stayed with me:

Which made me think it’s the block size in which the core generates the audio that is of influence whether or not the wasapi low latency works without issues.

Maybe you already tried it, but could it make sense to create a test version where the audio sample packet size can be configured (possible via a core option or something?) such that we can find out whether that has any significant impact on how well the wasapi driver works?

Other than that I think you’re right that probably one of the libretro devs or casdevel himself would need to give their view.

#115

i haven’t tested wasapi in a while and back then it has problem on some cores but im sure @Sour and @casdevel together can make something happen…

#117

Hi Sour,

Congrats on your core, is awesome. The only problem I find is, the lightgn crosshair is not showing up. It moves, and you can fire, but you never know where are you aiming at.

#118

Hi casdevel,

Thanks for commenting.

I’ve tried all the various options, including the advanced ones ones with intermediate buffer size settings etc. But the glitches can only be made to appear less frequent. I have to set the intermediate buffer size settings to 1024, use wasapi shared, and then it’s the least apparent, a small glitch only appears every few seconds. The games I’ve tested with are donkey kong, mario brothers and akumajou densetsu, on all three the issue appears.

I’m listening on headphones by the way, as I’ve experienced this makes any glitches / pops stand out easier.

@sour : Could you possibly create a version where the blocksize is configurable, as per casdevel’s comment above the fix may be to have a blocksize (far) larger than 26 frames. For me this is about the only solution that I really would love to experiment with, as it might also provide an insight in why some other libretro cores have issues with the Wasapi driver too. Hope you have some time and interest to look at this.

Thanks again for a great core, enjoying the hell out of it :grinning:

#120

It does send tiny blocks of samples, but shouldn’t it be RetroArch’s job to use these samples in whatever most effective way is needed for the sound API? e.g there is nothing actually preventing RetroArch from buffering these and sending them in a bigger block, if that is what WASAPI needs to work properly?

I could make a build with a larger buffer (letting the user select this is harder since this is a constant, at the moment), but it still feels like this should be something RetroArch itself manages, rather than each individual core (assuming this is even the problem in the first place, I have not even tested WASAPI on my end yet)

@cubatilles Thanks, I was not aware this was even a feature at all as I’ve only used it in situations where RetroArch was showing my mouse cursor - I’ll have to see what other cores do for this.

1 Like
#122

Are there any plans to implement soft patching support in the Mesen core?

#123

@casdevel Yes, you’re right on that - should have used that function instead. When I read the documentation originally I had assumed this was meant for cores that called it a single time per frame, so I used the other function instead. Slightly related, I noticed you forked and changed this on your end (to test if it helps, I imagine), but saw that you forked libretro/Mesen. You should probably fork SourMesen/Mesen, since Mesen is meant to be an upstream core (I still don’t understand why libretro/Mesen exists, and why the Android builds point to it).

@butanebob I won’t say outright “no”, but the last time I checked, I got the impression that this would involve a lot more changes than I feel is worth (I don’t want to have to rewrite a ton of filesystem-related code that’s been in use & tested for a while, just for the libretro core). So it may happen eventually, but probably not soon.

#125

Since we support a bunch of platforms that upstream authors don’t usually care much/any about (weird consoles, super-old Windows, DOS, etc), we usually use shallow forks for the buildbot so we can look after those obscure targets without bothering upstream too much. If you’d rather us point at your repo, though, we can certainly make it happen.

#126

That fork is currently only used for the Android builds (and I don’t know why, since I had originally merged the PR for android support when it was done), and afaik only contains one minor makefile change dating a couple of months ago.

IMO, the existence of the libretro/Mesen repo just makes it harder for everyone involved and causes confusion as to where to make changes - e.g even if casdevel’s PR is merged to that repo, it will only affect the android core, since all the other build targets are using the main repo. And in the end, this just ends up preventing me from fixing/improving the Android builds the buildbot produces (e.g the libretro/Mesen repo doesn’t have the raw palette option I added last month, and is missing a number of emulation fixes, too).

Obviously, if you guys were to try to heavily rework the code to make it build in e.g C++98, then that would definitely warrant a fork, but at the moment, it just seems to be unused, and slowly becoming out-of-date vs upstream.

@casdevel If you want to try increasing the size of the packets of samples Mesen sends, you can try increasing this constant: https://github.com/SourMesen/Mesen/blob/master/Core/SoundMixer.h#L25 e.g setting it to 10000 will send samples 3x per frame instead of 30x. If you set it over 50000, you’ll probably want to increase “MaxSamplesPerFrame” a few lines below, otherwise it might end up crashing. I still want to give WASAPI a shot on my end when I get a chance, but haven’t had the time to do so yet.

#127

Oh, just being used for Android? Yeah, we should see about getting rid of that, then. I’ll see what I can do.

1 Like
#128

FYI, someone else requested this on GitHub just now, so I took another look. Turns out enabling softpatching support was actually very easy, whoops!

The next build the buildbot makes should have softpatching available - let me know if there are issues with it.

3 Likes
#129

Hi, I’d like to request a Mesen core for Retroarch Wii U if possible and thank you.

#130

Awesome thank you mate

#131

Why? you have nestopia and mesen is not likely gonna be fullspeed on WiiU. It’s very accurate, it’s very nice, it’s just not suited to slower platforms.

I could try to get it to build but IIRC it requires C++11 not sure we have that available on WiiU.