Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
07.09.2014 15:48, Tanu Kaskinen wrote: Do we have some kind of a conclusion about whether the soxr and libavresample resamplers should be merged? If I understood correctly, the libavresample resampler appears to be somehow broken, so I guess that should not be merged until the brokenness is fixed. There is an important update. Yesterday Peter shared source code of his standalone program that performs resampling using the same libraries as PulseAudio. And in this standalone version, the lavr resampler does not have this brokenness. So the bug is somewhere in PulseAudio integration, i.e. in the submitted patch, and not in libavresample itself. Thus, it should be searched for and fixed. As for quality evaluation, I have not performed any testing yet, and will do it live during today's discussion of resampler quality evaluation. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
On Sun, 2014-09-07 at 16:32 +0600, Alexander E. Patrakov wrote: > [sent only to Tanu by mistake, resending to the list] > > 07.09.2014 15:48, Tanu Kaskinen wrote: > > On Sun, 2014-08-24 at 13:35 +0600, Alexander E. Patrakov wrote: > >> 04.08.2014 19:29, I wrote: > >>> Anyway, I think that the task of objectively testing the resampler > >>> speed and quality also needs to be done, in order to provide such > >>> justifications. Please see > >>> http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html > >>> for the formulation. > >> > >> Now I have the tools for the basic form of quality evaluation (using a > >> linear sine sweep). The tools can compare quality of various resamplers, > >> including those found in proprietary operating systems. However, the end > >> result is still not good enough to answer the question "is this > >> resampler good enough". The (useless) answer is almost always the same: > >> "no, here is a sine wave frequency that it either attenuates audibly or > >> distorts audibly", even though nobody listens to e.g 18 kHz sine waves. > >> > >> I will test the two new resamplers among the others today. > > > > Do we have some kind of a conclusion about whether the soxr and > > libavresample resamplers should be merged? If I understood correctly, > > the libavresample resampler appears to be somehow broken, so I guess > > that should not be merged until the brokenness is fixed. > > Correct. > > > Did the soxr > > resampler end up being the best one in any of the following categories? > > > > 1) Best quality > > The problem with this question is that there are perfect resamplers in > terms of perceived quality. It has no meaning to compare e.g. > speex-float-5 and speex-float-10 in terms of quality. Both are just > perfect when given a task of resampling from 44.1 to 48 kHz. > > At MQ or HQ quality, soxr is perfect, too. > > > 2) Fastest > > Definitely not, at least at quality levels above QQ. And at QQ, I have > not tested, and at that level it is just a cubic interpolator. I think > we don't need a complex library just for cubic interpolation. > > > 3) Fastest without any audible distortions > > Definitely not, by a factor of 10 (over speex). > > > 4) Best compromise between speed and quality > > Definitely not. > > > X) Some of the above when applying licensing constraints > > Definitely not. The winner on all points is speex. At the quality level > of 5, it never creates audible distortions. And at any quality higher > than 2, it eats less CPU than any comparable (in terms of quality) > competitors. Thank you! I'll remove this patch set from the wiki then. > At this point, I also suggest removing libsamplerate-based resampler. Sounds reasonable to me. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
[sent only to Tanu by mistake, resending to the list] 07.09.2014 15:48, Tanu Kaskinen wrote: On Sun, 2014-08-24 at 13:35 +0600, Alexander E. Patrakov wrote: 04.08.2014 19:29, I wrote: Anyway, I think that the task of objectively testing the resampler speed and quality also needs to be done, in order to provide such justifications. Please see http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html for the formulation. Now I have the tools for the basic form of quality evaluation (using a linear sine sweep). The tools can compare quality of various resamplers, including those found in proprietary operating systems. However, the end result is still not good enough to answer the question "is this resampler good enough". The (useless) answer is almost always the same: "no, here is a sine wave frequency that it either attenuates audibly or distorts audibly", even though nobody listens to e.g 18 kHz sine waves. I will test the two new resamplers among the others today. Do we have some kind of a conclusion about whether the soxr and libavresample resamplers should be merged? If I understood correctly, the libavresample resampler appears to be somehow broken, so I guess that should not be merged until the brokenness is fixed. Correct. Did the soxr resampler end up being the best one in any of the following categories? 1) Best quality The problem with this question is that there are perfect resamplers in terms of perceived quality. It has no meaning to compare e.g. speex-float-5 and speex-float-10 in terms of quality. Both are just perfect when given a task of resampling from 44.1 to 48 kHz. At MQ or HQ quality, soxr is perfect, too. 2) Fastest Definitely not, at least at quality levels above QQ. And at QQ, I have not tested, and at that level it is just a cubic interpolator. I think we don't need a complex library just for cubic interpolation. 3) Fastest without any audible distortions Definitely not, by a factor of 10 (over speex). 4) Best compromise between speed and quality Definitely not. X) Some of the above when applying licensing constraints Definitely not. The winner on all points is speex. At the quality level of 5, it never creates audible distortions. And at any quality higher than 2, it eats less CPU than any comparable (in terms of quality) competitors. At this point, I also suggest removing libsamplerate-based resampler. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
On Sun, 2014-08-24 at 13:35 +0600, Alexander E. Patrakov wrote: > 04.08.2014 19:29, I wrote: > > Anyway, I think that the task of objectively testing the resampler > > speed and quality also needs to be done, in order to provide such > > justifications. Please see > > http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html > > > > for the formulation. > > Now I have the tools for the basic form of quality evaluation (using a > linear sine sweep). The tools can compare quality of various resamplers, > including those found in proprietary operating systems. However, the end > result is still not good enough to answer the question "is this > resampler good enough". The (useless) answer is almost always the same: > "no, here is a sine wave frequency that it either attenuates audibly or > distorts audibly", even though nobody listens to e.g 18 kHz sine waves. > > I will test the two new resamplers among the others today. Do we have some kind of a conclusion about whether the soxr and libavresample resamplers should be merged? If I understood correctly, the libavresample resampler appears to be somehow broken, so I guess that should not be merged until the brokenness is fixed. Did the soxr resampler end up being the best one in any of the following categories? 1) Best quality 2) Fastest 3) Fastest without any audible distortions 4) Best compromise between speed and quality X) Some of the above when applying licensing constraints -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
04.08.2014 19:29, I wrote: Anyway, I think that the task of objectively testing the resampler speed and quality also needs to be done, in order to provide such justifications. Please see http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html for the formulation. Now I have the tools for the basic form of quality evaluation (using a linear sine sweep). The tools can compare quality of various resamplers, including those found in proprietary operating systems. However, the end result is still not good enough to answer the question "is this resampler good enough". The (useless) answer is almost always the same: "no, here is a sine wave frequency that it either attenuates audibly or distorts audibly", even though nobody listens to e.g 18 kHz sine waves. I will test the two new resamplers among the others today. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
Hello Arun, > > the work was mostly done by poljar (Damir Jelić) during GSoC'13, this is > > just > > a rebase > > > > my goal would be to establish libavresample as the new default resampler and > > drop the ffmpeg code copied into PA currently; don't worry, this would be > > further work based on the feedback received :) > The split looks good to go in now. good > For the other two, I think it would be nice to have some > measurements/justification. We have the resampler test to do CPU > measurements (and I see that poljar already did some comparisons that > show soxr to be favourable in the int case at least), but I think we > need to also have a justification based on quality. Any thoughts on > measuring that? ok, will provide more info/justification in a v2 quality is more difficult > I should also add that for libavresample to be the default > implementation, it needs to be easily available in distributions, and I > think this might be a concern unless the packaging is split off (at > least on my Fedora box, this comes from rpmfusion and not offcial Fedora > packages). ok, libavresample is in libav v0.9 Ubuntu has libavresample-dev/libavresample1 p. -- Peter Meerwald +43-664-218 (mobile)___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
On Mon, 2014-08-04 at 14:40 +0200, Peter Meerwald wrote: > Hello, > > this patch series splits up the resampler implementation found in pulsecore > into separate files and adds two new resampler implementations: soxr and > libavresample > > the work was mostly done by poljar (Damir Jelić) during GSoC'13, this is just > a rebase > > my goal would be to establish libavresample as the new default resampler and > drop the ffmpeg code copied into PA currently; don't worry, this would be > further work based on the feedback received :) The split looks good to go in now. For the other two, I think it would be nice to have some measurements/justification. We have the resampler test to do CPU measurements (and I see that poljar already did some comparisons that show soxr to be favourable in the int case at least), but I think we need to also have a justification based on quality. Any thoughts on measuring that? I should also add that for libavresample to be the default implementation, it needs to be easily available in distributions, and I think this might be a concern unless the packaging is split off (at least on my Fedora box, this comes from rpmfusion and not offcial Fedora packages). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
04.08.2014 19:05, Peter Meerwald wrote: Hello Alexander, my goal would be to establish libavresample as the new default resampler and drop the ffmpeg code copied into PA currently; don't worry, this would be further work based on the feedback received :) This conflicts with my goal of writing and getting a rewindable resampler into pulseaudio. First, sorry for the very harsh reply. ok, so general direction is not undisputed :) do you know if libavresample can do rewind? do you oppose the present patches to split up resampler.c and add new resamplers? nothing would prevent yet another resampler probably different applications need different resamplers, i.e. fast vs. correct currently, speex and ffmpeg are kind-of default: speexdsp is largely unmaintained, very recently there seems to be some activity [0]; speex has SSE and NEON code path ffmpeg code is copied into the PA repo and has been superceeded by libavresample libavresample has AARCH64, NEON and SSE/AVX codepath, although only AARCH64 (!) has SIMD resampling code (yet) libavresample might be a good basis for general purpose resampling with a good infrastructure for architecture specific optimization regards, p. [0] https://git.xiph.org/speexdsp.git OK, now I see what you are after. Let me answer point-by-point. First, libavresample cannot rewind. There is currently no open-source rewindable resampler. Just look at the header. There is nothing that could save and restore the delay buffer in avresample. As for the current patch to split up resampler.c (1/3 in your series), I don't have any inherent objection to its intent. However, I should look more closely before I can say whether its content is good. Will do that today. As for adding _any_ new resamplers, well, I would like to see the justification in the commit message for each new resampler. Otherwise we'll end up with the equivalent of GNOME 1 situation with clocks. For libavresample, you have already provided a good justification (upstream deprecation of the ffmpeg resampler + SIMD addition) in the e-mail I am replying to, please copy it into the commit message. Still, I have to look at the patch more thoroughly. Maybe the end result for the "rewindable resampler" quest will be something based on libavresample - but then we'll have to either maintain it indefinitely or submit our modifications upstream (where they will be likely rejected, as "not needed for libav"). For soxr, I have not seen such justification yet, and thus currently have a slight objection to its addition. Anyway, I think that the task of objectively testing the resampler speed and quality also needs to be done, in order to provide such justifications. Please see http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html for the formulation. Feel free to come to the Plumbers conference and discuss it there if we don't reach any conclusion before that. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
Hello Alexander, > > my goal would be to establish libavresample as the new default resampler and > > drop the ffmpeg code copied into PA currently; don't worry, this would be > > further work based on the feedback received :) > This conflicts with my goal of writing and getting a rewindable > resampler into pulseaudio. ok, so general direction is not undisputed :) do you know if libavresample can do rewind? do you oppose the present patches to split up resampler.c and add new resamplers? nothing would prevent yet another resampler probably different applications need different resamplers, i.e. fast vs. correct currently, speex and ffmpeg are kind-of default: speexdsp is largely unmaintained, very recently there seems to be some activity [0]; speex has SSE and NEON code path ffmpeg code is copied into the PA repo and has been superceeded by libavresample libavresample has AARCH64, NEON and SSE/AVX codepath, although only AARCH64 (!) has SIMD resampling code (yet) libavresample might be a good basis for general purpose resampling with a good infrastructure for architecture specific optimization regards, p. [0] https://git.xiph.org/speexdsp.git -- Peter Meerwald +43-664-218 (mobile) ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/3] resamplers
04.08.2014 18:40, Peter Meerwald wrote: Hello, this patch series splits up the resampler implementation found in pulsecore into separate files and adds two new resampler implementations: soxr and libavresample the work was mostly done by poljar (Damir Jelić) during GSoC'13, this is just a rebase my goal would be to establish libavresample as the new default resampler and drop the ffmpeg code copied into PA currently; don't worry, this would be further work based on the feedback received :) This conflicts with my goal of writing and getting a rewindable resampler into pulseaudio. thanks, p. Peter Meerwald (3): resampler: Split the resampler implementations into separate files resampler: Add optional soxr resampler resampler: Add optional libavresample resampler configure.ac| 34 ++ src/Makefile.am | 30 +- src/pulsecore/resampler.c | 660 +++- src/pulsecore/resampler.h | 54 +++ src/pulsecore/resampler/ffmpeg.c| 132 +++ src/pulsecore/resampler/lavr.c | 160 src/pulsecore/resampler/libsamplerate.c | 102 + src/pulsecore/resampler/peaks.c | 163 src/pulsecore/resampler/soxr.c | 124 ++ src/pulsecore/resampler/speex.c | 151 src/pulsecore/resampler/trivial.c | 102 + 11 files changed, 1107 insertions(+), 605 deletions(-) create mode 100644 src/pulsecore/resampler/ffmpeg.c create mode 100644 src/pulsecore/resampler/lavr.c create mode 100644 src/pulsecore/resampler/libsamplerate.c create mode 100644 src/pulsecore/resampler/peaks.c create mode 100644 src/pulsecore/resampler/soxr.c create mode 100644 src/pulsecore/resampler/speex.c create mode 100644 src/pulsecore/resampler/trivial.c -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
