subject:"\[music\-dsp\] Resampling"

Re: [music-dsp] Resampling

2018-10-07 Thread Scott Cotton

On Sun, 7 Oct 2018 at 08:20, Alex Dashevski  wrote:

> is it phase vocoder ?
>

I am not the author, so take with a grain of salt: Yes, but it treats the
input to output sample ratio
differently than say a standard pv in matlab.




> I can't understand how it work.
>

welcome to the world of closed ideas by open source obscurity :)  I wish
the author would publish a clear
explanation, it would save lots of folks lots of time.  But it would also
make things easier for its competitors...

That said, I think there are examples and clear docs of how to use it, and
the web page probably provides
better forum and access to usage than this list.


Scott



>
> ‫בתאריך שבת, 6 באוק׳ 2018 ב-23:15 מאת ‪Scott Cotton‬‏ <‪w...@iri-labs.com
> ‬‏>:‬
>
>> 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

Re: [music-dsp] Resampling

2018-10-07 Thread Alex Dashevski

is it phase vocoder ?
I can't understand how it work.

‫בתאריך שבת, 6 באוק׳ 2018 ב-23:15 מאת ‪Scott Cotton‬‏ <‪w...@iri-labs.com
‬‏>:‬

> 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

Re: [music-dsp] Resampling

2018-10-06 Thread 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

2018-10-06 Thread 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

Re: [music-dsp] Resampling

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-06 Thread 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

2018-10-03 Thread Spencer Jackson

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

Re: [music-dsp] Resampling

2018-10-03 Thread Alex Dashevski

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

Re: [music-dsp] Resampling

2018-10-03 Thread Spencer Jackson

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

[music-dsp] Resampling

2018-10-03 Thread Alex Dashevski

Hi,

I use a sample rate :48Khz and buffer size = 240 samples.
I made pitch shifting with WSOLA and resampling.
But pitch duration is ~20ms then I need decrease rate sample or increase
buffer size. As a result of it, the delay will increase.
if I do resampling before and after processing. for example, 48Khz -> 8Khz
and then 8Khz -> 48Khz then will it help ?
If so, how should do ? I don't understand why I need filter, This is to
prevent alias but I can't understand why ?

Is there option to decrease latency or delay ?

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

Re: [music-dsp] resampling

2018-07-25 Thread Tom O'Hara



On 7/26/2018 2:27 AM, rolfsassin...@web.de wrote:
Regarding Tom's remark:  Using the copied samples also requires no 
additional multiplcation since the value is already stored and in use (?)


No, they require multiplication and addition as, while the samples are 
the same, each coefficient is different.  A zero x coefficient = zero, 
so no need to multiply or add.


Tom

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

Re: [music-dsp] resampling

2018-07-25 Thread rolfsassinger


Ok, I had a closer look, but will have to get deeper I think, since i did not fully got this.
According to my simulations, using copied samples does sometimes better.
Maybe a question of intelligent filter design.

Regarding Tom's remark:  Using the copied samples also requires no additional multiplcation since the value is already stored and in use (?)

Anyway thanks.

 

Rolf

 

 

Gesendet: Dienstag, 24. Juli 2018 um 18:36 Uhr
Von: "Nigel Redmon" 
An: music-dsp@music.columbia.edu
Betreff: Re: [music-dsp] resampling


(Not sure why I didn’t receive Rolf’s email directly…)
 

Hi Rolf,
 

First, I should have pointed to this newer series of articles (of mine), not old ones, earlier in this thread. You’ll get a detailed explanation of why zeroes (and as Alex points out, the zeros can be handled efficiently so it’s a good thing anyway):

 

http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC

 

Nigel

 
 

On Jul 24, 2018, at 7:53 AM, Tom O'Hara <tom_i...@ticino.com> wrote:
 



Adding zeros is an advantage as then you don't need to calculate their multiplication, as 0 x coefficient = 0

The filter order will be the same with zeros or repeated samples.

Tom
 

On 7/24/2018 4:37 PM, rolfsassin...@web.de wrote:




Hello Nigel

 

