-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
SampleBuffer -> Samplerate - Fix two sample rate issues: #4991
Conversation
#4786 is not fixed with this PR. 😕 I guess, the sample on the sample track is played with its own samplerate. I exported a clicktrack (with 44100) and loaded it to the sample track. My Jack runs with 48000 Hz. The click and the sample aren't in sync anymore. |
Ok, I've found the right commit. However, I can't understand how your solution has solved it? :\ |
6f314c2
to
f0e344f
Compare
Thanks! I'll look into that in a few hours.
…On Wed, 29 May 2019, 11:47 Steffen Baranowsky, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/core/SampleBuffer.cpp
<#4991 (comment)>:
> @@ -1196,7 +1201,7 @@ SampleBuffer * SampleBuffer::resample( const sample_rate_t _src_sr,
src_data.data_out = dst_buf[0];
src_data.input_frames = frames;
src_data.output_frames = dst_frames;
- src_data.src_ratio = (double) _dst_sr / _src_sr;
+ src_data.src_ratio = (double) _src_sr / _dst_sr;
My Jack is running on 48Khz. I have a click track. I export the project
*.wav with 44,1 khz. I insert the *.wav to a sample track. It isn't in sync:
[image: Bildschirmfoto von 2019-05-29 10-37-38]
<https://user-images.githubusercontent.com/6502580/58543012-dc58e380-81fe-11e9-9c4f-fee53f266c06.png>
If I revert this line (_dst_sr / _src_sr) it is in sync:
[image: Bildschirmfoto von 2019-05-29 10-39-19]
<https://user-images.githubusercontent.com/6502580/58543102-08746480-81ff-11e9-9fee-e08991831025.png>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4991?email_source=notifications&email_token=AFOMGKCRTHMBXKI5NG4IKNTPXY7J7A5CNFSM4HPVG4AKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOBZ63ARQ#pullrequestreview-243118150>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFOMGKFLPCHJROEUMPSEOWDPXY7J7ANCNFSM4HPVG4AA>
.
|
f0e344f
to
fedcd9a
Compare
Oky dooky, I think we are good now (I fixed that in another commit probably :) Thanks for your help! |
fedcd9a
to
c9e457c
Compare
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.
The issue is fixed with this PR, now. After fixing these 2 style issues I vote for merge.
SampleBuffer was using baseSampleRate as the default samplerate instead of the actual processingSampleRate.
played correctly after saving and loading a project due to sample rate not getting saved in the project file.
right place when it not played from the begining. That has created a difference between the ticks and the metronome and the sample track. The cause of the problem was that the calculation of the frame to play was wrong: we had calculated `framesPerTick` according to the current engine's sample rate instead of the SampleBuffer's sample rate.
c9e457c
to
78b0652
Compare
Since it isn't a single issue, I'll rebase it instead of squashing. |
instead of the actual processingSampleRate.
Closes #4786