Damir Jeli? wrote: > On Fri, Nov 29, 2013 at 12:20:57PM +0600, Alexander E. Patrakov wrote: >> Let me try changing this by providing a review. >> >> Resampler implementations >> >> From: poljar (Damir Jeli?) >> Submission date: 2013-09-06(?) >> In a github branch: >> https://github.com/poljar/pulseaudio/commits/resampler_implementations_v2 >> >> My review: justification for this work is currently missing. I would expect >> some comparisons with the existing resamplers to be posted on the mailing >> list, or, if they were posted already, a link to be added to the patch >> review page. > Performance comparison was posted already [1]. > >> As I have already expressed, we should aim either for one perfect >> feature-complete resampler, or a small number plus a technical document >> justifying (a) the tradeoffs that are at play here and (b) why these >> tradeoffs should be exposed to the user. >> >> In other words: if one of the added resamplers is strictly better than e.g. >> speex, then add it and drop speex. If speex is strictly better than one of >> the added resamplers, drop that resampler. If no resampler is strictly >> better than the other, document this and document whether pulseaudio has >> enough information to make a decision automatically in each case. > The original plan was to remove ffmpeg from our tree and replace it with > the maintained equivalent library implementations (libav and > libswresample), but over the summer Arun requested not to drop ffmpeg > since some people don't like to have an extra dependency. > > My new plan is as follows: > - don't drop ffmpeg > - don't add libav or libswresample > - add soxr (which could potentially be a speex replacement) > > [1] http://poljar.blogspot.com/2013/08/vol-2-resampling-methods.html Thanks for the update. Tanu: could you please add the following text to the patch status page regarding Damir's project, just to keep all information in one place? """ * Status update: http://article.gmane.org/gmane.comp.audio.pulseaudio.general/18991 * Performance tests (mono): http://poljar.blogspot.com/2013/08/vol-2-resampling-methods.html * Performance tests (stereo & 5.1): TBD * Bandwidth & Aliasing tests: TBD, with explanatory material at http://poljar.blogspot.com/2013/10/epilogue-fourier-analysis-and-testing.html * Features (such as variable-rate support, input & output formats, optimizations for particular combinations of sample rates, compatibility with rewinds): TBD """ Separate performance tests for non-mono input are needed because some resamplers (e.g. libsamplerate and my resampler in Wine) need to perform some auxiliary computation (e.g., in my case, interpolation of tabulated filter coefficients) once and then use the result for each channel. The 2013-10 blog post touches upon the important topic of the resampler quality. Indeed, there are two important properties that are discussed in the blog post: * [Bandwidth] The resampler should not attenuate signal at frequencies that are below the lowest of the two Nyquist frequencies. * [Aliasing] The resampler should not create anything at frequencies not present in the original signal. However, that blog post only deals with one (unspecified) resampler, and thus is only an illustration of the above properties, but not a comparison of resamplers based on these properties. That's why the TBD above. I think it would be a good idea to post a spectrogram of a resampled linear sweep from 0 Hz to half of the original sampling rate. The result would be similar to this collection of images (which compares, for 96k -> 44.1k resampling, the old Wine resampler, the linear-interpolation resampler, two of the then-proposed resamplers, and Speex at different quality settings): http://imgur.com/a/0w8s4 -- Alexander E. Patrakov