could you please say a word more to what you mean by "2x", "3x"?

Also I am again not sure why in this case, adding zeros is an advantage. I had expected to just copy the samples to have less work to do in filtering. I tested such things in MATLAB and found that feeding zeros needs more filter TAPs to come to the same result.

 

Rolf

 

 

Gesendet: Montag, 23. Juli 2018 um 18:25 Uhr
Von: "Nigel Redmon" 
An: music-dsp@music.columbia.edu
Betreff: Re: [music-dsp] resampling



Some articles on my website: http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/, especially the 2010 articles, but the Amp Sim article might be a helpful overview.

 

48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, throw away 5, repeat.

 

8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, repeat; filter with a lowpass filter with cutoff below 4k.

 







 

	
		
			
			Virus-free. www.avg.com
		
	

 
 

 
 

___
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

2018-07-24 Thread Nigel Redmon

Oops, meant “as Tom points out…”

> On Jul 24, 2018, at 9:36 AM, Nigel Redmon  wrote:
> 
> (Not sure why I didn’t receive Rolf’s email directly…)
> 
> Hi Rolf,
> 
> First, I should have pointed to this newer series of articles (of mine), not 
> old ones, earlier in this thread. You’ll get a detailed explanation of why 
> zeroes (and as Alex points out, the zeros can be handled efficiently so it’s 
> a good thing anyway):
> 
> http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC 
> <http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC>
> 
> Nigel
> 
> 
>> On Jul 24, 2018, at 7:53 AM, Tom O'Hara > <mailto:tom_i...@ticino.com>> wrote:
>> 
>> Adding zeros is an advantage as then you don't need to calculate their 
>> multiplication, as 0 x coefficient = 0
>> 
>> The filter order will be the same with zeros or repeated samples.
>> Tom
>> 
>> On 7/24/2018 4:37 PM, rolfsassin...@web.de <mailto:rolfsassin...@web.de> 
>> wrote:
>>> Hello Nigel
>>>  
>>> could you please say a word more to what you mean by "2x", "3x"?
>>> 
>>> Also I am again not sure why in this case, adding zeros is an advantage. I 
>>> had expected to just copy the samples to have less work to do in filtering. 
>>> I tested such things in MATLAB and found that feeding zeros needs more 
>>> filter TAPs to come to the same result.
>>>  
>>> Rolf
>>>  
>>>  
>>> Gesendet: Montag, 23. Juli 2018 um 18:25 Uhr
>>> Von: "Nigel Redmon"  <mailto:earle...@earlevel.com>
>>> An: music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>>> Betreff: Re: [music-dsp] resampling
>>> Some articles on my website: 
>>> http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/ 
>>> <http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/>,
>>>  especially the 2010 articles, but the Amp Sim article might be a helpful 
>>> overview.
>>>  
>>> 48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, throw 
>>> away 5, repeat.
>>>  
>>> 8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, repeat; 
>>> filter with a lowpass filter with cutoff below 4k.
>>>  
>>> 
>>>  
>>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>>>Virus-free. www.avg.com 
>>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>>>  
>>> 
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp 
>>> <https://lists.columbia.edu/mailman/listinfo/music-dsp>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu <mailto: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

2018-07-24 Thread Nigel Redmon

(Not sure why I didn’t receive Rolf’s email directly…)

Hi Rolf,

First, I should have pointed to this newer series of articles (of mine), not 
old ones, earlier in this thread. You’ll get a detailed explanation of why 
zeroes (and as Alex points out, the zeros can be handled efficiently so it’s a 
good thing anyway):

http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC 
<http://www.earlevel.com/main/tag/sampling-theory-series/?order=ASC>

Nigel


