On Mon, Nov 22, 2010 at 12:26 AM, David Henningsson <[email protected]> wrote: >> True. I think it makes the most sense to duplicate the existing >> routines and adapt them to whatever format we decide on (rather than >> trying to make them handle multiple formats). Using real 24 bit (3 >> byte) samples doesn't really make sense from a synthesis standpoint, >> so I suggest we either go with 32 bit integers and/or floating point >> audio. > > It would be interesting trying to SIMD:ize them as well, but it's not > trivial. The output is fluid_real_t, perhaps we should see if there is any > speed difference between having the input as 32 bit integer or 32 bit float. >
I think this was also an area that Markus Nentwig explored. The conclusion, I think, was that there was no real benefit from 32 bit integer math, in fact I think it was slower (which makes sense, because floating point instructions can be executed in parallel with integer instructions). I do however see a benefit in providing a completely integer based synth, for the case of embedding on a system without an FPU. But I think this would be a lot of work, for a rather niche use. There are plenty of embedded systems with FPUs these days. >> Sounds good. It may be that we can do some minor changes though >> (addition of a new sample format) without breaking the binary >> compatibility of the API. Some analysis could then be done of the >> existing limitations for future changes of the SoundFont loader. > > I admit I'm a little rookie when it comes to these things. Keeping the API > backwards compatible shouldn't be that much of a problem, should it? And as > long as we don't change functions into macros or the other way around, the > ABI should be backwards compatible too? And even if it isn't, is there a > problem with breaking the ABI between versions? > I'm also not an expert concerning what can be changed without breaking an API. I think fields can be added to structures, so long as the allocation is handled by the library. I imagine if we come up with a substantially different API for the SoundFont loader, the old one could still remain in parallel with it (new functions, etc for the new API). > // David > Element _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
