New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DSPHLE: Add HLE version of libaesnd ucode #10793
Conversation
|
Since this PR and the other PR covers libasnd and libaesnd, does that mean that the error where it tells you to use DSP LLE can be removed? Or are there still some homebrews which have weird exceptions where DSP HLE doesn't work and the error still displays? |
|
I assume you're referring to these messages: Due to how DSPHLE works, they're still needed. We attempt to match the uCode to use based on the hash of the code the game sends, but if the game sends code we don't recognize, that error appears. Games (and particularly homebrew) can send anything they want. For official games, this might just be a version of the uCode we don't recognize (see e.g. #10686 where a demo version of a game used a different uCode version). We need to do something in that case, and an error message is the best solution. For homebrew specifically, there are two cases I know of where unknown uCode will be used. The first is homebrew that uses the DSP for obfuscation (devolution does this, though it doesn't boot far enough in Dolphin to see it) - this is specific to the homebrew in question and would be a lot of work to HLE (for no real benefit). The second is DSPSpy, which is used to send completely arbitrary uCode to the DSP to test features of the DSP; since it's for testing it also doesn't make sense to HLE it. That said, the message itself won't show up for homebrew using libasnd or libaesnd now (at least for normal versions of it). It probably would make sense to make the message be more direct: "This title is incompatible with DSP HLE. Use DSP LLE for proper emulation." There shouldn't be any more cases where this triggers on official games, and the fallback of treating it as AX uCode doesn't work right for homebrew (or official games that use an unknown version of the zelda uCode, as was the case for the Pikmin demo). |
|
I see, so that error message won't appear as often and is still needed in some rare cases, got it |
|
Is this more or less done now? |
|
Yes, just waiting on a review. |
|
Can someone review this if they can? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good to me from a coding style point of view. I can't assess the audio part and its behaviour. I tested this PR with modplay and wii-tac-toe.
However, I haven't tested this PR with EDuke32 which uses a libaesnd's mod from tueidj.
Regardless, LGTM.


This PR adds an HLE version of the libaesnd ucode, which is used by newer homebrew (particularly homebrew with MOD music).
The libaesnd is a more advanced compared to the libasnd ucode, in that it uses more DSP features (in particular the stack registers, the wrapping registers, the accelerator, and extended instructions), but the actual ucode is organized in a cleaner way so this was easier to port. (That's not to say libasnd isn't impressive in its own way; it was developed when fewer DSP features were understood, and the tooling had to be developed with it.)
I've done limited testing with the modplay example included with libogc, and with the Harmony's Nightmare homebrew (which is somewhat weird, but it does feature both sound effects and music). Note that the latter behaves a bit weirdly (missing intro screen and phases of levels, and weird graphics) when started directly by Dolphin, but behaves fine if started by the (open) homebrew channel (even with
wiiload).I've implemented 3 versions, corresponding to 3 libogc releases. I've only tested the 2012 and 2020 versions, as I couldn't easily find any homebrew using the 2010 version. The history indicates a few other versions (including a mismatch between the binary and source in the repo), but they wouldn't have been present in a released version of libogc. See aesnd_ucode_versions.zip for a complete list of these.
Hashes of various possible versions for search purposes
This PR also includes some minor cleanup for #10763.