Many games report 6 channel output while only providing data for 2. We only output 2-channel audio regardless, and in the downmixing, front left/right only provide 36% of their volume. This is done assuming all of the other channels also contain valid data, but in many games they don't. This PR alters the downmixing to preserve front left/right, so volume is not lost.
This improves volume in Link's Awakening, New Super Mario Bros U, Disgaea 6, Super Kirby Clash.
There's no point in keeping the file open after the write limit is exceeded. This allows the file to be committed to the disk shortly after it is closed and avoids redundantly checking whether or not the write limit is exceeded.
It became apparent that logging can continuously spam errors that trigger file flushing.
Since committing the files to disk is an expensive operation, this causes unnecessarily high disk usage.
As such, we will revert Flush() to the previous behavior and add a Commit() member function in the event that this behavior is needed.
We were including the first 2 default miis which are not meant to be shown in games. With this change, we properly retrieve the 6 default miis shown in games, with 3 of each gender.
This lets us avoid needing to wrap external headers with #pragma warning directives for warnings we treat as errors and avoids generating warnings for external code.
Thanks to MerryMage for pointing this out.
If someone else wants to support other mod formats in the SDMC
directory, that can be added later. For now, just allow RomFS modding
here and force people to do other types of mods the old way.
Addresses review comments.
Co-authored-by: LC <mathew1800@gmail.com>
Currently, processing of audio samples is called from AudioRenderer's Update method, using a fixed 4 buffers to process the given samples. Games call Update at variable rates, depending on framerate and/or sample count, which causes inconsistency in audio processing. From what I've seen, 60 FPS games update every ~0.004s, but 30 FPS/160 sample games update somewhere between 0.02 and 0.04, 5-10x slower. Not enough samples get fed to the backend, leading to a lot of audio skipping.
This PR seeks to address this by de-coupling the audio consumption and the audio update. Update remains the same without calling for buffer queuing, and the consume now schedules itself to run based on the sample rate and count.
