Yep, recreated the weird bug you mentioned there. So, for now, MSU1 music only works again when you reload the ROM, just no 'snapshotting'.
Actually, it's more than that. Open MSU-1 game, take snapshot, close menu, continue playing. MSU-1 is gone as soon as you try to load any other track. I'm starting to suspect it's something screwy in the menu code, not in the MSU-1 code at all. Like calling an extra reset or something like that. Unfortunately, trying to debug this in Dolphin is rather painful.
Dayumn. By the way, maybe it's normal/expected, if you snapshot when inside a FMV and load that file, you return to a green screen (or sometimes a full crash, like in Super Road Blaster).
Last edited by niuus,
It's not normal, but those crashes are definitely related. Snapshot inside of a movie should work just fine (it's literally just the data seek pointer, along with VRAM and DMA state, both of which are standard parts of the system that must already be working or all snapshots would be broken). If anybody wants to help tracking this down, find where the snapshot functions are being called from the GUI, my guess is that something screwy is going on with the filesystem accesses related to creating the actual file for the snapshot, or something similar. Whatever it is, it happens when you click the snapshot button, so start there. The actual snapshot code itself works, something is unloading the files or clearing the "MSU Enabled" flag.
Sent from my m8wl using Tapatalk
Sent from my m8wl using Tapatalk
Wish there was custom shader support for these emulators but I can't complain too much about what we have now.
By the way, was that crashing bug ever fixed where you'd have your ROM's on the HDD and would load the app from the SDCard?
By the way, was that crashing bug ever fixed where you'd have your ROM's on the HDD and would load the app from the SDCard?
Hello! Surely many know this but I would like to comment on it in the hope that we will find a solution as a team.
I have used this emulator for many years and have a problem with the sound in many games, like "super mario rpg" and "chrono trigger" when the menu is opened, in other games it happens randomly as in "zelda a link to the Past "in dungeons more often, there is a distortion in sound when playing a time and more often with melodies that are constantly repeated.
In other games the problem is more frequent as in "terranigma" and "illusion of time".
A similar problem happens in the gameboy emulator "vbagx"
These games are examples, there are others where the problem is almost non-existent as in the series megaman x.
In "retroarch" this problem does not happen but the idea is that snes9x is as perfect as possible.
Many contributors who have participated before like Zopenko, Askot and Burnt Lasagna would be interested in this purpose and of course to the maximum responsible of this creation, tantric.
Many thanks for bringing the super nintendo to the wii.
I have used this emulator for many years and have a problem with the sound in many games, like "super mario rpg" and "chrono trigger" when the menu is opened, in other games it happens randomly as in "zelda a link to the Past "in dungeons more often, there is a distortion in sound when playing a time and more often with melodies that are constantly repeated.
In other games the problem is more frequent as in "terranigma" and "illusion of time".
A similar problem happens in the gameboy emulator "vbagx"
These games are examples, there are others where the problem is almost non-existent as in the series megaman x.
In "retroarch" this problem does not happen but the idea is that snes9x is as perfect as possible.
Many contributors who have participated before like Zopenko, Askot and Burnt Lasagna would be interested in this purpose and of course to the maximum responsible of this creation, tantric.
Many thanks for bringing the super nintendo to the wii.
I have found out that even by just pressing the Save / Load / Delete buttons (whether you use the functions or not) and going back to the game, will stop the next MSU-1 track from loading, reverting to normal spc music. In this case, it shouldn't be specifically tied to the snapshot function, but maybe the gui?
By the way @qwertymodo, would this change help pop/skip fixes on this side of the emulator?
Last edited by niuus,
That's essentially an independent re-implementation of this fix I already made and completely forgot about. Derp
The real issue was that when you request samples from the MSU-1 and it doesn't have any (song not playing, maybe other reasons I can't think of), it should still return the requested buffer size, padded with 0's. It was just returning the available samples, which in some cases was nothing at all. The rest of the changes in that commit ended up not being real issues after all, like increasing the counter variable sizes and shrinking the counter values by a factor of 10, since I was worried about potential counter overflows, but that really wasn't an issue. The relevant change in both is at line 357 or 425, depending on which version you're looking at.Bad:
Code:
else
{
MSU1.MSU1_STATUS &= ~(AudioPlaying | AudioRepeating);
return;
}Good:
Code:
else
{
MSU1.MSU1_STATUS &= ~(AudioPlaying | AudioRepeating);
partial_samples -= 3204;
*(bufPos++) = 0;
}As far as the snapshot issues, I'm almost positive it's in the GUI code somewhere, but I don't really have time to look into it. You're right that the issue happens when you press one of the buttons. It's completely unloading the MSU-1 related files, which causes the next MSU-1 call to fail and drop back to SPC fallback. If there's anybody more familiar with the GUI code, that's where you should be looking. Trace through the callbacks for those buttons and see if you can find where it's closing files or releasing open file handles. Once we find the offending code, it's probably an incredibly simple fix. I'm just not very familiar with the code, and unfortunately, runtime debugging is not a simple task.
(also, just a note, if you want to get my attention, I don't actively follow this thread at all, but @ mentioning me sends me email notifications, so if I don't respond, try that)
Cool @qwertymodo, so, currently, it is like this on my source:That's essentially an independent re-implementation of this fix I already made and completely forgot about. Derp
Code:
else
{
if (MSU1.MSU1_STATUS & AudioRepeating)
{
MSU1.MSU1_AUDIO_POS = audioLoopPos;
MSU1_AUDIO_SEEK(MSU1.MSU1_AUDIO_POS);
}
else
{
MSU1.MSU1_STATUS &= ~(AudioPlaying | AudioRepeating);
}
}
}
else
{
MSU1.MSU1_STATUS &= ~(AudioPlaying | AudioRepeating);
}
}
else
{
*(bufPos++) = 0.0;
partial_samples -= 32040;
}
}
}So, from what i understand, i should change it into this:
Code:
else
{
if (MSU1.MSU1_STATUS & AudioRepeating)
{
MSU1.MSU1_AUDIO_POS = audioLoopPos;
MSU1_AUDIO_SEEK(MSU1.MSU1_AUDIO_POS);
}
else
{
MSU1.MSU1_STATUS &= ~(AudioPlaying | AudioRepeating);
}
}
}
else
{
MSU1.MSU1_STATUS &= ~(AudioPlaying | AudioRepeating);
}
}
else
{
MSU1.MSU1_STATUS &= ~(AudioPlaying | AudioRepeating);
partial_samples -= 32040;
*(bufPos++) = 0.0;
}
}
}Yeah, i totally understand, i follow a couple of your projects, specially the ones that are MSU-1 related, of course. Thanks for the tips! I'll see what i can do.
It's okey, if you'd like me to send you emails (or not) instead of posting here, just lemme know. You asked me to send you a bit of code a while back, so i should have your address on my inbox.
Right now, we're trying to track down one remaining issue (fast-forward causes a desync), at which point you should probably just drop in the current main-line versions of msu1.h/cpp instead of trying to cherry-pick changes. I also just fixed a fairly significant memory leak upstream just now. I'll try to pull it down, along with cherry-picking any other changes that have been made to apu.cpp, since those can't just be dropped in due to GX using the older APU.
Ok @qwertymodo, just to be sure, i should use msu1.h/cpp from snes9xgit or libretro-snes9x?
That's great to hear. I suppose i'll keep an eye on your Github GX fork to use it as soon as it gets out =)
Grab it from my repo: https://github.com/qwertymodo/snes9xgx/tree/msu1 just give me a bit, something's broken and the Wiimote disconnects when I try to open a folder. I'm running a bisect now to try and figure out where the problem is. I also added .bps patch support just now, so you'll want to grab that. Right now, the relevant changes are in apu.cpp, memmap.cpp, and msu1.h/cpp
Cool, thanks for the feedback. Just need to figure out snapshots now.
Sent from my m8wl using Tapatalk
Sent from my m8wl using Tapatalk
D
Deleted User
Guest
I noticed this when playing on a mono CRT, but mostly on the Turtles in Time MSU-1 game (right at the 1st level).
@qwertymodo I've finally bit the bullet and tried your Chrono Trigger MSU-1 patch. Noticed some minor pops here and there at the intro gameplay demo, right after the pendulum swing. When the pendulum scene comes again, skips were a bit more noticeable. Would this be affected whether i use the SD card or USB? I'll try to make some other tests this afternoon.
EDIT: though there were a little bit less skips when using USB, they were still noticeable. It seems to happen consistently after at least 1 full minute of MSU music playing. Again, i used Chrono Trigger for this round of tests. Just to clarify, this behaviour is the same as before the new cpp/h patches.
Last edited by niuus,
Yeah, Chrono Trigger has been my primary litmus test. I'm hoping that the remaining skips are due to lag, and might be related to the fast-forward issue (basically, the MSU isn't handling lag *at all* which means if you fast forward repeatedly it gets way out of sync because it drops samples every time you start and stop FF, so for videos you'll really notice because the audio will finish way before the video does). Beyond that, it's back to the audio core, and I still have absolutely no idea what I'm doing there. OV2 and bearoso have said they'd look into the desync, so when that gets figured out I'll try to backport it here.
Similar threads
-
- Article