> On Jul 24, 2018, at 7:53 AM, Tom O'Hara  wrote:
> 
> Adding zeros is an advantage as then you don't need to calculate their 
> multiplication, as 0 x coefficient = 0
> 
> The filter order will be the same with zeros or repeated samples.
> Tom
> 
> On 7/24/2018 4:37 PM, rolfsassin...@web.de <mailto:rolfsassin...@web.de> 
> wrote:
>> Hello Nigel
>>  
>> could you please say a word more to what you mean by "2x", "3x"?
>> 
>> Also I am again not sure why in this case, adding zeros is an advantage. I 
>> had expected to just copy the samples to have less work to do in filtering. 
>> I tested such things in MATLAB and found that feeding zeros needs more 
>> filter TAPs to come to the same result.
>>  
>> Rolf
>>  
>>  
>> Gesendet: Montag, 23. Juli 2018 um 18:25 Uhr
>> Von: "Nigel Redmon"  <mailto:earle...@earlevel.com>
>> An: music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>> Betreff: Re: [music-dsp] resampling
>> Some articles on my website: 
>> http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/ 
>> <http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/>,
>>  especially the 2010 articles, but the Amp Sim article might be a helpful 
>> overview.
>>  
>> 48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, throw 
>> away 5, repeat.
>>  
>> 8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, repeat; 
>> filter with a lowpass filter with cutoff below 4k.
>>  
>> 
>>  
>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>> Virus-free. www.avg.com 
>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>>  
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu <mailto:music-dsp@music.columbia.edu>
>> https://lists.columbia.edu/mailman/listinfo/music-dsp 
>> <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

2018-07-24 Thread Tom O'Hara

Adding zeros is an advantage as then you don't need to calculate their 
multiplication, as 0 x coefficient = 0


The filter order will be the same with zeros or repeated samples.

Tom


On 7/24/2018 4:37 PM, rolfsassin...@web.de wrote:

Hello Nigel
could you please say a word more to what you mean by "2x", "3x"?

Also I am again not sure why in this case, adding zeros is an 
advantage. I had expected to just copy the samples to have less work 
to do in filtering. I tested such things in MATLAB and found that 
feeding zeros needs more filter TAPs to come to the same result.

Rolf
*Gesendet:* Montag, 23. Juli 2018 um 18:25 Uhr
*Von:* "Nigel Redmon" 
*An:* music-dsp@music.columbia.edu
*Betreff:* Re: [music-dsp] resampling
Some articles on my website: 
http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/, 
especially the 2010 articles, but the Amp Sim article might be a 
helpful overview.
48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, 
throw away 5, repeat.
8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, 
repeat; filter with a lowpass filter with cutoff below 4k.


<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free. www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
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

2018-07-24 Thread rolfsassinger


Hello Nigel

 

could you please say a word more to what you mean by "2x", "3x"?

Also I am again not sure why in this case, adding zeros is an advantage. I had expected to just copy the samples to have less work to do in filtering. I tested such things in MATLAB and found that feeding zeros needs more filter TAPs to come to the same result.

 

Rolf

 

 

Gesendet: Montag, 23. Juli 2018 um 18:25 Uhr
Von: "Nigel Redmon" 
An: music-dsp@music.columbia.edu
Betreff: Re: [music-dsp] resampling



Some articles on my website: http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/, especially the 2010 articles, but the Amp Sim article might be a helpful overview.

 

48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, throw away 5, repeat.

 

8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, repeat; filter with a lowpass filter with cutoff below 4k.

 





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

Re: [music-dsp] resampling

2018-07-24 Thread Alex Dashevski

Hi,
I need to do resampling on android.
Could you give me code on c/c++/Java?

On Tue, Jul 24, 2018, 08:56 Tom O'Hara  wrote:

> I've done many resamplers over the decades (48<->32, 24,16,8) and always
> used FIRs for these reasons.
>
> Tom
>
> On 7/23/2018 6:25 PM, Nigel Redmon wrote:
> > Some articles on my website:
> >
> http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/,
>
> > especially the 2010 articles, but the Amp Sim article might be a
> > helpful overview.
> >
> > 48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample,
> > throw away 5, repeat.
> >
> > 8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value,
> > repeat; filter with a lowpass filter with cutoff below 4k.
> >
> > Nuances:
> >
> > A linear phase FIR is a popular choice for the lowpass filter (odd
> > length, Kaiser windowed sinc is a good choice). In downsampling, you
> > don’t have to calculate the samples you intend to discard, and in
> > upsampling, you don’t need to do the operations for added 0-valued
> > samples.
> >
> > You want the filter stop band (above 4k) to have suitable attenuation
> > (Kaiser is nice for this, because you can specify it, trading off with
> > transition sharpness).
> >
> > Advance topic: You can optimize performance by doing it in two stages
> > (3x, 2x). You win by noting that the first stage doesn’t have to be
> > perfect, and long as the second stage cleans up after it.
> >
>
> ___
> 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

