SameBoy
SameBoy copied to clipboard
LIJI32
[Regression] [Libretro] Link's Awakening DX Menu Sound Crackle
In the latest libretro build, there is a sort of stuttery crackle in the BGM whenever you open the menu (Start). It happens when transitioning through some of the menus too, like from title screen to save select. It doesn't happen in an older build I have from Jan 19th.
Just to update, when the libretro mirror updated to 3ee2c648996c6eb3a2fb32113b984215f54b7b02 I checked the buildbot build and still experience this. Haven't noticed any other crackling in other places in LADX or other games, so I don't think it's performance related.
Testing a bit more, I found a little crackle when entering and leaving the pause menu in Kirby's Dream Land 2 as well that's in the new build but not the January one. It's more subtle than in LADX. Seems like it's mostly fade style screen transitions where it happens. But it doesn't happen when opening LADX's map or any of the menus in Oracle of Seasons.
Great findings @Awakened0
I hear what you hear too but I'm not sure if Gambatte or bgb suffers from this as well? Never really thought of it much when I played the game on those but in SameBoy it's definitely more apparent.
Are you referring to the few pops that can be heard when you open the menu in certain areas, and that crackling sound you get when the music fades out? If so, these are not bugs – these can be heard when you play the game on actual hardware. If that's not what you mean, can you please attach an audio recording affected by this bug?
This doesn't sound like the usual GB pops to me. Comparing the older core with the latest one, it sounds like the BGM transitions have a sort of stuttery crackle, whereas they're smooth in the old one. Here's a recording, January core first, latest core from the buildbot second:
Do you have actual commit hashes of the versions compared? The only related diff between those dates is in the buffer copy function, and it doesn't explain many of the differences I see between the recordings.
Since I suspect the audio buffer copying code, and I've wanted to replace it for quite a while, I rewrote it and redesigned its API, and updated the relevant frontends (libretro wrapper, Cocoa, SDL). Specifically on the libretro port, it leaves most of the work to RetroArch now, which should improve quality and latency. Can you check if anything improved after last commit?
I'm extremely confused, the APU related differences between those two revisions are:
- The buffer copying function
- AGB mixing emulation (I assume you're testing on CGB mode and not AGB?)
- A few optimization hints for the compiler.
If it's not 1, I'm not sure what could have caused it. Since it won't reproduce on my machine, maybe you can try and git bisect it so I can know which commit changed it?
I was thinking about doing that, but I can't figure out how to checkout an old commit and also apply the libretro buildbot patch to get it built. Normally I just copy the prebuilt bootroms and makefile from the libretro buildbot branch and build using an msys2 environment.
I have no idea how to install dependencies in that to compile directly from this repo. Tried adding BOOTROMS_DIR=./prebuilt with the prebuilt folder under msys64/home/
What error are you getting? With BOOTROMS_DIR defined the only unusual requirement for compilation on Windows should be hexdump.
@Awakened0 Some x64 builds. Can't test myself now. https://github.com/LIJI32/SameBoy/commit/9d0aadb83fa0d63fb6810f05ff6089686cf82db4 https://github.com/LIJI32/SameBoy/commit/b3939e8fdcec9882fc57a4e4fbe3722860c3d1ee https://github.com/LIJI32/SameBoy/commit/b6e92dc8a74c850df3c5af49310e6c018d6c6707 https://github.com/LIJI32/SameBoy/commit/5ead9d49f4eac01e2c58de5ac0efe5195358db6b
@funbars https://github.com/LIJI32/SameBoy/commit/9d0aadb83fa0d63fb6810f05ff6089686cf82db4 - Bad https://github.com/LIJI32/SameBoy/commit/b3939e8fdcec9882fc57a4e4fbe3722860c3d1ee - Bad https://github.com/LIJI32/SameBoy/commit/b6e92dc8a74c850df3c5af49310e6c018d6c6707 - Bad https://github.com/LIJI32/SameBoy/commit/5ead9d49f4eac01e2c58de5ac0efe5195358db6b - Good
@LIJI32 Same error as if I hadn't defined the bootroms dir. I tried a bunch of relative paths, but I'm not sure exactly which folder is supposed to be root (home, sameboy, libretro, ?). And I was just using this dir from the libretro repo: https://github.com/libretro/SameBoy/tree/buildbot/BootROMs/prebuilt
@Awakened0 Great! Last ones https://github.com/LIJI32/SameBoy/commit/9d0aadb83fa0d63fb6810f05ff6089686cf82db4 - bad https://github.com/LIJI32/SameBoy/commit/42ef41182d68dfeafe26838d3a13c91eb52bd07b https://github.com/LIJI32/SameBoy/commit/42ef41182d68dfeafe26838d3a13c91eb52bd07b https://github.com/LIJI32/SameBoy/commit/dde06e7cae094859d7e0501bb824fe1e04379b61 https://github.com/LIJI32/SameBoy/commit/dde06e7cae094859d7e0501bb824fe1e04379b61 https://github.com/LIJI32/SameBoy/commit/5ead9d49f4eac01e2c58de5ac0efe5195358db6b - good
I think I see what's going on here. The Game Boy, being able to turn its LCD screen off, does not actually guarantee a stable 59.7 FPS. This thing happens when you open the menu and close it, for example. If I understand correctly, the libretro API does not allow a non constant FPS, so in such cases SameBoy reports a frame that is shorter than usual, which has, as expected, a fewer number of samples. RetroArch simply takes this frame's length, stretches it to the usual size together with the audio, plays the two together. The change that caused this issue slightly altered how specific cases of "irregular" frames are reported to the frontend. In the Cocoa and SDL frontend the video and audio aren't coupled at all which is why I couldn't reproduce it. Now, this effect can easily be mitigated by making the libretro frontend "mimic" the behavior before that change, but this still won't be a perfect/correct solution without proper variable FPS in libretro/RetroArch. Also, is it possible to make RetroArch sync to audio instead of video? This should fix the problem completely.
Hmm, but I'm using "Sync to Exact Content Framerate" under Settings, Throttle with a Gsync display. Thought that would mitigate this sort of issue. The description label under it says "No deviation from core requested timing". I think with that enabled it syncs to audio instead of video, but @Tatsuya79 would know more about it.
"Exact sync" just follows info->timing.fps that the core sends. That's pretty basic.
I have constant crackling when I use SGB1 while SGB2 is OK if that can help to figure the issue. For popping when bringing up the menu, I noticed that activating the high pass filter got rid of that (while the core is active, not at start).
Yup, following info->timing.fps is exactly what shouldn't happen in this case, as the frame rate momentarily changes to something a higher, so this option is better off for SameBoy. This also explains crackling in SGB1, as SGB1 runs at a different frame rate yet I didn't updated info->timing.fps accordingly. SGB2 (for the Game Boy perspective, I don't emulate the SFC's frame rate) runs at the same rate so it's not affected.
Also, the high pass filter should really ever be disabled, at the very least it should be set to "Preserve Waveforms", as otherwise the audio will always have DC offset, which not only triggers pops on FPS drops, might also interfere audio playing from other applications. I should probably make it the default setting in the core.
The last commit should make audio on libretro as good as it was before the regression on GB, CGB, GBA and SGB2. I still have to fix the SGB issue but that's a different problem. It's not a proper solution, but it should be equivalent to Gambatte,
Yep, tested LADX and a few other games and everything sounds good. Thanks everyone!
I'm having this exact same issue on RetroArch. On Link's Awakening, while opening the start menu, or when transitioning between the startup cutscene -> startscreen -> savefile select, I always get very slight crackling on the audio.
I have tested this on Windows and on Manjaro. Both exhibit the same problem as described on the original post. This does not happen on Gambatte.
Is it related to this? https://github.com/LIJI32/SameBoy/blob/18126994ff35c880677d51728aa5f995219592e1/Core/display.c#L1805
I only hear what should be the hardware accurate pops. Using a Win64 build I made from this repo from commit 2a034d4ebe79613b88921d35396f8228b708c671
@Awakened0 Are the pops reproducible every time? Does Gambatte have these same pops? What I hear is a bit irregular, and is not present at all in other GB cores.
It is specially noticeable in the transition between the BIOS and the cutscene, and between the cutscene and the start screen.
EDIT: @Awakened0 I also built that specific commit and I got the same results.
@Awakened0 Are the pops reproducible every time? Does Gambatte have these same pops? What I hear is a bit irregular, and is not present at all in other GB cores.
It's pretty consistent on my end. Here's what it sounds like for me:
https://user-images.githubusercontent.com/4565863/165411756-abd86434-f74c-4151-9dc3-0b29acb43a8e.mp4
It is specially noticeable in the transition between the BIOS and the cutscene, and between the cutscene and the start screen.
Looking at my opening post in this thread, that could be a regression. There's definitely a little sound stutter in those transitions. I don't keep old builds of the core around anymore to compare though.
It's pretty consistent on my end. Here's what it sounds like for me:
Yeah, that's exactly how it sounds on my end too. That roughness before the waves appear and before the start screen appears is what I'm talking about.
I've checked on the GearBoy, TGB Dual, mGBA and Gambatte cores, and none of them have this behavior. SameBoy is the only one. If this is more accurate, I'm all for it. But I want to make sure that is how real hardware sounded and if this needs to be fixed or not.
Getting the same audio behavior in the Libretro buildbot version which is built from their downstream repo. That repo hasn't been updated since December, so if this is a regression it's older than that.