-
Notifications
You must be signed in to change notification settings - Fork 15
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
Rewrite resampler #166
Merged
Merged
Rewrite resampler #166
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
MarkKremer
force-pushed
the
resampler-rewrite
branch
from
July 11, 2024 12:25
3a9ea05
to
7301df4
Compare
The original length of pts made sense because when wantPos is a decimal position like 3.5, you want the window for quality 1 to contain positions 3 and 4. Having a window of 1 more doesn't make sense for that. My previous reasoning for increasing the window size was arguing from the point of wantPosition always being an integer value, which isn't the case.
Two bugs: - SetRatio() could cause out of range panic when the ratio was sufficiently big. This happens when the newly calculated position was casted to an int. This caused the value to be rounded down. If difference times the ratio was bigger than the buffer, the calculated wantPos could be a negative index in buf1. - When the ratio is sufficiently big, the Stream function may not only need to fill the buffers with new data once, but multiple times. The if statement has been replaced with a for loop, so the check is executed until the desired samples are reached.
dusk125
requested changes
Jul 30, 2024
dusk125
approved these changes
Jul 31, 2024
dusk125
approved these changes
Jul 31, 2024
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.
lgtm
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.
Fix for #20
Rewritten the
Resampler
to make the code easier to read & fix some bugs:When the source streamer didn't conform the
Streamer
interface by returning a drained signal & then returning samples again, the internal buffer could be resized and unsuitable to do the job causing an out of range panic. The new resampler keeps track of the end of the stream. When the end is reached, it will simply stay in a drained state.SetRatio
with a big enough ratio could cause an out of range panic. This was because during the calculation of the newpos
, the result was cast to an int. If the ratio was so big that this rounding down caused a different of more than the buffer size, the buffer would be indexed with a negative value. I don't expect any reasonable application to run into this error, but it's nice to not get panics when playing around with the speedy-player example. That said, I've added some limits to the values that can be selected in that example.pos
is now afloat64
. I expect this to carry enough precision for most use-cases. Say you have a resample ratio of 1/6 (from 8000 to 48000), 48000 samples per seconds, 86400 seconds in a day, 365 days in a year, the number of unique values would be6*48000*86400*365 = 9.082368×10^12
.float64
has enough precision to hold a bit less than 16 decimal digits so even though I'm not entirely sure how much we need, there is still a bunch of wiggle room.SetRatio
being more precise is probably good for theDoppler
streamer. Less samples will be skipped over.Stream
fetches new samples from the source streamer to fill the buffer when it detects that the samples needed for the interpolation are after the currently loaded buffers. However, when the ratio is larger than the buffer size, the needed samples could be more than one buffer away. I've replaced theif
statement with afor
loop so it keeps streaming samples until it reaches the right index. This solves another out of range panic.I've added a fuzz test to confirm weird resample ratios don't cause panics anymore.
It seems that the doppler example is now easier to crash. But the
Doppler
streamer is experimental and was giving the resampler invalid ratios. It probably needs a rewrite as well, but that something for another day.