What is KVR Audio? | Submit News | Advertise | Developer Account

Options (Affects News & Product results only):

OS:
Format:
Include:
Quick Search KVR

"Quick Search" KVR Audio's Product Database, News Items, Developer Listings, Forum Topics and videos here. For advanced Product Database searching please use the full product search. For the forum you can use the phpBB forum search.

To utilize the power of Google you can use the integrated Google Site Search.

Products 0

Developers 0

News 0

Forum 0

Videos 0

Search  

Open source high-quality pro audio sample rate converter library released from Voxengo

DSP, Plug-in and Host development discussion.

Moderator: Moderators (Main)

User avatar
KVRAF
 
2915 posts since 7 Sep, 2002
 

Postby Aleksey Vaneev; Tue Oct 29, 2013 3:57 am

Released v1.5 with minor precision enhancements
Image
User avatar
KVRist
 
369 posts since 12 Apr, 2010, from Lowlands of Holland
 

Postby Tale; Wed Oct 30, 2013 12:28 am

Thanks. :)
Martinic Combo Model F
User avatar
KVRist
 
150 posts since 30 Apr, 2006, from PA->FL->PA->???
 

Postby random_id; Sat Nov 16, 2013 3:10 pm

Aleksey Vaneev wrote:No, that's not overkill, I myself use linear-phase oversampling in Voxengo plug-ins that is close to that latency number and quality. You can reduce latency by using a lower ReqAtten and higher ReqTransBand values, it's flexible.


I have been trying to implement r8brain in an oversampling scenario and I have a question. Using r8brain to downsample would be the obvious choice; however, what would be the recommended method for upsampling? Would zero-stuffing with some other filtering work more efficiently when upsampling? Or, would it be better to use r8brain for this as well?

Thanks for the great library.
KVRian
 
1195 posts since 14 Dec, 2003, from Melbourne, Australia
 

Postby very angry mobster; Sat Nov 16, 2013 4:25 pm

random_id wrote:
Aleksey Vaneev wrote:No, that's not overkill, I myself use linear-phase oversampling in Voxengo plug-ins that is close to that latency number and quality. You can reduce latency by using a lower ReqAtten and higher ReqTransBand values, it's flexible.


I have been trying to implement r8brain in an oversampling scenario and I have a question. Using r8brain to downsample would be the obvious choice; however, what would be the recommended method for upsampling? Would zero-stuffing with some other filtering work more efficiently when upsampling? Or, would it be better to use r8brain for this as well?

Thanks for the great library.
I would use r8brain for both the upsampling and downsampling.
User avatar
KVRAF
 
2915 posts since 7 Sep, 2002
 

Postby Aleksey Vaneev; Sat Nov 16, 2013 11:07 pm

random_id wrote:I have been trying to implement r8brain in an oversampling scenario and I have a question. Using r8brain to downsample would be the obvious choice; however, what would be the recommended method for upsampling? Would zero-stuffing with some other filtering work more efficiently when upsampling? Or, would it be better to use r8brain for this as well?


r8brain-free-src can be used for both tasks. Besides, I think it would be hard to find a faster implementation of linear-phase resampling than what r8brain-free-src offers.

If you just need to do 2x,4x,8x,etc upsampling/downsampling you may use objects of the CDSPBlockConvolver class directly. But you'll need to study the CDSPFIRFilterCache::getLPFilter() function to be fluent with filter parameters. For efficient multi-step resampling the transition bands of intermediate resampling steps must be set to larger values.
Image
User avatar
KVRAF
 
2915 posts since 7 Sep, 2002
 

Postby Aleksey Vaneev; Sun Nov 17, 2013 1:24 am

After a bit of thought, I think I'll add an additional "resampler" class which will do the "power of 2" resampling exclusively. It will be different to the CDSPResampler class in that it will report the full latency amount without consuming it automatically.

Right now I think CDSPResampler class cannot be used for oversampling inside plug-in's signal path, because CDSPResampler is not working synchronously.
Image
User avatar
KVRist
 
369 posts since 12 Apr, 2010, from Lowlands of Holland
 

Postby Tale; Sun Nov 17, 2013 1:49 am

Aleksey Vaneev wrote:After a bit of thought, I think I'll add an additional "resampler" class which will do the "power of 2" resampling exclusively. It will be different to the CDSPResampler class in that it will report the full latency amount without consuming it automatically.

That would be a nice addition. :cool:

Aleksey Vaneev wrote:Right now I think CDSPResampler class cannot be used for oversampling inside plug-in's signal path, because CDSPResampler is not working synchronously.

Well, I have experimented with this only briefly, but it does seem to work already. However, I couldn't find a way to read out the latency programmatically, so I just measured it manually.
Martinic Combo Model F
User avatar
KVRAF
 
2915 posts since 7 Sep, 2002
 

Postby Aleksey Vaneev; Sun Nov 17, 2013 1:54 am

Tale wrote:Well, I have experimented with this only briefly, but it does seem to work already. However, I couldn't find a way to read out the latency programmatically, so I just measured it manually.

Yes, but that's a work-around. Besides, for the overall latency to remain a whole number, downsampling step may require insertion of several samples. So, in general case things are quite complicated if one wants to have consistent results at any setting.
Image
User avatar
KVRist
 
369 posts since 12 Apr, 2010, from Lowlands of Holland
 

Postby Tale; Sun Nov 17, 2013 2:06 am

Aleksey Vaneev wrote:Yes, but that's a work-around. Besides, for the overall latency to remain a whole number, downsampling step may require insertion of several samples. So, in general case things are quite complicated if one wants to have consistent results at any setting.

This was for 2x up, 2x down, and measuring the latency each time you change something was a pain, although it did seemed to be consistent.

Still, like I already expressed, I would very much welcome the addition of a better solution. :)
Martinic Combo Model F
KVRer
 
24 posts since 27 Dec, 2009, from Berlin
 

Postby tonfilm; Tue Dec 17, 2013 4:40 am

this is great! i am currently working on a c# wrapper.
but there is one thing i don't understand. the process function has double* as input and output type for the buffers. so does the process function only work with double[] types and i have to provide the samples always as double? and how does this work together with the resolution of the resampler type that i create?

i ask this because in my engine am using only 32-bit float buffers and it would need an additional step to convert the input/output buffers which would be painful for the performance. also the input to the resampler is often PCM 16 or 24 bit integer data directly from a wave file that i would need in 32-bit float buffer representation after.

so the setup is most of the time:

wavafile not in engine sample rate -> resampler -> 32-bit float buffer in engine sample rate

whats your suggestion for an optimal signal flow?

here is my first take on it:
https://github.com/tebjan/VVVV.Audio/blob/master/Source/Utils/R8BrainSampleRateConverter.cs
KVRer
 
24 posts since 27 Dec, 2009, from Berlin
 

Postby tonfilm; Tue Dec 17, 2013 11:27 am

and i have another question, in which cases does the op0 output buffer point to the input buffer? can you generalize this? only when downsampling?

this is an important question since the c# wrapper has to know whether it has to allocate unmanaged memory. in cases when the op0 output buffer does not point to the input buffer it can just pin the input array for the time of the call and no copy is needed.
KVRer
 
24 posts since 27 Dec, 2009, from Berlin
 

Postby tonfilm; Tue Dec 17, 2013 8:06 pm

i am not sure what i am doing wrong... the process method seems to work, but i get very high output values, like 3.15490588487157E+287. have you ever seen this? might be an obvious problem... my input values are double samples in the range [-1..1], this is correct, or not?
KVRian
 
1195 posts since 14 Dec, 2003, from Melbourne, Australia
 

Postby very angry mobster; Tue Dec 17, 2013 9:10 pm

Aleksey Vaneev wrote:After a bit of thought, I think I'll add an additional "resampler" class which will do the "power of 2" resampling exclusively. It will be different to the CDSPResampler class in that it will report the full latency amount without consuming it automatically.
That would be useful. :)
User avatar
KVRAF
 
2915 posts since 7 Sep, 2002
 

Postby Aleksey Vaneev; Tue Dec 17, 2013 11:09 pm

tonfilm wrote:this is great! i am currently working on a c# wrapper.
but there is one thing i don't understand. the process function has double* as input and output type for the buffers. so does the process function only work with double[] types and i have to provide the samples always as double? and how does this work together with the resolution of the resampler type that i create?

Yes, you have to provide "double" samples, always.

tonfilm wrote:i ask this because in my engine am using only 32-bit float buffers and it would need an additional step to convert the input/output buffers which would be painful for the performance. also the input to the resampler is often PCM 16 or 24 bit integer data directly from a wave file that i would need in 32-bit float buffer representation after.

Such conversion is not "pain", it takes no more than 0.1% of conversion time.

Moreover, today it's much more practical to work with "double" buffers exclusively, it's an outdated approach, to use 32-bit float. From my tests, "doubles" work visibly faster than "floats", at least Intel C++ Compiler creates a faster code when "double" type is used.

tonfilm wrote:and i have another question, in which cases does the op0 output buffer point to the input buffer? can you generalize this? only when downsampling?

this is an important question since the c# wrapper has to know whether it has to allocate unmanaged memory. in cases when the op0 output buffer does not point to the input buffer it can just pin the input array for the time of the call and no copy is needed.

I would not rely on any pointer comparisons. You have to write your code in a way so that a new block of input data is not processed until you consume all output data.

tonfilm wrote:i am not sure what i am doing wrong... the process method seems to work, but i get very high output values, like 3.15490588487157E+287. have you ever seen this? might be an obvious problem... my input values are double samples in the range [-1..1], this is correct, or not?

You have bug somewhere definitely.
Image
KVRer
 
24 posts since 27 Dec, 2009, from Berlin
 

Postby tonfilm; Wed Dec 18, 2013 7:14 am

Aleksey Vaneev wrote:I would not rely on any pointer comparisons. You have to write your code in a way so that a new block of input data is not processed until you consume all output data.

tonfilm wrote:i am not sure what i am doing wrong... the process method seems to work, but i get very high output values, like 3.15490588487157E+287. have you ever seen this? might be an obvious problem... my input values are double samples in the range [-1..1], this is correct, or not?

You have bug somewhere definitely.


Yes, that was the case, i was just to overworked to see it. i handed over the wrong pointer to the input array, there are subtle details in .NET interop. it works now like a charm.

do you think i should host a project on github for the .NET wrapper? maybe others are interested too. current code is here:
https://github.com/tebjan/VVVV.Audio/blob/master/Source/Utils/R8BrainSampleRateConverter.cs

Aleksey Vaneev wrote:
Moreover, today it's much more practical to work with "double" buffers exclusively, it's an outdated approach, to use 32-bit float. From my tests, "doubles" work visibly faster than "floats", at least Intel C++ Compiler creates a faster code when "double" type is used.



this is very interesting... as i am in an early stage of the engine, i can still switch to double precision as the overall buffer format. from what you write, it sounds like the thing to do... and hello, we live in 2014 soon, 64-bit machines are here to stay. but i fear that 90% of all VST plugins do not support double precision and modular vst routing is one of the core features of the engine. what do you think? maybe i should open a separate discussion thread for that... :)
PreviousNext

Moderator: Moderators (Main)

Return to DSP and Plug-in Development