Open Source Sample Rate Conversion Algorithm

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Can anyone point me towards a decent open source sample rate conversion algorithm that I could port to C#? I have been creating some managed wrappers for the Vista CoreAudio WASAPI interfaces, but they don't support sample rate conversion in shared mode. I'm not after the highest quality possible, just decent performance (needs to do 8kHz to 44.1Khz and 44.1kHz to 48kHz). I could probably cobble up some kind of linear interpolation myself, but I'm sure I will get better results from using a tried and tested algorithm.

thanks
Mark

Post

JOS has some good links on his page:

http://ccrma-www.stanford.edu/~jos/resa ... tware.html

If you pick one of these it would make sense to become part of their community and maintain a .NET port for them.
Matt

Pi is exactly three

Post

I googled "open source" & "sample rate conversion" for you, and it came up with this:

http://www.mega-nerd.com/SRC/

http://www.jsresources.org/examples/Sam ... .java.html
(you could probably port it to C# yourself)

If you want more, just do the Googling yourself. There's enough there...
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

Post

BertKoor wrote:I googled "open source" & "sample rate conversion" for you, and it came up with this:

http://www.mega-nerd.com/SRC/

http://www.jsresources.org/examples/Sam ... .java.html
(you could probably port it to C# yourself)

If you want more, just do the Googling yourself. There's enough there...
Although it's great software, I'd discourage using the SRC linked above because it's under GPL, two in the link I posted are LGPL, it's much less restrictive since you can dynamically link and not have to inherit the GPL for your code, or more importantly the people using your port.

The Java link above uses some javax libraries to do the heavy lifting, so that's not going to help very much.
Matt

Pi is exactly three

Post

thanks for the suggestions. I think I will just go with the SRC you can get at through the PCM ACM codec for now, and perhaps dig out some of my old signal processing books to refresh my memory on this stuff. Its such a shame that open source licenses keep seeming to get in the way of actually reusing other code in your own open source library.

Mark

Post

Do you know how it works, is it linear interpolation perhaps? If you have a little code snippet I'd be interested to see how the api lets you do the job as I'm unfamiliar with the acm approach.

If you're making an open source library there is nothing to stop you reusing these libraries, you just tend to need to release under the same license.
Matt

Pi is exactly three

Post

It seems like the ACM codec doesn't do IEEE formats, so I have ended up writing a managed wrapper for the Resampler DirectX media object (DMO). This was a lot more work than I was hoping for as I had to wrap large portions of DirectShow. Anyway, it is basically working now - I can resample WAV files quite easily. However, I still need to tweak it for on the fly resampling during playback, as I need to work out a read-ahead strategy so it can supply enough data to fill each buffer.

If you are interested in the code, it is available on Codeplex:
http://www.codeplex.com/naudio

You can download or browse the code online. If you want to use SVN, check out the SvnBridge project also on CodePlex, which lets you connect SvnTortoise to TFS.

Mark
http://mark-dot-net.blogspot.com

Post

Just found another resampling library under LGPL named SSRC but have not yet tried it http://shibatch.sourceforge.net/

Mainly this is for others finding this post in a few months time as I see you solved your particular issue.
Matt

Pi is exactly three

Post

Just found an interesting site rating the quality of some of the sample rate converters used in many apps and libs:

http://src.infinitewave.ca/
Matt

Pi is exactly three

Post

Hmm... not what the OP were thinking of but, there's an interesting and, AFAIK, also an excellent SRC option for "lazy coders" available as DLL version ... just download and install the great free r8brain from Voxengo and read files named as r8b_API.txt and r8b_license.txt ...


Juha

Post

If you're converting up, then a simple third-order polynomial interpolator (Hermite) will do just fine! It adds significantly less noise than linear, and doesn't take a whole lot more runtime. There should be public domain code for doing that on the net -- and maybe even in the music-dsp code archives.

Remember: you probably want to run a steep low-pass filter on the output of the SRC after up-conversion, to remove any artifacts added by the SRC. IIRC, linear will add artifacts at about -20dBFS, and Hermite will add artifacts at -40dBFS, so filtering above the Nyquist of the original signal will make sense.

If you want a higher-quality converter, then I recommend a polyphase filter/interpolator, which typically end up being implemented with interpolator and filter in a single loop. You can construct them by thinking of what a windowed sinc convolution followed by a FIR filter would look like for each possible relative phase (e g, when doing 8 to 48, you only get 6 relative phases; when doing 44.1 to 48 you get 147/160 phases). Or you can just go look it up in a textbook, decide on a width, and write out the formulas :-)
Apparently, there are some legal, mostly non-controverisal subjects you can't talk about on KVR, or even mention in your sig. Unfortunately, the guidelines don't actually talk about them, so the only way to find out is trial and error.

Post

juha_p wrote:Hmm... not what the OP were thinking of but, there's an interesting and, AFAIK, also an excellent SRC option for "lazy coders" available as DLL version ... just download and install the great free r8brain from Voxengo and read files named as r8b_API.txt and r8b_license.txt ...


Juha
I thought this was quite limited in the input/output rates that it supports, something like input only at 44.1k as far as memory serves. Happy to be corrected though :)
Matt

Pi is exactly three

Post Reply

Return to “DSP and Plugin Development”