Mesen Core


Should it be of interest to anyone, I’ve finally gotten around to converting the Nestopia hack for Castlevania 1 (that was released last year by kya over on to the HD pack format used by Mesen - so you can now play this with the Mesen core.

More info and link here:


Ah, that’s awesome! Way better than needing a hacked emu.


Simply bad ass, I really hope the HDNES pack scene catches on like the MSU stuff for the SNES.


Gall Force on Famicom disk system is constantly inserting/ejecting disks causing the game to pause.
Putting auto-insert to OFF gets around the problem, but just wanting to report it for science.


Thanks - I’ll take a look when I get the chance. Can’t promise I can fix it, though, since the auto-insert feature is essentially a hack that tries to predict what the game is trying to do. Some games might be hard to support if they behave differently from all the others.


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!


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.


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)


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.


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:

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:

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?


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.


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.


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…


@rafan I couldn’t reproduce that behavior on my machine (Windows 7 32-bit, RetroArch 1.7.3 Git version a5b877b142), audio works without issues. My Windows 10 64-bit is currently broken so I can do tests on it. I tested this with default RetroArch settings (apart from audio driver) and then changed latency to 10 ms and after that tried driver in shared-mode, in all cases audio was fine. Since I’m little busy these days I didn’t try different games, only the Super Mario 3.

Regarding size of the audio blocks, WASAPI have issues with small data transfers and, as I remember, this is just a nature of the driver itself (OS driver, not the RetroArch-s). With that in mind I wouldn’t be surprised if increasing that value will solve the issue. If Mesen core sends data 1800 times per second, as @Sour said, this would mean that those blocks are 26 frames long (at 48 KHz), and that is way to short for the Wasapi driver.

If you didn’t play around with audio settings you can try that. As I recall, I did added some workarounds to the driver and exposed them to the users trough settings. Note that few settings are considered advanced so they are not visible by default.


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.


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:


@rafan another thing worth mentioning is that some audio adapters may have issues with WASAPI. I remember that one user reported that one of his audio adapters didn’t work correctly with WASAPI (regardless of app used). Just another thing to keep in mind.


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.


@Sour based on my experience during development of the WASAPI driver, it’s not just the buffer size that matters, it’s also important where/when is buffering done. I noticed that all RetroArch’s audio drivers, that I tried, have problems (some more than others) when core sends audio in small chunks, and I can only speculate why since I’m not familiar enough with RetroArch’s code which executes before data reaches driver. WASAPI driver does buffering but that helps only so much.

Also, I’ve looked at Mesen Libretro source code (audio data dispatch part only) and there is one thing that is worth trying since it would require only few lines of code to be changed. Core currently uses ‘retro_audio_sample_t’ function which sends one audio frame at a time. Function ‘retro_audio_sample_batch_t’ should “fit” better since it uses same data format as core’s final audio buffer, and can transfer audio frames for entire video frame period in one call.


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