Attached is a snapshot of work-in-progress of a FFT based resampler. At the moment it works in floating point only, and only basic quality inspection has been done. Some benchmarks comparing the filter-based resampler at Q3 with the FFT resampler with overlap = in_len / 2, using 20ms chunks of data. (-O3 -ffast-math, FFTW3, gcc 4.3.0 on x86_64) 16=>48: 59us vs 19us 16=>44.1: 204us vs 34us 16=>8: 13us vs 7us 48=>8: 32us vs 16us This is actually much faster than I expected. With -O3, the overhead of copying, applying window etc is 20%. With all options, the overhead sinks to 10%. I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, and there aren't any obvious artifacts. I also did a 16=>16 test, and the results are delayed by 10ms and within +/- 1 (basically, rounding errors from the FFT). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: speex-block-snapshot.diff Url: http://lists.xiph.org/pipermail/speex-dev/attachments/20080529/6819bbbe/attachment.txt
Hi, Here are some questions from user point of view. :) On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote:> I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, > and there aren't any obvious artifacts. I also did a 16=>16 test, and the > results are delayed by 10ms and within +/- 1 (basically, rounding errors > from the FFT).Do you plan to use it in VoIP environment? If so, 10ms of additional latency is a big cost for resampling. Do you think there are any ways to reduce it?> +/** Get the latency in input samples introduced by the resampler. > + * @param st Resampler state > + * @return Latency in input samples. > + */ > +int > speex_block_resampler_get_input_latency(SpeexBlockResamplerState > *st); > + > +/** Get the latency in output samples introduced by the resampler. > + * @param st Resampler state > + * @return Latency in output samples. > + */ > +int > speex_block_resampler_get_output_latency(SpeexBlockResamplerState > *st);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? -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
Alexander Chemeris wrote:> Hi, > > Here are some questions from user point of view. :) > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, >> and there aren't any obvious artifacts. I also did a 16=>16 test, and the >> results are delayed by 10ms and within +/- 1 (basically, rounding errors >> from the FFT). >> > > Do you plan to use it in VoIP environment? If so, 10ms of additional latency > is a big cost for resampling. Do you think there are any ways to reduce it? >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. 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 :)>> +/** Get the latency in input samples introduced by the resampler. >> + * @param st Resampler state >> + * @return Latency in input samples. >> + */ >> +int >> speex_block_resampler_get_input_latency(SpeexBlockResamplerState >> *st); >> + >> +/** Get the latency in output samples introduced by the resampler. >> + * @param st Resampler state >> + * @return Latency in output samples. >> + */ >> +int >> speex_block_resampler_get_output_latency(SpeexBlockResamplerState >> *st); >> > > 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.