Subject: Re: [linux-audio-dev] EVO 0.0.5 released , resampling (interpolation) support added
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Sep 19 2000 - 23:59:22 EEST
On Tue, 19 Sep 2000, Paul Barton-Davis wrote:
> >Basically what he is doing is using fixed point math:
> >interpreting a part of the 32 word as integer part,
> >and the other as fractional part.
> >
> >I've thought about this , but in EVO's case we have to
> >deal with samples up to 2GB, that means we need the full
> >32bit for the integer part.
>
> why only 2GB ?
for several reasons:
- limited filesize on ext2 (2GB)
- 64bit ints are not that fast on 32bit boxes
but that limit can easily be lifted (with very little code modifications)
- availability of 64bit filesystems with associated 64bit calls
(64bit read() , write() , lseek()
- 64bit CPUs where 64bit ints are fast
perhaps the 64bit ints on 32bit CPUs would not even incide that much
on the overall performance of the sampler,
because the time consuming stuff is mainly interpolation, filters
and shuffling around memory.
As soon as 64bit filesystems (is there already a 64bit ext2 on 32bit CPUs
available ?) with 64bit file IO syscalls will be available, I'll try them out
and measure what's the impact on a 32bit x86.
Anyway the 2GB limit even if you stay within the 32bit domain and
with regular ext2 is not a big issue:
assume you want to create an 8GB Piano:
split the keyboard in 4 zones and supply 4 files of 2GB each.
The 8GB piano instrument file, does nothing more than
loading the 4 2GB sections , map them to the correct keyrange
and assign them to the same MIDI channel.
And automagically you have an 8GB instrument, which
seamlessy glued together the 4 parts, without the user noticing
anything.
>
> >I'll try both custom FP asm (rounding and then check if
>
> i don't think you need asm to do this, and in fact, asm is not
> portable. you want to check out the _FPU_SETCW macro. it can do what
> you want in a portable way, i believe.
The problem is that on x86 , the setting of CW eats cycles like mad,
and since we do need truncation in my case, (opposed to rounding which is the
default FPU behaviour), we would need to modify the rounding mode before
and after each FP->int which is what pos_int=(int)pos does.
And keeping the FPU in truncate mode all the time is not the best solution
either, since we will loose precision at each calculation because rounding
was turned off.
See my response to Karl for more infos.
>
> >It really pays off to optimize that small code section,
> >because it's in the innermost loop, thus making a significant
> >difference in the number of voices you can achieve.
>
> sure. like i said, ed hall's optimizations racked up incredible
> performance gains on the x86. note, however, that it made not much
> difference on a MIPS system.
Yes because the MIPS does not suffer from the CW setting problem, probably
because it's either fast or because it has a native truncation instruction.
Benno.
>
> --p
This archive was generated by hypermail 2b28 : Tue Sep 19 2000 - 23:14:48 EEST