Re: [music-dsp] Resampling

[Alex Dashevski]

I have project with pitch shifting (resampling with wsola), It implements
on android NDK.
Since duration of pitch is ~20ms, I can't use system recommended
parameters for the fast path. for example, for my device: SampleRate:48Khz
and buffer size 240 samples. That means, duration time is 5ms (< pitch
duration = 20ms).
What can I do so I can use recommended parameters because it increases
latency. For example if I use 48Khz and 240 samples then latency is 66 ms
but if buffer size is 24000 samples then latency is 300ms.
I need latency < 100ms.

Thanks,
Alex

‫בתאריך שבת, 6 באוק׳ 2018 ב-14:11 מאת ‪Ethan Fenn‬‏ <‪et...@polyspectral.com
‬‏>:‬

> You've got it backwards -- downsample means fewer samples. If you have a
> 240-sample buffer at 48kHz, then resample to 8kHz, you'll have 240/6=40
> samples.
>
> -Ethan
>
>
> On Sat, Oct 6, 2018 at 4:10 AM, Alex Dashevski  wrote:
>
>> Hi,
>> Let's assume that my system has sample rate = 48Khz and audio buffer size
>> = 240 samples. It should be on RealTime.
>> Can I do that:
>>
>> 1. Dowsampe to 8Khz and buffer size should be 240*6
>> 2. To do proccessing on buffer 240*6 with 8Khz sample rate.
>> 3. Upsample to 48khz with original buffer size.
>>
>> Thanks,
>> Alex
>>
>>
>> ‫בתאריך יום ד׳, 3 באוק׳ 2018 ב-23:51 מאת ‪Spencer Jackson‬‏ <‪
>> ssjackso...@gmail.com‬‏>:‬
>>
>>> 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 
>>> 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 
> 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
>>
>>
>> ___
>> dupswapdrop: music-dsp 

Re: [music-dsp] Resampling

[Alex Dashevski]

Hi,
Let's assume that my system has sample rate = 48Khz and audio buffer size =
240 samples. It should be on RealTime.
Can I do that:

1. Dowsampe to 8Khz and buffer size should be 240*6
2. To do proccessing on buffer 240*6 with 8Khz sample rate.
3. Upsample to 48khz with original buffer size.

Thanks,
Alex


‫בתאריך יום ד׳, 3 באוק׳ 2018 ב-23:51 מאת ‪Spencer Jackson‬‏ <‪
ssjackso...@gmail.com‬‏>:‬

> 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  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 
>>> 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
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

[Ethan Fenn]

You've got it backwards -- downsample means fewer samples. If you have a
240-sample buffer at 48kHz, then resample to 8kHz, you'll have 240/6=40
samples.

-Ethan


On Sat, Oct 6, 2018 at 4:10 AM, Alex Dashevski  wrote:

> Hi,
> Let's assume that my system has sample rate = 48Khz and audio buffer size
> = 240 samples. It should be on RealTime.
> Can I do that:
>
> 1. Dowsampe to 8Khz and buffer size should be 240*6
> 2. To do proccessing on buffer 240*6 with 8Khz sample rate.
> 3. Upsample to 48khz with original buffer size.
>
> Thanks,
> Alex
>
>
> ‫בתאריך יום ד׳, 3 באוק׳ 2018 ב-23:51 מאת ‪Spencer Jackson‬‏ <‪
> ssjackso...@gmail.com‬‏>:‬
>
>> 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  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 
 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
>
>
> ___
> 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

Re: [music-dsp] Resampling

[gm]

Your numbers don't make sense to me but probably I just dont understand it.

The latency should be independent of the sample rate, right?

You search for similarity in the wave, chop it up, and replay the grains 
at different speeds and/or rates.


What you need for this is a certain amount of time of the wave.

If you need a latency of <= 100 ms you can have two wave cycles stored
of 50ms length / 20 Hz, which should be sufficient, given taht voice is 
ususally well above 20 Hz.



Am 06.10.2018 um 13:45 schrieb Alex Dashevski:
I have project with pitch shifting (resampling with wsola), It 
implements on android NDK.
Since duration of pitch is ~20ms, I can't use system recommendedB  
parameters for the fast path. for example, for my device: 
SampleRate:48Khz and buffer size 240 samples. That means, duration 
time is 5ms (< pitch duration = 20ms).
What can I do so I can use recommended parameters because it increases 
latency. For example if I use 48Khz and 240 samples then latency is 66 
ms but if buffer size is 24000 samples then latency is 300ms.

I need latency < 100ms.

Thanks,
Alex

b> 
You've got it backwards -- downsample means fewer samples. If you
have a 240-sample buffer at 48kHz, then resample to 8kHz, you'll
have 240/6=40 samples.

-Ethan


On Sat, Oct 6, 2018 at 4:10 AM, Alex Dashevski mailto:alexd...@gmail.com>> wrote:

Hi,
Let's assume that my system has sample rate = 48Khz and audio
buffer size = 240 samples. It should be on RealTime.
Can I do that:

1. Dowsampe to 8Khz and buffer size should be 240*6
2. To do proccessing on buffer 240*6 with 8Khz sample rate.
3. Upsample to 48khz with original buffer size.

Thanks,
Alex


b> 
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
mailto: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


b> Jacksonb> 
b>


On Wed, Oct 3, 2018 at 3:17 AM Alex Dashevski
mailto: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.B  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.

Re: [music-dsp] Resampling

[gm]

In my example, the buffer is 2 times as long as the lowest possible pitch,
for example if your lowest pitch is 20 Hz, you need 50 ms for one wave cycle

Think of it as magnetic tape, without sample rate, the minimum requierd 
latency and the buffer length in milliesconds

are independent of sample rate
You have 100 ms "magnetic tape", search for similarity, and then chop 
the tape according to that.

Then you have sippets of 50 ms length or smaller.
Then you copy these snippets and piece them together again, at a higher 
or slower rate than before.
You can also shrink or lengthen the snippets and change the formants, 
that ist shift all

spectral contant of one snippet up or down.




Am 06.10.2018 um 17:58 schrieb Alex Dashevski:

Hi,

I can't understand your answer.B  The duration of buffer should be 
bigger than duration of pitch because I use WSOLA.

The latency also depends on sample rate and buffer length.

Thanks,
Alex

b> b>
Your numbers don't make sense to me but probably I just dont
understand it.

The latency should be independent of the sample rate, right?

You search for similarity in the wave, chop it up, and replay the
grains at different speeds and/or rates.

What you need for this is a certain amount of time of the wave.

If you need a latency of <= 100 ms you can have two wave cycles stored
of 50ms length / 20 Hz, which should be sufficient, given taht
voice is ususally well above 20 Hz.




___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

[Alex Dashevski]

I still don't understand. You change buffer size. Right ?
But I don't want to change.

‫בתאריך שבת, 6 באוק׳ 2018 ב-19:11 מאת ‪gm‬‏ <‪g...@voxangelica.net‬‏>:‬

>
> In my example, the buffer is 2 times as long as the lowest possible pitch,
> for example if your lowest pitch is 20 Hz, you need 50 ms for one wave
> cycle
>
> Think of it as magnetic tape, without sample rate, the minimum requierd
> latency and the buffer length in milliesconds
> are independent of sample rate
> You have 100 ms "magnetic tape", search for similarity, and then chop the
> tape according to that.
> Then you have sippets of 50 ms length or smaller.
> Then you copy these snippets and piece them together again, at a higher or
> slower rate than before.
> You can also shrink or lengthen the snippets and change the formants, that
> ist shift all
> spectral contant of one snippet up or down.
>
>
>
>
> Am 06.10.2018 um 17:58 schrieb Alex Dashevski:
>
> Hi,
>
> I can't understand your answer.B The duration of buffer should be bigger
> than duration of pitch because I use WSOLA.
> The latency also depends on sample rate and buffer length.
>
> Thanks,
> Alex
>
> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
> g...@voxangelica.netb
>
>> Your numbers don't make sense to me but probably I just dont understand
>> it.
>>
>> The latency should be independent of the sample rate, right?
>>
>> You search for similarity in the wave, chop it up, and replay the grains
>> at different speeds and/or rates.
>>
>> What you need for this is a certain amount of time of the wave.
>>
>> If you need a latency of <= 100 ms you can have two wave cycles stored
>> of 50ms length / 20 Hz, which should be sufficient, given taht voice is
>> ususally well above 20 Hz.
>>
>>
> ___
> 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

Re: [music-dsp] Resampling

[Alex Dashevski]

Hi,
phase vocoder doesn't have restriction of duration ?
Thanks,
Alex

‫בתאריך שבת, 6 באוק׳ 2018 ב-20:55 מאת ‪Daniel Varela‬‏ <‪
danielvarela...@gmail.com‬‏>:‬

