Re: [Audacity-devel] SoX resampling

[Steve t. F. <ste...@gm...>]

On 30 October 2012 08:37, Gale Andrews <ga...@au...> wrote:
>
> | From Vaughan Johnson <va...@au...>
> | Mon, 29 Oct 2012 15:52:32 -0700
> | Subject: [Audacity-devel] SoX resampling
>> On 10/29/2012 3:17 PM, Gale Andrews wrote:
>> >
>> > | From Steve the Fiddle <ste...@gm...>
>> > | Sun, 28 Oct 2012 21:02:31 +0000
>> >> On 28 October 2012 20:04, Gale Andrews <ga...@au...> wrote:
>> >>>
>> >>> | From Steve the Fiddle <ste...@gm...>
>> >>> | Sun, 28 Oct 2012 14:19:51 +0000
>> >>>> I would expect that most Linux distributions (and their users) would
>> >>>> prefer to use libsamplerate rather than libresample because of the
>> >>>> resampling is demonstrably better quality.
>> >>>>
>> >>>[...]
>> >
>> > But we must choose libresample for releases, so if we want to give an
>> > option to use libsamplerate (either instead of libsoxr, or just instead
>> > of libresample for time tracks), we've got to maintain three different
>> > resampling libraries.
>>
>> The code was already in the configure file, and as far as I know was not
>> requiring any ongoing support. Besides, it should be up to developers to
>> decide what code should be maintained.
>
> Obviously, apart from my previous point about knowing which resampling
> library the user has.
>
> I merely thought it was worth posing whether we still need libsamplerate
> *if* libsoxr has the quality of libsamplerate without the time penalty.
> Presumably libsoxr would be faster for everyone, not just for those
> with low powered machines; also we would lose a P3 crash bug
> ( http://bugzilla.audacityteam.org/show_bug.cgi?id=333 ) .
>
>
>> Regardless of the details of speed and quality, and I've seen different
>> opinions in this thread,
>
> Is there any doubt about the time penalty with libsamplerate? I've had
> several other confirmations of it. That's my only beef with it, and that
> those who complain obviously blame Audacity for the slowness.

I don't find libsamplerate excessively slow on my 2 GHz laptop, but I
can confirm that it is definitely a lot slower than libresample.
I would expect libsoxr to be the preferred library on all platforms as
it has both high quality and speed.

Until the other quality issue with Time Tracks is fixed it doesn't
really matter much what sort of variable rate sampling is done, but
when it is fixed I would expect most Linux distributions to favour
libsamplerate as the second option (with libsoxr as the "main"
resampling library).

One thing that looks a bit peculiar with the current SVN head build is
that it is built with libsoxr and resampling tracks is being performed
by libsoxr, but "About Audacity > build informations" lists
libresamlple as the only resampling library.

Steve


>
>
>> All that work had already been done, so why throw it out, especially
>> when distros prefer libsamplerate over libresample?
>
> The question may be if distros will prefer libsoxr to libsamplerate
> or not; there is no doubt they prefer libsamplerate to libresample.
>
> The way I was reading things when this started, libsamplerate (and
> libresample) were on the way out (subject to testing) and that's what
> I think the originally committed patches for Linux achieved, hence
> what ./autogen.sh produced in the configure script I committed in
> r12007.
>
> But I assume LSR is going to be quality-preferable for Time Track
> if the machine is fast enough (unless the work you are doing changes
> that somehow). So if the quality difference is significant (the other
> question I was posing) we can't now remove libsamplerate even if it
> was felt libsoxr was generally preferable.
>
>
>> Gale, will you please restore that libsamplerate code you threw out in
>> r12007? There was no to reason make any change to libsamplerate support
>> in the configure file, just add libsoxr support -- that's the only thing
>> mentioned in your commit comment, and all that should have been done.
>
> Of course I can do what's decided as needed, but as above, all I
> committed was what ./autogen.sh produced.
>
> I probably shouldn't try selectively restoring libsamplerate myself
> without guidance, and obviously we must be sure HEAD still compiles
> on Linux if we put libsamplerate and libresample back in configure
> as you suggested to Paul. It's not really surprising that HEAD won't
> build for him right now if he has still libresample dependencies in the
> project file, even though they will need to go back later.
>
> So do you want to see what happens if Paul produces his own
> patch for configure and it lets him build on Mac? Or just leave it
> until you've committed your changes to Resample.* and see
> what that does to configure after running ./autogen.sh?
>
> And when done, is it going to work thus - if Audacity is configured
> with libsamplerate or libresample, all is as before; if Audacity is
> configured with libsoxr, then libresample is used for minFactor !=
> maxFactor?
>
>
> Thanks,
>
>
>
> Gale
>
>
>
>> > Is there the same tradeoff using libsamplerate on time tracks as
>> > generally  - higher quality than libresample, but much slower?
>> >
>> > On Ubuntu 12.04 on my netbook (1 GHz, 1 GB RAM), time track on an
>> > Audacity 2.0.0 build using libsamplerate (unchanged Quality Preferences)
>> > takes about 3 seconds to start playback. The sound stutters here and
>> > there. Playback is noticeably smoother in HEAD (using libresample for
>> > the time track).
>> >
>> > Time Track playback with libsamplerate was as I recall quite OK using
>> > Ubuntu 11.10 on a much faster laptop. Yes subjectively, quality may
>> > be slightly better, especially comparing exports.
>> >
>> >
>> >
>> >
>> > Gale
>> >
>> >
>> >>>> On 28 October 2012 09:58, Erik de Castro Lopo <ml...@me...> wrote:
>> >>>>> Vaughan Johnson wrote:
>> >>>>>
>> >>>>>> I did not know that. I thought that long-ago decision was working for
>> >>>>>> all parties.
>> >>>>>>
>> >>>>>> We cannot control what Linux distros do, but yes, we can make it more
>> >>>>>> difficult by removing support from Audacity trunk/HEAD. Even if we do,
>> >>>>>> anybody with enough motivation could still find that libsamplerate
>> >>>>>> support in prior Audacity revisions.
>> >>>>>>
>> >>>>>> Am cc-ing Erik, as he has already expressed that he does not want
>> >>>>>> libsamplerate in our releases.
>> >>>>>
>> >>>>> I have a problem with Audacity linking to libsamplerate *and* GPL
>> >>>>> incompatible stuff. Most Linux distributions don't do that.
>> >>>>>
>> >>>>>> Erik, would you like us to remove the
>> >>>>>> options for libsamplerate support from Audacity trunk/HEAD, as well?
>> >>>>>
>> >>>>> I'd prefer if you kept it so that Linux distros like Debian that do
>> >>>>> the RightThing(tm) wrt licenses can use libsamplerate.
>> >>>>>
>> >>>>> Erik
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel