I'm a bit worried that this will hurt performance on low-end devices since this PR removes the fast paths for simple conversions. I'm also not sure why the use of templates has been removed, since that doesn't appear to be related to the sample rate, and removing it makes future changes I have planned more complex.

A potential solution would be to have one class that has the functions from each of the old classes as private functions, and have the convert function select the best one based on the configured sample rate.

@ccawley2011 The templates were removed since they essentially 'lock in' the type of RateConverter at creation. Suppose you have a Copy/SimpleRateConverter whose rate you want to adjust to an arbitrary value: this just wouldn't work, since the interpolation code is in an entirely different class. A solution would be to destroy the old RateConverter and replace it with a new one, but then you also need to carry over the internal buffer and state... which already I tried doing, with poor results.

I'm not at all opposed to bringing the old code paths back in, though. I opted to remove them since the different specializations used the internal variables in slightly different ways that could get tangled up when switching, but with a bit more work they could definitely be brought back.

@ccawley2011 The templates were removed since they essentially 'lock in' the type of RateConverter at creation.

I was referring to the use of templates for specifying the stereo parameters, rather than the multiple subclasses for different sample rates.

I'm not at all opposed to bringing the old code paths back in, though. I opted to remove them since the different specializations used the internal variables in slightly different ways that could get tangled up when switching, but with a bit more work they could definitely be brought back.

👍

I was referring to the use of templates for specifying the stereo parameters, rather than the multiple subclasses for different sample rates.

@ccawley2011 I see. There wasn't a particular reason for removing those, they just became victim of overeager refactoring :) I'll work on both of your points as soon as I've got the time, until then I'm marking this as a draft PR.

I've re-added the optimized code paths and the templatization of the stereo parameters. From what I've tested, switching between copying and interpolation seems to work fine, without any audible distortion. I'm not entirely sure where simple conversion is useful, so I haven't been able to test it yet.

This is interesting, however, the changes are huge and this needs a good review and testing before getting merged I believe. Anyways just wondering, why change flow function name to convert?

I'm not entirely sure where simple conversion is useful, so I haven't been able to test it yet.

It's used when the input sample rate is a multiple of the output sample rate. For example, when converting 44100Hz to 22050Hz or 11025Hz. This should be easy to test with the SDL backend using the --output-rate command line option or by setting the output_rate key in the configuration file.

@ccawley2011 Thanks, I did not know about that flag. Testing with it revealed an error I introduced when renaming variables, which has now been fixed. I've tested switching between all code paths and everything seems to work correctly now :)

@hari01584 The function was named flow() to support the flow/drain dichotomy. However, since I'm removing the drain() function (which was just a nonfunctional stub), leaving flow() named like that would just make it more confusing.

Thanks!