Tobias Doerffel schrieb: > Hi, > > Am Dienstag, 6. April 2010 21:52:41 schrieben Sie: > >> 1. Chose a sane but fixed output-sampling-rate (44.1 kHz, 48 kHz, 96 >> kHz ... any of these will do. I would rather not go far beyond 96 >> kHz... Why? Given alias-"free" generators no one even can hear >> 22.05 kHz tones...) >> > When doing post-processing of render output, samplerates up to 192 KHz IMHO > can be helpful - even if most people won't need it. > I never encountered this and I can't see a reason for it either, currently. So, for what operations would this be beneficial? Due to the fact that we are no bats, only sample-rates up to (maybe even this is too high... hmm,...) 96kHz make some sense at all. And only if post-processing of some sort is involved. For listening the finished product 44.1 kHz is definitely enough (16-bit maybe a little bit too less, but the sampling-rate is OK for that...).
> That's whats already done, if I didn't understand you wrong. > :) no, you don't ... This is already happening all the day... :) >> would _not_ opt for alias-free waveform-generators >> > To be honest, there's a checkbox but currently it does not have any impact > yet.. so don't let you get confused by that.. ;-) > Oh, good... :) > Why downsample before filters and effects? Usually you want to process audio > data at highest samplerate until the end and downsample afterwards. > Exceptions > are made for LADSPA plugins that are known/were reported to go crazy with > higher samplerates. > The reason is just, that going to the ends of the spectrum (either lowest or highest end, doesn't matter...) the coefficients of any DSP-Algo may get unstable due to very low or very high values needed to coope with the higher sampling-rate. While there exist many algorithms (filter+FX) which do not suffer too much from that problem so they are usable on a quite large range of sample-rates, some of the more interesting ones are difficult to be tuned for stable operation on such a large scale of supported sampling-rates. While this is strongly related to numerical precision it is something which can be solved. But it is difficult to do (and to do it "fast" enough for real-time) and most of the time the gain in quality is so marginal that it's just not worth the effort... > Hm.. probably true for filters but not in general. However I'm not completely > familiar with all the higher DSP math behind filters etc. so correct me if > I'm > wrong. > Well, for anything which has at least two poles (so, yes, mainly for IIR-digital filters :)), this becomes "interesting"... It doesn't apply on such alike as reverbs or FIR-Filters. My point just was that even with these the gain in quality is marginal (if present at all) and the computational load is reduced in either ways... >> [*] I personally regard a stable rendering quality which as closely as >> possible resembles the real-time output (but of course without the >> alias) as being essential for the acceptance of lmms against other >> solutions, such as MusE or commercial products. Just because if one >> presses the big render-knob he/she wants to know it sounds the same ... >> just better (that is without the aliasing) than before... >> > Do you know how other solutions handle this issue? Do they all downsample > immediately after the generators? > At least the products I know the internals of, do it this way: Either they generate the waveforms in a band-limited-manner directly on f_s or they generate the waveforms with a very high sampling-rate (power of two to f_s) and down-sample to f_s immediately afterwards, so all following DSP is done on that lower rate... all the best, Stefan ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