2018-07-23 Thread Tom O'Hara

I've done many resamplers over the decades (48<->32, 24,16,8) and always 
used FIRs for these reasons.


Tom

On 7/23/2018 6:25 PM, Nigel Redmon wrote:
Some articles on my website: 
http://www.earlevel.com/main/category/digital-audio/sample-rate-conversion/, 
especially the 2010 articles, but the Amp Sim article might be a 
helpful overview.


48k -> 8k: Filter with a lowpass with cutoff below 4k; keep 1 sample, 
throw away 5, repeat.


8k -> 48k: Use 1 sample, follow it with 5 new samples of 0 value, 
repeat; filter with a lowpass filter with cutoff below 4k.


Nuances:

A linear phase FIR is a popular choice for the lowpass filter (odd 
length, Kaiser windowed sinc is a good choice). In downsampling, you 
don’t have to calculate the samples you intend to discard, and in 
upsampling, you don’t need to do the operations for added 0-valued 
samples.


You want the filter stop band (above 4k) to have suitable attenuation 
(Kaiser is nice for this, because you can specify it, trading off with 
transition sharpness).


Advance topic: You can optimize performance by doing it in two stages 
(3x, 2x). You win by noting that the first stage doesn’t have to be 
perfect, and long as the second stage cleans up after it.




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

Re: [music-dsp] resampling

2018-07-23 Thread Felix Homann

libsamplerate, aka Secret Rabbit Code, has been relicensed under a 2 clause
BSD license a while ago. Maybe you want to give it a try:

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

Re: [music-dsp] resampling

2018-07-23 Thread Kjetil Matheussen

On Mon, Jul 23, 2018 at 3:08 AM, Henrik G. Sundt  wrote:

> This solution, without using any low pass filters before and after the
> desimation, will generate a lot of aliasing frequencies, Kjetil!
>
> Here is another solution:
> https://github.com/intervigilium/libresample/tree/master/jni/resample
>
>
For linear interpolation, here is a version that's easier to read:

currReadPos = 2.0;
prevVal = 0.0;
nextVal = 0.0;

float getOutputSample(){
  while(currReadPos > 1.0){
currReadPos-=1.0;
prevVal=nextVal;
nextVal=getInputSample();
  }
  float ret = prevVal + currReadPos * (nextVal-prevVal);
  currReadPos += (input_samplerate / output_samplerate);

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

Re: [music-dsp] resampling

2018-07-23 Thread Kjetil Matheussen

On Mon, Jul 23, 2018 at 3:08 AM, Henrik G. Sundt  wrote:

> This solution, without using any low pass filters before and after the
> desimation, will generate a lot of aliasing frequencies, Kjetil!
>
>
No doubt. I did write "Not the best sound quality though." :-)
Alex didn't write about his knowledge level etc., so I just showed the
simplest resampler, in case it would be useful.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] resampling

2018-07-22 Thread Sound of L.A. Music and Audio



This code is also dangerous "LGPL" :-)

Seriously, I'm afraid this is also too much for him. Code is not really 
good to explain solutions. I prefer the clarification and let people 
code themselves.


Let's try it this way:

1. Apply an anti aliasing filter with an edge frequency of about 2..3kHz 
and a stop frequency of not more than 4kHz to meet the 8kHz sampling 
rate. Do not use only linear interpolation but CIC + FIR. For simple 
approaches use an IIR. A nice filter was a 6x4 TAP FIR Filter and a 3kHz 
edge.


2. Pick up every 6th sample to get 8kHz

3. Appreciate a dark sound without any "s", "t" ... :-)


To transform back to 48kHz

1. use a linear interpolation with a one stage CIC. Do not use the often 
proposed filling with zeros. For simple solutions use the smaple 6 times.


2. Apply a short 12 TAP - FIR filter with an edge frequency of 16kHz 
which has easy coefficients for 48kHz and reduces artifacts from the 
linear interpolation.


3. This should maintain the 8kHz quality without new degradation

Jürgen


Am 23.07.2018 um 03:08 schrieb Henrik G. Sundt:
This solution, without using any low pass filters before and after the 
desimation, will generate a lot of aliasing frequencies, Kjetil!


Here is another solution:
https://github.com/intervigilium/libresample/tree/master/jni/resample

Henrik


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

Re: [music-dsp] resampling

2018-07-22 Thread Henrik G. Sundt

This solution, without using any low pass filters before and after the 
desimation, will generate a lot of aliasing frequencies, Kjetil!


Here is another solution:
https://github.com/intervigilium/libresample/tree/master/jni/resample

Henrik


On 22.07.2018 22:22, Kjetil Matheussen wrote:

Maybe this will give you an idea:

48khz -> 8khz:
float get_output_sample(get_input_sample){
   static int i=0;
   static float sample;

  if (i % 6 == 0)
 sample = get_input_sample();

  i++;

  return sample;
}

8khz -> 48khz:
float get_output_sample(get_input_sample){

   float ret = get_input_sample();

   for(int i=1;i<6;i++)
  get_input_sample();

   return ret;
}

Not the best sound quality though.

On Sun, Jul 22, 2018 at 9:55 PM, Alex Dashevski 
wrote:


real time

On Sun, Jul 22, 2018, 22:52 jpff  wrote:


Were you expecting real-time/time-critical resampling or offline?

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


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




Links:
--
[1] 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

2018-07-22 Thread Alex Dashevski

where is low pass filter?

On Sun, Jul 22, 2018, 23:22 Kjetil Matheussen 
wrote:

> Maybe this will give you an idea:
>
> 48khz -> 8khz:
> float get_output_sample(get_input_sample){
>static int i=0;
>static float sample;
>
>   if (i % 6 == 0)
>  sample = get_input_sample();
>
>   i++;
>
>   return sample;
> }
>
> 8khz -> 48khz:
> float get_output_sample(get_input_sample){
>float ret = get_input_sample();
>
>for(int i=1;i<6;i++)
>   get_input_sample();
>
>return ret;
> }
>
> Not the best sound quality though.
>
>
> On Sun, Jul 22, 2018 at 9:55 PM, Alex Dashevski 
> wrote:
>
>> real time
>>
>> On Sun, Jul 22, 2018, 22:52 jpff  wrote:
>>
>>> Were you expecting real-time/time-critical resampling or offline?
>>>
>>> ___
>>> 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

2018-07-22 Thread Kjetil Matheussen

Maybe this will give you an idea:

48khz -> 8khz:
float get_output_sample(get_input_sample){
   static int i=0;
   static float sample;

  if (i % 6 == 0)
 sample = get_input_sample();

  i++;

  return sample;
}

8khz -> 48khz:
float get_output_sample(get_input_sample){
   float ret = get_input_sample();

   for(int i=1;i<6;i++)
  get_input_sample();

   return ret;
}

Not the best sound quality though.


On Sun, Jul 22, 2018 at 9:55 PM, Alex Dashevski  wrote:

> real time
>
> On Sun, Jul 22, 2018, 22:52 jpff  wrote:
>
>> Were you expecting real-time/time-critical resampling or offline?
>>
>> ___
>> 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

2018-07-22 Thread Alex Dashevski

real time

On Sun, Jul 22, 2018, 22:52 jpff  wrote:

> Were you expecting real-time/time-critical resampling or offline?
>
> ___
> 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

2018-07-22 Thread jpff


Were you expecting real-time/time-critical resampling or offline?

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

Re: [music-dsp] resampling

2018-07-22 Thread Alex Dashevski

This is even more incomprehensible.
I'm looking for a simple example of code and explanation how to convert
signal of 48Khz freq samples to 8Kh ,do processing of signal and convert
8Khz to 48Khz freq samples.
Thanks,
Alex

2018-07-22 22:28 GMT+03:00 Vladimir Pantelic :

> https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
>
> On Sun, Jul 22, 2018, 21:23 Alex Dashevski  wrote:
>
>> Hi,
>> Could you explain how to use with LGPL ? I can't understand it.
>> Thanks,
>> Alex
>>
>> 2018-07-19 21:28 GMT+03:00 Esteban Maestre :
>>
>>> Hi Alex,
>>>
>>>
>>> This is a good read:
>>>
>>> https://ccrma.stanford.edu/~jos/resample/
>>>
>>>
>>> Using Google, I found somebody who used the LGPL code available at
>>> Julius' site:
>>>
>>> https://github.com/intervigilium/libresample
>>>
>>>
>>> Good luck!
>>>
>>> Esteban
>>>
>>> On 7/19/2018 2:15 PM, Alex Dashevski wrote:
>>>
>>> Hi,
>>>
>>> I need to convert 48Khz to 8KHz on input and convert 8Khz to 48Khz on
>>> audio on output.
>>> Could you explain how to do it ?
>>> I need to implement this on android(NDK).
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>> ___
>>> dupswapdrop: music-dsp mailing 
>>> listmusic-dsp@music.columbia.eduhttps://lists.columbia.edu/mailman/listinfo/music-dsp
>>>
>>>
>>> --
>>>
>>> Esteban Maestre
>>> Computational Acoustic Modeling Lab
>>> Department of Music Research, McGill 
>>> Universityhttp://ccrma.stanford.edu/~esteban
>>>
>>>
>>> ___
>>> 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

2018-07-22 Thread Vladimir Pantelic

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

On Sun, Jul 22, 2018, 21:23 Alex Dashevski  wrote:

> Hi,
> Could you explain how to use with LGPL ? I can't understand it.
> Thanks,
> Alex
>
> 2018-07-19 21:28 GMT+03:00 Esteban Maestre :
>
>> Hi Alex,
>>
>>
>> This is a good read:
>>
>> https://ccrma.stanford.edu/~jos/resample/
>>
>>
>> Using Google, I found somebody who used the LGPL code available at
>> Julius' site:
>>
>> https://github.com/intervigilium/libresample
>>
>>
>> Good luck!
>>
>> Esteban
>>
>> On 7/19/2018 2:15 PM, Alex Dashevski wrote:
>>
>> Hi,
>>
>> I need to convert 48Khz to 8KHz on input and convert 8Khz to 48Khz on
>> audio on output.
>> Could you explain how to do it ?
>> I need to implement this on android(NDK).
>>
>> Thanks,
>> Alex
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing 
>> listmusic-dsp@music.columbia.eduhttps://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>>
>> --
>>
>> Esteban Maestre
>> Computational Acoustic Modeling Lab
>> Department of Music Research, McGill 
>> Universityhttp://ccrma.stanford.edu/~esteban
>>
>>
>> ___
>> 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

2018-07-19 Thread Esteban Maestre


Hi Alex,


This is a good read:

https://ccrma.stanford.edu/~jos/resample/


Using Google, I found somebody who used the LGPL code available at 
Julius' site:


https://github.com/intervigilium/libresample


Good luck!

Esteban


On 7/19/2018 2:15 PM, Alex Dashevski wrote:

Hi,

I need to convert 48Khz to 8KHz on input and convert 8Khz to 48Khz on 
audio on output.

Could you explain how to do it ?
I need to implement this on android(NDK).
Thanks,
Alex


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


--

Esteban Maestre
Computational Acoustic Modeling Lab
Department of Music Research, McGill University
http://ccrma.stanford.edu/~esteban

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

[music-dsp] resampling

2018-07-19 Thread Alex Dashevski

Hi,

I need to convert 48Khz to 8KHz on input and convert 8Khz to 48Khz on audio
on output.
Could you explain how to do it ?
I need to implement this on android(NDK).

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

46 matches

Mail list logo