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.
On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote:> Alexander Chemeris wrote: > > 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.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? :)> 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.> > > +/** 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.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". -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
>> 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.