Adjustable sample-rate and frequency shifting on samples #151
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
use an enum for AudioState use more consistent variable naming fix some code formatting
calculate sample playback rate based on a base frequency value for the sample. this defaults to 532hz, or C5 (the C above middle-C)
this allows frequency adjustment of sample playback to be compatible with existing code that could be providing any value for sample frequency to `playNote`
includes variants both for negative sample numbers and bufferId-based numbering
support added for defining looping on a sample sample playback however needs reworking. the current system has the AudioSample structure keeping track of where playback is inside a sample, however that wouldn’t allow the same sample to be played simultaneously on more than one channel control of sample playback instead needs to move into the EnhancedSamplesGenerator. much of what’s in this commit needs to be moved
logic moved out of AudioSample for keeping track of position within sample this will allow the same sample to be played back on multiple channels simultaneously hack of using frequency -1 also no longer needed, as channel and sample generator now support `seekTo`
allows for note duration to be set to a 24-bit value
allows for the the sample rate for the underlying system, or for a waveform on an individual channel, to be adjusted
|
FYI this functionality is all "additive" to the existing API - all existing sample using code will still work unchanged. samples only become "tuneable" when a base frequency is set on them. samples still loop by default in the exact manner they did before, etc etc. |
duration of a sample when played back calculation was buggy, resulting in looping samples when they shouldn’t the sample generator’s `getDuration` call needs to calculate based on how long the _underlying_ audio system will take to step through samples, therefore it is the sample rate of the underlying system that needs to be used for calculations
avoids placing audio objects (waveform generators and AudioSample objects) in psram, as the ESP32 has cache bugs related to psram. whilst there is a compiler work-around for this (which we're using) the fix doesn't seem to work in the context of our multi-threaded and interrupt-driven audio system audio logging improved audio channel state is an atomic value to ensure consistency across different threads
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.
This builds on work done by @movievertigo in #143
With this PR it becomes possible to set a "base frequency" on a sample, and once that is set the sample can be played at different frequencies.
It also becomes possible to adjust the sample rate of the underlying audio system. This allows the audio system to run with a higher fidelity than the default 16khz - altho that remains the default.
Individual samples can also be set to differing sample rates. The audio system will automatically compensate for this, ensuring that samples play back at the correct speed irrespective of what the rate the sample has been set to or the underlying audio system.
Looping of samples can now also be controlled; it is possible to set the byte offset within a sample of where repeats start from as well as the length of the section to repeat.
Note duration can be changed after starting playback, or set to initiate playback. This allows for durations longer than 65s, which can be useful when playing back long samples.
documentation on the audio system API changes to support this enhanced functionality can be found in AgonConsole8/agon-docs#6