Closed ghost closed 6 years ago
@LIJI32
To answer your first question, YES I can indeed reproduce the pops and click noises during playing Zelda - Link's Awakening on the standalone version of SameBoy 0.10 with "Accurate", "Preserve Waveform" and "None (Keep DC Offset)" alternatives.
To answer your second question, I can only say that I have a hard time doing that because I don't know how.
RetroArch won't let me record anything no matter what I do and the standalone version doesn't have any options for recording.
I have attached a physical microphone to the mic jacket on my computer and the microphone is hanging behind the TV speaker but I doubt the sound would be good IF I just knew how to record things because Windows 10 Enterprise 2016 LTSB doesn't really offer much when it comes to record audio.
What should I do here??
@LIJI32
OK I have now made a recording of the pop and click noise issue via Audacity and saved it as .wav It's around 20 seconds and you can clearly hear what's wrong.
It's taken straight off RetroArch with "Accurate" High-Pass and what you hear in that file is what I hear in the standalone version of SameBoy too.
Thanks in advance!
Nice. I'll have a look (and a listen) once I'm home.
Oh wow that sounds bad. I seem to be able to reproduce it on the Cocoa port as well. I'll try and see what's the source of it.
Turns out this is caused by an incorrect emulation of an APU glitch. Disabling emulation of this glitch completely fixes this issue. Now I just need to see how to emulate this correctly.
@LIJI32
I wish you all the best with this issue and I really looking forward to your solution to this audio problem.
If there is anything else you need just ask.
Happy new year!
I've created a test ROM to test this issue and it appear that my behavior is actually correct. The same issue does actually happen on Gambatte as well, but it is significantly less noticeable for some reason. (I had to mute channels 2-4 to actually hear it).
That's really interesting @LIJI32 , have you gotten any chance to test your ROM in bgb as well?
bgb and Gambatte is pretty much on par when it comes to accuracy I believe but that may only apply to CPU and not APU.
What do you plan to do next and what can be done?
I didn't reproduce the bug with the test ROM, I did it with the original Link's Awakening ROM – both Gambatte and BGB fail virtually all of my APU test ROMs because they do not emulate the PCMXX registers. I did try to test on BGB though, but because BGB performs non-optional high-pass and low-pass filters I wasn't able to determine if BGB is affected or not.
Now that I know my emulation of that specific APU glitch is probably correct, I need to determine what the game does when it causes these pops, and how SameBoy emulates what it does in way to makes pops more noticeable than on real hardware or on Gambatte.
I appreciate all the time and effort you are putting on this @LIJI32 and it's real interesting to read all this!
I know it's kinda wrong of me to say that it's good to hear that Gambatte and bgb is failing all of your APU test roms but I think it's great to finally know that they're not as accurate when it comes to sound as I originally expected and hopefully good things will come out from this.
It's also great to know that your emulation of that specific APU glitch is probably correct because that means you can probably solve this for good.
How do you determine/figure out what the game does when it causes these pops? I'm rather curious of all this.
It's not that Gambatte and BGB are not accurate when it comes to APU emulation (In fact, the test portions that BGB does pass show it surprisingly accurately emulates several undocumented APU behaviors) – the thing is that Gambatte and BGB's accuracy can't be tested by my ROMs because they lack emulation of the PCM12 and PCM34 registers, which is required for my tests.
The next thing I'll probably do is to log the writes the game makes to APU registers with precise timing, before and after a sound pop occurs, and see:
I an flowing the discussion and wonder what you think of the accuracy of higan?
(https://byuu.org/
)
@LIJI32 Well that makes perfect sense when you put it that way, of course they can't work if they lack PCM12 and PCM34 registers (I'm an idiot) I didn't thought of that actually when I wrote my previous comment but thanks for explaining all this.
I look forward to hear your results from your logs!
@cyberic99 Well if you mean higan as in the SNES core it's famous for then all I can say that it's literally a SNES in it's purest software form and you won't find anything like it. If accuracy is all you want when it comes to SNES then don't bother with anything else.
If you however refer to higan and it's GB core I can't really speak much of it as I haven't tested it out but I know former bsnes used to have Gambatte for SGB emulation.
I would also like to point out that I think SameBoy for GB/GBC emulation and Mesen for NES/FC/FDS emulation is starting to get as good and accurate as higan with it's SNES core even though they're completely different systems. Basically if accuracy is what you want for GB/GBC and NES/FC/FDS emulation SameBoy and Mesen is what you want.
Turns out the emulation of the NRX2 write glitch is in fact not accurate in some cases (Although it is "accurate enough" to pass Blargg's APU tests). I'll have to write a better test ROM to figure out what's wrong (I'll probably do it this weekend).
Great to hear you have made progress @LIJI32
Looking forward to next update from you, keep up the good work!
@LIJI32 Nice commit!
I'm eagerly awaiting the Libretro buildbot to build the SameBoy core so I can test this out, I'm reporting back once I had a chance to test it, probably tomorrow if the core is built then.
The latest commits were merged into the libretro mirror, so I tested out the newest buildbot build. It seems less poppy in LADX, I think.
There's still this sort of "static" on certain high notes; particularly noticeable if you listen to "Ballad of the Wind Fish" in LADX. I wonder if it sounds smooth in Gambatte just because of some kind of audio filtering it does. Here's a comparison wav (first half is Gambatte, second Sameboy. Both running in RetroArch on Windows):
Forgot to mention I was using the accurate high pass filter setting in that recording. The "static" is there when setting it to off or remove dc offset too.
While the sound is 1000x better then before I have to agree with @Awakened0 here, I hear what he hears too and I also hear a small distorted sound when I pause/unpause the game to get to the item/quest item screen i Zelda - Link's Awakening.
Otherwise the sound is pretty much perfect.
EDIT:
There seems to be also a distorted sound when enter/leaving houses.
There seems to be also a distorted sound when enter/leaving houses.
I've noticed that in Gambatte too, but it's less pronounced there. It's harsher sounding in SameBoy.
It's probably due to the better filtering used in Gambatte, as I don't recall hearing this distortion on the Mac version (which renders audio at 96KHz, so these distortions are heavily reduced), but I'll have to check it to verify.
Raising Audio Output Rate (Hz) in RetroArch to 96000 which is equivalent to 96Khz didn't change anything, I still hear sound distortions pausing and enter/leaving houses.
Hi-pass filter is set to Accurate.
The libretro core of SameBoy itself is hardcoded to 44.1KHz AFAIK
OK, well that would explain why I didn't hear any difference. RetroArch is defaulted to 48000 as far as I know when it comes to Audio Output Rate (Hz).
I'm unable to reproduce this bug on my Mac even after reducing the sampling frequency to 44.1KHz. I suspect that the cause of this issue is RetroArch resampling 44.1KHz audio to 48KHz. Can any of you check if changing RetroArch's sample rate to 44.1KHz solves this issue?
I tried that and I get ear melting loud static that sounds nothing like the game audio :O
Mmm that sounds like either a bug in the SameBoy libretro frontend or RetroArch itself. Does it reproduce after changing the setting, quitting RetroArch, reopening it and then testing the game? Also, is there any API a core can use to get the user-set sample rate? Letting RetroArch resample the audio output when it can be directly rendered in the correct rate in the first place sounds like a bad idea.
I changed the setting in my retroarch.cfg before launching, just in case changing it in the menu while the game was running didn't work. Maybe @fr500 or another dev could help you with the API stuff.
That static bug doesn't reproduce on RetroArch for macOS, so I've managed to test it myself – when RetroArch's frequency matches SameBoy's it sounds just fine (and when it doesn't match, it doesn't). This can be easily solved if the core can know RetroArch's frequency.
Also, is there any API a core can use to get the user-set sample rate? Letting RetroArch resample the audio output when it can be directly rendered in the correct rate in the first place sounds like a bad idea.
@Themaister, would there be a benefit to exposing this on the frontend side?
@LIJI32 What's the status on this currently? And what frequency can we use in RetroArch to eliminate the static bug?
Configuring RetroArch to 44.1 KHz should fix this issue. For a proper fix I'll need help from the libretro guys as I'm not well familiar with its audio APIs.
@LIJI32 Thanks, changing Audio Output Rate (Hz) to 44100 and Latency to 57 seemed to have helped a bit but I can still hear the distorted sound faintly enter/leaving houses and pause/unpause.
Does Latency need to be something different then 57? I just used what bgb is defaulted to.
EDIT:
I think I can live with this, the faint distortion is tolerable with 44100 Audio Output Rate (Hz) and 57 Latency.
I also set Audio Resampler Quality to Highest, but I don't think that option matters.
Further testing between bgb and SameBoy shows that the specific distorted sound I mentioned is also present in bgb.
I don't think that there is more to do here, the sound and music in SameBoy is good and my initial issue is solved + changing Audio Output Rate (Hz) and Latency helped a bit too.
Not needing to change the sample rate to 44.1 would still be nice. 48KHz is the Retroarch default and the most common Windows default.
@Fergdog I see your point but as long as it works it's pretty much fine by my standards. We'll see if they manage to fix this at some point, 44.1 sounds good enough for my 32 year old ears.
44100 doesn't work on my machine though, or at least it's very buggy. It always starts as loud static noise, but sometimes I can get it to work if I switch to windowed mode. It forced my monitor to 60hz from 120 when going windowed from exclusive fullscreen too, which doesn't happen at 48000 (and that's the only option I changed). I tried setting my monitor to 60hz mode and setting swap interval to 1 before launching at 44100, but I still got static before switching to windowed mode. And sometimes switching to windowed mode doesn't completely fix the sound; I have to switch modes a few times, or sometimes bringing up the menu fixes it. It's bizarre.
The same thing happens with Mesen, so it must be a frontend issue.
Hmmm... I can't repro any of this other than some small pops every now and then. That said, I get no audio in sameboy if I run RA at 44100hz, that seems like a retroarch bug
Not sure if any of this is recent, recently there were some changes that mande the sinc resampler configurable.
Honestly I know very little about audio and I don't really hear anything bad atm...
Oh I hear a brrrr when entering houses in LADX, is that the issue at hand?
Some more insight, I get no audio at 44100 unless I raise latency a bit (was at 64 before). I still don't see any noticeable difference at 44100 vs 48000 though.
Setting my audio latency to 80 fixed the problems I was having with 44100. It doesn't really sound any different than 48000 to me either though; the "static" on high notes when Marin is singing in LADX (or the real GBC or GB BIOS sound) is still there. The door entering sound doesn't sound any less harsh as far as I can tell either.
Can you any of you reproduce these artifacts on the standalone version? I highly suspect this is caused by double resampling – SameBoy resamples the 2 MHz audio to 44.1 KHz, then RetroArch resamples that to whatever rate it uses (and if I understand correctly, it might be a bit a bit lower or higher then what is actually configured). When resampling from one sample rate to a very similar sample rate it is very likely to introduce such artifacts. A possible solution is to make the SameBoy core render at a very high rate (384KHz, for example. Due to how audio rendering works, it shouldn't make a noticeable performance difference) and let RetroArch handle downsampling (Which it does better than SameBoy anyway).
I did! I tested standalone on win 10, lots of popping but that's not relevant. The BRRR noise when entering houses still exists.
Yeah the pops in 0.10 are already fixed on master. I'll see what happens with the house noises, probably a core issue then.
I plugged my GBC into my desktop's mic port to record it and compare to the Gambatte and SameBoy cores. There's some line noise, so it's not as clean as I would like, but I think it sounds less "clicky" than the emulators. Gambatte's "clicks" near the end of the sound aren't as harsh as SameBoy's; could this be due to lack of a low pass filter? I do like the cleaner sound of SameBoy, but the "clicks" in high pitched notes like the BIOS sound bother me a bit. It might be nice to have a low pass option if that could smooth those out. Here's the wav (Hardware -> Gambatte -> SameBoy):
@fr500 I hear those BRRR noises, seems like an APU bug (My guess is that it's similar to the one I just fixed), I'll look into it. @Awakened0 Seems like a combination of sample rate mismatch and Gambatte's filters being better. I think I know how to fix it.
Just pushed a commit that redid the way the libretro port did audio. Audio is now sent to libretro at 384KHz, which is then resampled by RetroArch to whatever rate the user configured. This should greatly improve audio quality on the RetroArch port, which by this commit should sound even better than the standalone versions.
Awesome, I managed to compile it using msys2 (it takes like two seconds to build, wow) and that made the high notes in the BIOS and LADX smooth!
There are a couple things I noticed in Super Mario Land 2 I figured I'd note. On the load game screen, there's sort of a buzzing sound that plays in the background. I think it's barely there in Gambatte too; not sure if that's less noticeable there because of it's filtering or not. Also, Mario's swim sound effect likes to pop a lot in SameBoy. I don't hear that at all in Gambatte.
Glad this one is finally fixed. All of the other bugs are probably the same issue as that BRRR noise in LADX, which is caused by incorrectly emulated edge case of an APU glitch (See http://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware#Volume_Envelope). I found it while investigating the original bug described in this issue, but I haven't fixed it yet. I'll probably fix it later this week.
Hi @LIJI32 and thanks for a wonderful and accurate Game Boy emulator!
I have read both https://github.com/LIJI32/SameBoy/issues/8 and this commit https://github.com/LIJI32/SameBoy/commit/00623d4eea49eb3d8e1e69bf9774b691e9bcd349 and from what I could understand from it the sound quality should be fixed and the pops and clicks should be gone?
Maybe this is just something on my end but I don't know, I'm running SameBoy 0.10 (https://github.com/libretro/SameBoy/commit/f905c4d0f61b0ec4a1446de9d5dd8b7e3e853bae) on RetroArch 1.7.0 on Windows 10 Enterprise 2016 LTSB x64 and I can still hear frequent pops and clicks, real strong in Zelda - Link's Awakening.
All you have to do is to start a new game and the music in Mabe village should pop and click like crazy, and this is not happening on either bgb or Gambatte.
I have tried to change the Audio settings in RetroArch to make them similar like bgb for example but the music still pops and clicks.
However this isn't the case for all games I have, but of all 12, Link's Awakening is the worst sounding game.