Merge train from preview #664
Merged
+607
−408
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Because the RSP mixer ucode does overread (that is, it can read a bit past the waveform end), we need to make sure that those extra bytes are 0 (in case of a non looping waveform). Up until now, this was left to the waveform callback to implement. We can do better: just like for the looping case, we can have the mixer handle this internally by clearing up the extra samples, calling the callback only for actual samples. This better matches the waveform callback API too, and makes things easier. Moreover, the overread now is 100% an implementation detail of the mixer.
Added samplebuffer_undo to remove some samples that were previously added. Added samplebuffer_is_inited
Rewrite the looping logic of the RSP code correctly handle RDRAM misalignments.
Currently, the mixer allocates all channels with a single global malloc. The whole allocation is changed when something calls mixer_ch_set_limits, just like the xm64 player does. Normally, this didn't create any problems and if anything, decreased fragmentation. Unfortunately, with compressed waveforms support now (VADPCM), there is a bug if you play a compressed waveforms and then starts a xm64. xm64 will call mixer_ch_set_limits that in turn will reallocate all channels, including discarding sample buffers that already contains VADPCM samples that were already decompressed but not yet played back; and since VADPCM can't seek backward, the playback will crash. Compressed waveforms normally work in "frames" so it's normally to fully decompressed one audio frame even though this is more than strictly requested by the mixer: the extra samples stay in the sample buffer ready. But if the mixer reallocates memory, that data is discarded, casing havoc. The new strategy, implemented by this change, is to allocate each channel individually. This way, calling mixer_ch_set_limits on *other* channels won't create issues to other channels were playback is in progress. It can increase fragmentation but such is life. There's also a slight-possible breaking change because samplebuffer API is public (mistake from the past), and now samplebuffer owns the allocation. Hopefully nobody is doing anything with them anyway.
Calling wav64_close on an in-progress playback would cause a crash. This is quite unfortunate and unexpected by the user. We add a private API to the mixer to do this, but it's pretty clear that wav64 will have to track whether playback is in progress or not at some point. For now, let's fix the crash.
Currently, wav64 is limited to rom:/ addresses as internally it does direct DMA access. We change it to use a file descriptor so that it can work on any filesystem. Direct DMA requests are basically changed into standard lseek+read calls.
Also create a pluggable compression system, similar to that already used for assets.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.