Skip to content
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

TickRate: Issue in Interpolation Mode #92

Open
MeFisto94 opened this issue Feb 19, 2019 · 4 comments
Open

TickRate: Issue in Interpolation Mode #92

MeFisto94 opened this issue Feb 19, 2019 · 4 comments

Comments

@MeFisto94
Copy link

So for my case I noticed that FilePlayer had some issues with a samplerate and only samples with 22050 Hz were playing correctly, long story short, I wanted to use a TickRate(2f) to fix that problem but noticed I couldn't hear anything.

Without interpolation, only half of the samples are considered at all [nextSample is discarded as audio is ticked twice], but with interpolation I didn't hear anything either. Debugging showed:

https://github.com/ddf/Minim/blob/master/src/main/java/ddf/minim/ugens/TickRate.java#L184
The problem here is: A) sampleCount where sampleStep was inteded, because sampleCount is always 0. B) I guess / sampleStep was intended instead of * sampleCount to basically have the average of all the samples.

@ddf
Copy link
Owner

ddf commented Feb 22, 2019

There's no resampling in FilePlayer, so if you load a file that is a 44100Hz recording and play it on a 22050Hz output, it will sound slowed down by half. You could use a TickRate(2f) to remedy this and I would expect it to output every other sample as you describe, even with interpolation turned on, since sampleStep will be exactly 2 and the while( sampleCount >= 1.f) block further down will tick the connected UGen twice. This means the output on the line you link to will always just be currentSample[i], same as when interpolation is turned off. At least that's what's intended.

Can you provide an example file that you are having trouble with and information about the audio format of the AudioOutput you are trying to play it through?

@MeFisto94
Copy link
Author

MeFisto94 commented Feb 28, 2019

There's no resampling in FilePlayer, so if you load a file that is a 44100Hz recording and play it on a 22050Hz output, it will sound slowed down by half.

Actually most files should've been 44100Hz as that's what I wanted to target, I have no clue why the output chose 22050Hz as default (or mabye FilePlayer assumed it to be 22050Hz for some reason?)

even with interpolation turned on, since sampleStep will be exactly 2 and the while( sampleCount >= 1.f) block further down will tick the connected UGen twice. This means the output on the line you link to will always just be currentSample[i], same as when interpolation is turned off. At least that's what's intended.

I agree with you on the ticked twice part, that's obvious. But say we're about to sample a sine wave, then ticking twice gives us two data points. Unfortunately, we can only proceed with one. Why would you arbitrarly choose the second one? Wouldn't interpolation imply the average of both samples?

I have to create a minimum viable test case as I'm having issues on multiple fronts but since I have a rather complex setup (a live input, two ouputs, many samples, multiple gains), I have to see individually where the problem is.

@MeFisto94
Copy link
Author

So I drew the following conclusion:
FilePlayer doesn't automatically resample, so all files have to manually be resampled to 44100 Hz for now, so I don't have an issue anymore.

For this issue though, I think that when sampling down from 44.1kHz to 22.05kHz the samples in the output should be the average of the two ticked 44.1 samples, so essentially interpolation instead of skipping frames. But that is just my intention, I don't know if that makes an audible difference or not.

@ddf
Copy link
Owner

ddf commented Apr 19, 2019

I don't think averaging the samples makes any difference here, since that's just the midpoint of the two samples. Effectively you are sampling the source at 2x but with a half sample offset, which will likely sound the same as using every other sample. TickRate is not meant to be a resampler, it's simply a generation speed control. I've not looked much into resampling, but my very limited understanding is that it's definitely very different from what's going on in TickRate.

I can certainly try a test that plays back a 44100Hz audio file on a 22050Hz output going through a TickRate set to 2, but I'm also a little confused about your initial setup where you had the bug of not getting any sound. You original Issue says only files at 22050Hz were playing correctly but now you've fixed it by manually resampling all files to 44100Hz. Can you tell me exactly the situation in your original setup, file sample rate and output sample rate? Even better if you can provide a sketch that demonstrates the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants