[Speex-dev] FFT Resampler

[Thorvald Natvig]

>>  Yes, I plan to use it in a VoIP environment if I can get latency reduced to
>> an acceptable level :)
>>  The latency depends directly on the overlap parameter, which also controls
>> the quality. Higher quality => higher latency. You could set the overlap to
>> 0, but that would give you some nasty artifacts.
>>  You can also resample with smaller block sizes. In the example I used 20ms
>> blocks and 50% overlap. If you use 10ms blocks and 50% overlap, latency
>> sinks to 5ms.
>>     
>
> How quality and CPU usage depends from block size?
> Looking at edge case - 1 sample blocks - I should have <1 sample latency,
> but something should be  wrong here, e.g. required CPU power may be
> infinite, no? :)
>   
Higher block size and more overlap => higher CPU. The idea is to let the 
block size be whatever block size you use for the rest of your program. 
For Speex, 20ms is perfect.
Lower overlap will give less CPU requirements, but also introduce 
artifacts in the resampling.
>>  It could be 50% overlap is complete overkill. It could be it's not enough.
>> It could be how much overlap you need depends on the block size. I need to
>> do some quality testing before I can say for sure :)
>>     
> *nod*
> Also comparison with standard resampler would be very useful. Probably
> the best way would be to take standard resampler as a reference
> and see how much latency/CPU is needed to reach each of its complexity
> levels. This would give clear idea of what's going, even for people
> who unaware of implementation details.
>   
That's the idea, I just haven't gotten that far :)
>
>>> What is input and output latency? As a user, I think there is only one
>>>       
>> latency,
>>     
>>> latency between data I passed to resampler and data I've got from it.
>>> I suppose there may be some internal idea behind this division of latency,
>>> but is end user interested in it?
>>>
>>>
>>>       
>>  It's copied directly from the speex_resampler.h; it's the same latency, but
>> measured in input and output samples. So if I resample from a blocksize of
>> 320 to 960 with 50% overlap, the input latency is 160 samples and the output
>> latency is 480 samples.
>>     
>
> Aha, got it. Documentation is very unclear at this point. =\ It should be
> something like what you've written, e.g. "Latency, measured in samples
> at input (output) sample rate".
>   
I must admit I didn't get the difference either until I checked the 
source for the original resampler. I'll see if we can't reword both of 
them to make it more clear.