> You could try a phase vocoder instead of WSOLA for time stretching.
> Latency would be the size of the fft block.
>
> El sáb., 6 oct. 2018 19:49, gm  escribió:
>
>>
>> right
>>
>> the latency required is that you need to store the complete wavecycle, or
>> two of them, to compare them
>>
>> (My method works a little bit different, so I only need one wavecycle.)
>>
>> So you always have this latency, regardless what sample rate you use.
>>
>> But maybe you dont need 20 Hz, for speech for instance I think that 100
>> or even 150 Hz is sufficient? I dont know
>>
>>
>>
>> Am 06.10.2018 um 19:34 schrieb Alex Dashevski:
>>
>> If I understand correctly, resampling will not help. Right ?
>> No other technique that will help. Right ?
>> What do you mean "but not the duration/latency required" ?
>>
>> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
>> g...@voxangelica.netb
>>
>>>
>>>
>>> Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
>>> > What do you mean "replay" ? duplicate buffer ?
>>>
>>> I mean to just read the buffer for the output.
>>> So in my example you play back 10 ms audio (windowed of course), then
>>> you move your read pointer and play
>>> that audio back again, and so on, untill the next "slice" or "grain" or
>>> "snippet" of audio is played back.
>>>
>>> > I have the opposite problem. My original buffer size doesn't contain
>>> > full cycle of the pitch.
>>>
>>> then your pitch is too low or your buffer too small - there is no way
>>> around this, it's physics / causality.
>>> You can decrease the number of samples of the buffer with a lower sample
>>> rate,
>>> but not the duration/latency required.
>>>
>>> > How can I succeed to shift pitch ?
>>>
>>> You wrote you can have a latency of < 100ms, but 100ms should be
>>> sufficient for this.
>>>
>>>
>>>
>>> ___
>>> 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
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

[Alex Dashevski]

If I understand correctly, resampling will not help. Right ?
No other technique that will help. Right ?
What do you mean "but not the duration/latency required" ?

‫בתאריך שבת, 6 באוק׳ 2018 ב-20:29 מאת ‪gm‬‏ <‪g...@voxangelica.net‬‏>:‬

>
>
> Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
> > What do you mean "replay" ? duplicate buffer ?
>
> I mean to just read the buffer for the output.
> So in my example you play back 10 ms audio (windowed of course), then
> you move your read pointer and play
> that audio back again, and so on, untill the next "slice" or "grain" or
> "snippet" of audio is played back.
>
> > I have the opposite problem. My original buffer size doesn't contain
> > full cycle of the pitch.
>
> then your pitch is too low or your buffer too small - there is no way
> around this, it's physics / causality.
> You can decrease the number of samples of the buffer with a lower sample
> rate,
> but not the duration/latency required.
>
> > How can I succeed to shift pitch ?
>
> You wrote you can have a latency of < 100ms, but 100ms should be
> sufficient for this.
>
>
>
> ___
> 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

Re: [music-dsp] Resampling

[gm]

You can "freeze" audio with the phase vocoder "for ever" if that ist 
what you want to do.


You just keep the magnitude of the spectrum from one point in time and 
keep it


and update the phases with the phase differences of that moment.



Am 06.10.2018 um 20:02 schrieb Alex Dashevski:

Hi,
phase vocoder doesn't have restriction of duration ?
Thanks,
Alex

b> 
You could try a phase vocoder instead of WSOLA for time
stretching. Latency would be the size of the fft block.

El sC!b., 6 oct. 2018 19:49, gm mailto:g...@voxangelica.net>> escribiC3:


right

the latency required is that you need to store the complete
wavecycle, or two of them, to compare them

(My method works a little bit different, so I only need one
wavecycle.)

So you always have this latency, regardless what sample rate
you use.

But maybe you dont need 20 Hz, for speech for instance I think
that 100 or even 150 Hz is sufficient? I dont know



Am 06.10.2018 um 19:34 schrieb Alex Dashevski:

If I understand correctly, resampling will not help. Right ?
No other technique that will help. Right ?
What do you mean "but not the duration/latency required" ?

b href="mailto:g...@voxangelica.net
"
moz-do-not-send="true">g...@voxangelica.net
b



Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
> What do you mean "replay" ? duplicate buffer ?

I mean to just read the buffer for the output.
So in my example you play back 10 ms audio (windowed of
course), then
you move your read pointer and play
that audio back again, and so on, untill the next "slice"
or "grain" or
"snippet" of audio is played back.

> I have the opposite problem. My original buffer size
doesn't contain
> full cycle of the pitch.

then your pitch is too low or your buffer too small -
there is no way
around this, it's physics / causality.
You can decrease the number of samples of the buffer with
a lower sample
rate,
but not the duration/latency required.

> How can I succeed to shift pitch ?

You wrote you can have a latency of < 100ms, but 100ms
should be
sufficient for this.



___
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



___
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

Re: [music-dsp] Resampling

[Alex Dashevski]

Hi,

I can't understand your answer.  The duration of buffer should be bigger
than duration of pitch because I use WSOLA.
The latency also depends on sample rate and buffer length.

Thanks,
Alex

‫בתאריך שבת, 6 באוק׳ 2018 ב-18:26 מאת ‪gm‬‏ <‪g...@voxangelica.net‬‏>:‬

