I have only used libraries for resampling myself. I haven't looked at their source, but it's available. The two libraries I'm aware of are at http://www.mega-nerd.com/SRC/download.html and https://kokkinizita.linuxaudio.org/linuxaudio/zita-resampler/resampler.html
perhaps they can give you some insight. On Wed, Oct 3, 2018 at 2:46 PM Alex Dashevski <alexd...@gmail.com> wrote: > I wrote on android ndk and there is fastpath concept. Thus, I think that > resampling can help me. > Can you recommend me code example ? > Can you give me an example of resampling ? for example from 48Khz to 8Khz > and 8Khz to 48Khz. > I found this: > https://dspguru.com/dsp/faqs/multirate/resampling/ > but it is not enough clear for me, > > Thanks, > Alex > > > בתאריך יום ד׳, 3 באוק׳ 2018 ב-20:56 מאת Spencer Jackson < > ssjackso...@gmail.com>: > >> >> >> On Wed, Oct 3, 2018 at 3:17 AM Alex Dashevski <alexd...@gmail.com> wrote: >> >>> >>> if I do resampling before and after processing. for example, 48Khz -> >>> 8Khz and then 8Khz -> 48Khz then will it help ? >>> >> >> Lowering sample rate can help achieve lower latencies by giving you fewer >> samples to process in the same amount of time but just downsampling and >> then upsampling back doesn't really have any effect. >> >> >> >>> I don't understand why I need filter, This is to prevent alias but I >>> can't understand why ? >>> >>> Technically you only need a filter if your signal has information above >> the nyquist frequency of the lowest rate but this is not usually the case. >> I think wikipedia explains aliasing pretty well: >> https://en.wikipedia.org/wiki/Aliasing#Sampling_sinusoidal_functions . >> Once the high frequency information aliases it cannot be recovered by >> resampling back to the higher rate and your lower band information is now >> mixed in with the aliased information. The filter removes this high >> freqency data so that the low band stays clean through the whole process. >> >> >> Is there option to decrease latency or delay ? >>> >> >> The only way to reduce latency in your algorithm (unless there is some >> error in the implementation) is to reduce the block size, so you process >> 128 samples rather than 240. 240 isn't a very large amount of latency for a >> pitch shifter which is typically a CPU intensive process and therefore most >> implementations have relatively high latencies. >> >> I'm not sure I understand what you mean by the pitch duration requiring a >> buffer-resize or sample-rate decrease. WSOLA creates a signal with more >> samples than the input, you must resample that (usually by a non-integer >> amount) to make it the correct number of samples then output that, and >> reload your buffer with the next block of input data. Please clarify if you >> mean some other issue. >> >> _Spencer >> _______________________________________________ >> dupswapdrop: music-dsp mailing list >> music-dsp@music.columbia.edu >> https://lists.columbia.edu/mailman/listinfo/music-dsp > > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