> Your numbers don't make sense to me but probably I just dont understand it.
>
> The latency should be independent of the sample rate, right?
>
> You search for similarity in the wave, chop it up, and replay the grains
> at different speeds and/or rates.
>
> What you need for this is a certain amount of time of the wave.
>
> If you need a latency of <= 100 ms you can have two wave cycles stored
> of 50ms length / 20 Hz, which should be sufficient, given taht voice is
> ususally well above 20 Hz.
>
> Am 06.10.2018 um 13:45 schrieb Alex Dashevski:
>
> I have project with pitch shifting (resampling with wsola), It implements
> on android NDK.
> Since duration of pitch is ~20ms, I can't use system recommendedB
> parameters for the fast path. for example, for my device: SampleRate:48Khz
> and buffer size 240 samples. That means, duration time is 5ms (< pitch
> duration = 20ms).
> What can I do so I can use recommended parameters because it increases
> latency. For example if I use 48Khz and 240 samples then latency is 66 ms
> but if buffer size is 24000 samples then latency is 300ms.
> I need latency < 100ms.
>
> Thanks,
> Alex
>
> b Fennb moz-do-not-send="true">et...@polyspectral.comb
>
>> You've got it backwards -- downsample means fewer samples. If you have a
>> 240-sample buffer at 48kHz, then resample to 8kHz, you'll have 240/6=40
>> samples.
>>
>> -Ethan
>>
>>
>> On Sat, Oct 6, 2018 at 4:10 AM, Alex Dashevski 
>> wrote:
>>
>>> Hi,
>>> Let's assume that my system has sample rate = 48Khz and audio buffer
>>> size = 240 samples. It should be on RealTime.
>>> Can I do that:
>>>
>>> 1. Dowsampe to 8Khz and buffer size should be 240*6
>>> 2. To do proccessing on buffer 240*6 with 8Khz sample rate.
>>> 3. Upsample to 48khz with original buffer size.
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>> b W W W* b href="mailto:ssjackso...@gmail.com; target="_blank"
>>> moz-do-not-send="true">ssjackso...@gmail.comb
>>>
 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
 andB

 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 
 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
>
>
> b 2018 W -20:56 W W W* b mailto:ssjackso...@gmail.com;
> target="_blank" moz-do-not-send="true">ssjackso...@gmail.comb
>
>>
>>
>> On Wed, Oct 3, 2018 at 3:17 AM Alex Dashevski 
>> 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.
>>
>> B
>>
>>> 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.B 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. 

Re: [music-dsp] Resampling

[Alex Dashevski]

What do you mean "replay" ? duplicate buffer ?
I have the opposite problem. My original buffer size doesn't contain full
cycle of the pitch.
How can I succeed to shift pitch ?

Thanks,
Alex

‫בתאריך שבת, 6 באוק׳ 2018 ב-19:55 מאת ‪gm‬‏ <‪g...@voxangelica.net‬‏>:‬

>
> no, you don't change the buffer size, you just change the playback rate
> (and speed, if you want) of your grains.
>
> For instance, lets say the pitch is 20 Hz, or 50 ms time for one cycle.
>
> You want to change that to 100 Hz.
>
> Then you take 50 ms of audio, and replay this 5 times every 10 ms (with or
> without overlaps, but at the same speed
>
> as the original to maintaine the formants).
>
> Then you take the next 50 ms, and do that again.
>
> For this, you need a buffer size of 50 ms or more.
>
> But to compare two different wave cycles of 50 ms length to find
> similarity, you need a buffer size of 100 ms.
>
> That is your latency required, for 20 Hz.
>
> That is all independent of sample rate, but of course your buffer size in
> samples will be larger for a higher sample rate
>
> and smaller for a lower sample rate. But the times of latency required
> will be the same.
>
> Also, if you to correlation you need less values to calcuate for a lower
> sample rate.
>
> Am 06.10.2018 um 18:27 schrieb Alex Dashevski:
>
> I still don't understand. You change buffer size. Right ?
> But I don't want to change.
>
> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
> g...@voxangelica.netb
>
>>
>> In my example, the buffer is 2 times as long as the lowest possible pitch,
>> for example if your lowest pitch is 20 Hz, you need 50 ms for one wave
>> cycle
>>
>> Think of it as magnetic tape, without sample rate, the minimum requierd
>> latency and the buffer length in milliesconds
>> are independent of sample rate
>> You have 100 ms "magnetic tape", search for similarity, and then chop the
>> tape according to that.
>> Then you have sippets of 50 ms length or smaller.
>> Then you copy these snippets and piece them together again, at a higher
>> or slower rate than before.
>> You can also shrink or lengthen the snippets and change the formants,
>> that ist shift all
>> spectral contant of one snippet up or down.
>>
>>
>>
>>
>> Am 06.10.2018 um 17:58 schrieb Alex Dashevski:
>>
>> Hi,
>>
>> I can't understand your answer.B The duration of buffer should be bigger
>> than duration of pitch because I use WSOLA.
>> The latency also depends on sample rate and buffer length.
>>
>> Thanks,
>> Alex
>>
>> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
>> g...@voxangelica.netb
>>
>>> Your numbers don't make sense to me but probably I just dont understand
>>> it.
>>>
>>> The latency should be independent of the sample rate, right?
>>>
>>> You search for similarity in the wave, chop it up, and replay the grains
>>> at different speeds and/or rates.
>>>
>>> What you need for this is a certain amount of time of the wave.
>>>
>>> If you need a latency of <= 100 ms you can have two wave cycles stored
>>> of 50ms length / 20 Hz, which should be sufficient, given taht voice is
>>> ususally well above 20 Hz.
>>>
>>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
>
> ___
> dupswapdrop: music-dsp mailing 
> listmusic-dsp@music.columbia.eduhttps://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

Re: [music-dsp] Resampling

[gm]

Am 06.10.2018 um 19:07 schrieb Alex Dashevski:

What do you mean "replay" ? duplicate buffer ?


I mean to just read the buffer for the output.
So in my example you play back 10 ms audio (windowed of course), then 
you move your read pointer and play
that audio back again, and so on, untill the next "slice" or "grain" or 
"snippet" of audio is played back.


I have the opposite problem. My original buffer size doesn't contain 
full cycle of the pitch.


then your pitch is too low or your buffer too small - there is no way 
around this, it's physics / causality.
You can decrease the number of samples of the buffer with a lower sample 
rate,

but not the duration/latency required.


How can I succeed to shift pitch ?


You wrote you can have a latency of < 100ms, but 100ms should be 
sufficient for this.




___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

[gm]

right

the latency required is that you need to store the complete wavecycle, 
or two of them, to compare them


(My method works a little bit different, so I only need one wavecycle.)

So you always have this latency, regardless what sample rate you use.

But maybe you dont need 20 Hz, for speech for instance I think that 100 
or even 150 Hz is sufficient? I dont know




Am 06.10.2018 um 19:34 schrieb Alex Dashevski:

If I understand correctly, resampling will not help. Right ?
No other technique that will help. Right ?
What do you mean "but not the duration/latency required" ?

b> b>


Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
> What do you mean "replay" ? duplicate buffer ?

I mean to just read the buffer for the output.
So in my example you play back 10 ms audio (windowed of course), then
you move your read pointer and play
that audio back again, and so on, untill the next "slice" or
"grain" or
"snippet" of audio is played back.

> I have the opposite problem. My original buffer size doesn't
contain
> full cycle of the pitch.

then your pitch is too low or your buffer too small - there is no way
around this, it's physics / causality.
You can decrease the number of samples of the buffer with a lower
sample
rate,
but not the duration/latency required.

> How can I succeed to shift pitch ?

You wrote you can have a latency of < 100ms, but 100ms should be
sufficient for this.



___
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

Re: [music-dsp] Resampling

[gm]

no, you don't change the buffer size, you just change the playback rate 
(and speed, if you want) of your grains.


For instance, lets say the pitch is 20 Hz, or 50 ms time for one cycle.

You want to change that to 100 Hz.

Then you take 50 ms of audio, and replay this 5 times every 10 ms (with 
or without overlaps, but at the same speed


as the original to maintaine the formants).

Then you take the next 50 ms, and do that again.

For this, you need a buffer size of 50 ms or more.

But to compare two different wave cycles of 50 ms length to find 
similarity, you need a buffer size of 100 ms.


That is your latency required, for 20 Hz.

That is all independent of sample rate, but of course your buffer size 
in samples will be larger for a higher sample rate


and smaller for a lower sample rate. But the times of latency required 
will be the same.


Also, if you to correlation you need less values to calcuate for a lower 
sample rate.



Am 06.10.2018 um 18:27 schrieb Alex Dashevski:

I still don't understand. You change buffer size. Right ?
But I don't want to change.

b> b>

In my example, the buffer is 2 times as long as the lowest
possible pitch,
for example if your lowest pitch is 20 Hz, you need 50 ms for one
wave cycle

Think of it as magnetic tape, without sample rate, the minimum
requierd latency and the buffer length in milliesconds
are independent of sample rate
You have 100 ms "magnetic tape", search for similarity, and then
chop the tape according to that.
Then you have sippets of 50 ms length or smaller.
Then you copy these snippets and piece them together again, at a
higher or slower rate than before.
You can also shrink or lengthen the snippets and change the
formants, that ist shift all
spectral contant of one snippet up or down.




Am 06.10.2018 um 17:58 schrieb Alex Dashevski:

Hi,

I can't understand your answer.B The duration of buffer should be
bigger than duration of pitch because I use WSOLA.
The latency also depends on sample rate and buffer length.

Thanks,
Alex

b href="mailto:g...@voxangelica.net "
moz-do-not-send="true">g...@voxangelica.net
b

Your numbers don't make sense to me but probably I just dont
understand it.

The latency should be independent of the sample rate, right?

You search for similarity in the wave, chop it up, and replay
the grains at different speeds and/or rates.

What you need for this is a certain amount of time of the wave.

If you need a latency of <= 100 ms you can have two wave
cycles stored
of 50ms length / 20 Hz, which should be sufficient, given
taht voice is ususally well above 20 Hz.




___
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

Re: [music-dsp] Resampling

[Ethan Duni]

Alex, it sounds like you are confusing algorithmic latency with framing 
latency. At each frame, you take in 10ms (or whatever) of input, and then 
provide 10ms of output. This (plus processing time to generate the output) is 
the IO latency of the process. But the algorithm itself can add additional 
signal delay. 

Consider a simple delay process, wherein the algorithm maintains an internal 
delay buffer. At each 10ms frame, it reads the new input into the end of the 
buffer, and writes out 10ms of output from the front of the buffer. So the IO 
latency is 10ms, but the algorithmic latency is determined by the length of the 
delay buffer.

So if your WSOLA process requires more memory than the IO buffer, then it 
should maintain a longer internal memory. Then for each frame, you first digest 
the input into the buffer, then perform whatever processing to get 1 frame of 
output, and then save whatever state variables you need for the next frame. 
This internal buffer will add signal latency, but not IO latency.

Ethan

> On Oct 6, 2018, at 10:25 AM, gm  wrote:
> 
> 
> 
>> Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
>> What do you mean "replay" ? duplicate buffer ?
> 
> I mean to just read the buffer for the output.
> So in my example you play back 10 ms audio (windowed of course), then you 
> move your read pointer and play
> that audio back again, and so on, untill the next "slice" or "grain" or 
> "snippet" of audio is played back.
> 
>> I have the opposite problem. My original buffer size doesn't contain full 
>> cycle of the pitch.
> 
> then your pitch is too low or your buffer too small - there is no way around 
> this, it's physics / causality.
> You can decrease the number of samples of the buffer with a lower sample rate,
> but not the duration/latency required.
> 
>> How can I succeed to shift pitch ?
> 
> You wrote you can have a latency of < 100ms, but 100ms should be sufficient 
> for this.
> 
> 
> 
> ___
> 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

Re: [music-dsp] Resampling

[Daniel Varela]

You could try a phase vocoder instead of WSOLA for time stretching. Latency
would be the size of the fft block.

El sáb., 6 oct. 2018 19:49, gm  escribió:

>
> right
>
> the latency required is that you need to store the complete wavecycle, or
> two of them, to compare them
>
> (My method works a little bit different, so I only need one wavecycle.)
>
> So you always have this latency, regardless what sample rate you use.
>
> But maybe you dont need 20 Hz, for speech for instance I think that 100 or
> even 150 Hz is sufficient? I dont know
>
>
>
> Am 06.10.2018 um 19:34 schrieb Alex Dashevski:
>
> If I understand correctly, resampling will not help. Right ?
> No other technique that will help. Right ?
> What do you mean "but not the duration/latency required" ?
>
> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
> g...@voxangelica.netb
>
>>
>>
>> Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
>> > What do you mean "replay" ? duplicate buffer ?
>>
>> I mean to just read the buffer for the output.
>> So in my example you play back 10 ms audio (windowed of course), then
>> you move your read pointer and play
>> that audio back again, and so on, untill the next "slice" or "grain" or
>> "snippet" of audio is played back.
>>
>> > I have the opposite problem. My original buffer size doesn't contain
>> > full cycle of the pitch.
>>
>> then your pitch is too low or your buffer too small - there is no way
>> around this, it's physics / causality.
>> You can decrease the number of samples of the buffer with a lower sample
>> rate,
>> but not the duration/latency required.
>>
>> > How can I succeed to shift pitch ?
>>
>> You wrote you can have a latency of < 100ms, but 100ms should be
>> sufficient for this.
>>
>>
>>
>> ___
>> 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

Re: [music-dsp] Resampling

[Alex Dashevski]

Could you know where I can find phase vocoder implementaion in cpp thus I
can run it on real time ?

‫בתאריך שבת, 6 באוק׳ 2018 ב-21:21 מאת ‪Daniel Varela‬‏ <‪
danielvarela...@gmail.com‬‏>:‬

> For real time you will need to do windowing and overlap add. But yeah, 5ms
> should be enough.
>
> This is a high level explanation with MATLAB
>
>
> https://se.mathworks.com/help/audio/examples/pitch-shifting-and-time-dilation-using-a-phase-vocoder-in-matlab.html
>
> El sáb., 6 oct. 2018 20:10, Alex Dashevski  escribió:
>
>> Can you tell what minimum duration of buffer ? 5ms should be Ok ?
>>
>> ‫בתאריך שבת, 6 באוק׳ 2018 ב-21:06 מאת ‪Daniel Varela‬‏ <‪
>> danielvarela...@gmail.com‬‏>:‬
>>
>>> You can process buffers as small as your fft allows.
>>>
>>> El 6 oct. 2018 20:03, "Alex Dashevski"  escribió:
>>>
>>> Hi,
>>> phase vocoder doesn't have restriction of duration ?
>>> Thanks,
>>> Alex
>>>
>>> ‫בתאריך שבת, 6 באוק׳ 2018 ב-20:55 מאת ‪Daniel Varela‬‏ <‪
>>> danielvarela...@gmail.com‬‏>:‬
>>>
 You could try a phase vocoder instead of WSOLA for time stretching.
 Latency would be the size of the fft block.

 El sáb., 6 oct. 2018 19:49, gm  escribió:

>
> right
>
> the latency required is that you need to store the complete wavecycle,
> or two of them, to compare them
>
> (My method works a little bit different, so I only need one wavecycle.)
>
> So you always have this latency, regardless what sample rate you use.
>
> But maybe you dont need 20 Hz, for speech for instance I think that
> 100 or even 150 Hz is sufficient? I dont know
>
>
>
> Am 06.10.2018 um 19:34 schrieb Alex Dashevski:
>
> If I understand correctly, resampling will not help. Right ?
> No other technique that will help. Right ?
> What do you mean "but not the duration/latency required" ?
>
> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
> g...@voxangelica.netb
>
>>
>>
>> Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
>> > What do you mean "replay" ? duplicate buffer ?
>>
>> I mean to just read the buffer for the output.
>> So in my example you play back 10 ms audio (windowed of course), then
>> you move your read pointer and play
>> that audio back again, and so on, untill the next "slice" or "grain"
>> or
>> "snippet" of audio is played back.
>>
>> > I have the opposite problem. My original buffer size doesn't
>> contain
>> > full cycle of the pitch.
>>
>> then your pitch is too low or your buffer too small - there is no way
>> around this, it's physics / causality.
>> You can decrease the number of samples of the buffer with a lower
>> sample
>> rate,
>> but not the duration/latency required.
>>
>> > How can I succeed to shift pitch ?
>>
>> You wrote you can have a latency of < 100ms, but 100ms should be
>> sufficient for this.
>>
>>
>>
>> ___
>> 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
>>>
>>>
>>>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

[Scott Cotton]

sorry, dropped a phrase by accident: shouldn't be too hard -- to use --.

On Sat, 6 Oct 2018 at 22:14, Scott Cotton  wrote:

> The best open source one I know of is
> https://breakfastquay.com/rubberband/
>
> It is however very dense.  I wouldn't bet on coming to an understanding of
> how it does sample/window framing without significant investment.  The
> author himself said it was very hard to get sample accurate input samples
> to output samples ratios.
>
> However, to use it shouldn't be too hard.
>
> Scott
>
> On Sat, 6 Oct 2018 at 20:53, Alex Dashevski  wrote:
>
>> Could you know where I can find phase vocoder implementaion in cpp thus I
>> can run it on real time ?
>>
>> ‫בתאריך שבת, 6 באוק׳ 2018 ב-21:21 מאת ‪Daniel Varela‬‏ <‪
>> danielvarela...@gmail.com‬‏>:‬
>>
>>> For real time you will need to do windowing and overlap add. But yeah,
>>> 5ms should be enough.
>>>
>>> This is a high level explanation with MATLAB
>>>
>>>
>>> https://se.mathworks.com/help/audio/examples/pitch-shifting-and-time-dilation-using-a-phase-vocoder-in-matlab.html
>>>
>>> El sáb., 6 oct. 2018 20:10, Alex Dashevski 
>>> escribió:
>>>
 Can you tell what minimum duration of buffer ? 5ms should be Ok ?

 ‫בתאריך שבת, 6 באוק׳ 2018 ב-21:06 מאת ‪Daniel Varela‬‏ <‪
 danielvarela...@gmail.com‬‏>:‬

> You can process buffers as small as your fft allows.
>
> El 6 oct. 2018 20:03, "Alex Dashevski"  escribió:
>
> Hi,
> phase vocoder doesn't have restriction of duration ?
> Thanks,
> Alex
>
> ‫בתאריך שבת, 6 באוק׳ 2018 ב-20:55 מאת ‪Daniel Varela‬‏ <‪
> danielvarela...@gmail.com‬‏>:‬
>
>> You could try a phase vocoder instead of WSOLA for time stretching.
>> Latency would be the size of the fft block.
>>
>> El sáb., 6 oct. 2018 19:49, gm  escribió:
>>
>>>
>>> right
>>>
>>> the latency required is that you need to store the complete
>>> wavecycle, or two of them, to compare them
>>>
>>> (My method works a little bit different, so I only need one
>>> wavecycle.)
>>>
>>> So you always have this latency, regardless what sample rate you use.
>>>
>>> But maybe you dont need 20 Hz, for speech for instance I think that
>>> 100 or even 150 Hz is sufficient? I dont know
>>>
>>>
>>>
>>> Am 06.10.2018 um 19:34 schrieb Alex Dashevski:
>>>
>>> If I understand correctly, resampling will not help. Right ?
>>> No other technique that will help. Right ?
>>> What do you mean "but not the duration/latency required" ?
>>>
>>> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
>>> g...@voxangelica.netb
>>>


 Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
 > What do you mean "replay" ? duplicate buffer ?

 I mean to just read the buffer for the output.
 So in my example you play back 10 ms audio (windowed of course),
 then
 you move your read pointer and play
 that audio back again, and so on, untill the next "slice" or
 "grain" or
 "snippet" of audio is played back.

 > I have the opposite problem. My original buffer size doesn't
 contain
 > full cycle of the pitch.

 then your pitch is too low or your buffer too small - there is no
 way
 around this, it's physics / causality.
 You can decrease the number of samples of the buffer with a lower
 sample
 rate,
 but not the duration/latency required.

 > How can I succeed to shift pitch ?

 You wrote you can have a latency of < 100ms, but 100ms should be
 sufficient for this.



 ___
 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
>
>
> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
>
> --
> Scott Cotton
> http://www.iri-labs.com
>
>
>

-- 
Scott Cotton
http://www.iri-labs.com
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

[Scott Cotton]

The best open source one I know of is https://breakfastquay.com/rubberband/

It is however very dense.  I wouldn't bet on coming to an understanding of
how it does sample/window framing without significant investment.  The
author himself said it was very hard to get sample accurate input samples
to output samples ratios.

However, to use it shouldn't be too hard.

Scott

On Sat, 6 Oct 2018 at 20:53, Alex Dashevski  wrote:

> Could you know where I can find phase vocoder implementaion in cpp thus I
> can run it on real time ?
>
> ‫בתאריך שבת, 6 באוק׳ 2018 ב-21:21 מאת ‪Daniel Varela‬‏ <‪
> danielvarela...@gmail.com‬‏>:‬
>
>> For real time you will need to do windowing and overlap add. But yeah,
>> 5ms should be enough.
>>
>> This is a high level explanation with MATLAB
>>
>>
>> https://se.mathworks.com/help/audio/examples/pitch-shifting-and-time-dilation-using-a-phase-vocoder-in-matlab.html
>>
>> El sáb., 6 oct. 2018 20:10, Alex Dashevski  escribió:
>>
>>> Can you tell what minimum duration of buffer ? 5ms should be Ok ?
>>>
>>> ‫בתאריך שבת, 6 באוק׳ 2018 ב-21:06 מאת ‪Daniel Varela‬‏ <‪
>>> danielvarela...@gmail.com‬‏>:‬
>>>
 You can process buffers as small as your fft allows.

 El 6 oct. 2018 20:03, "Alex Dashevski"  escribió:

 Hi,
 phase vocoder doesn't have restriction of duration ?
 Thanks,
 Alex

 ‫בתאריך שבת, 6 באוק׳ 2018 ב-20:55 מאת ‪Daniel Varela‬‏ <‪
 danielvarela...@gmail.com‬‏>:‬

> You could try a phase vocoder instead of WSOLA for time stretching.
> Latency would be the size of the fft block.
>
> El sáb., 6 oct. 2018 19:49, gm  escribió:
>
>>
>> right
>>
>> the latency required is that you need to store the complete
>> wavecycle, or two of them, to compare them
>>
>> (My method works a little bit different, so I only need one
>> wavecycle.)
>>
>> So you always have this latency, regardless what sample rate you use.
>>
>> But maybe you dont need 20 Hz, for speech for instance I think that
>> 100 or even 150 Hz is sufficient? I dont know
>>
>>
>>
>> Am 06.10.2018 um 19:34 schrieb Alex Dashevski:
>>
>> If I understand correctly, resampling will not help. Right ?
>> No other technique that will help. Right ?
>> What do you mean "but not the duration/latency required" ?
>>
>> b href="mailto:g...@voxangelica.net; moz-do-not-send="true">
>> g...@voxangelica.netb
>>
>>>
>>>
>>> Am 06.10.2018 um 19:07 schrieb Alex Dashevski:
>>> > What do you mean "replay" ? duplicate buffer ?
>>>
>>> I mean to just read the buffer for the output.
>>> So in my example you play back 10 ms audio (windowed of course),
>>> then
>>> you move your read pointer and play
>>> that audio back again, and so on, untill the next "slice" or "grain"
>>> or
>>> "snippet" of audio is played back.
>>>
>>> > I have the opposite problem. My original buffer size doesn't
>>> contain
>>> > full cycle of the pitch.
>>>
>>> then your pitch is too low or your buffer too small - there is no
>>> way
>>> around this, it's physics / causality.
>>> You can decrease the number of samples of the buffer with a lower
>>> sample
>>> rate,
>>> but not the duration/latency required.
>>>
>>> > How can I succeed to shift pitch ?
>>>
>>> You wrote you can have a latency of < 100ms, but 100ms should be
>>> sufficient for this.
>>>
>>>
>>>
>>> ___
>>> 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


 ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp



-- 
Scott Cotton
http://www.iri-labs.com
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp