2007/11/27, cyanh256@xxxxxxxxxxxx <cyanh256@xxxxxxxxxxxx>: > Stefano, > > I'm a bit busy with the Haiku MIDI interface project at the > moment, but once that's wrapped up (end of the week > maybe?), I'll certainly do some listening tests on the > resampling algorithms. Ok. [...] > My thoughts so far -- > > I skimmed through the code quickly, but I didn't see any > reference to lowpass filtering -- this is usually required prior > to downsampling the audio (to avoid the frequencies above > the new nyquist wrapping around), although is unnecessary > when upsampling. In fact there isn't. The code now is just a very basic math-level intepolator, so I don't think it can be used as it is inside the audio mixer (IMHO it would need no big modifiiccattions however). Regarding lowpass filtering for downsampling, it shouldn't be a problem to add, but it can also be applied before the interpolator itself, so that an advanced user might disable it and/or the same code can be reused for other purposes (can''t think of any actually, since for example a math engine would need much more precision than regular floats). > Upon further thought, I don't think it's entirely necessary for > this specific application -- only if the code were to be used > in some wider context. The reason being, the media kit > mixer spends most of its time upsampling -- all soundcards > made in the last 15 years run at 44.1kHz to 192kHz, and most > recordings are made at 44.1kHz or lower > The only common case where downsampling would be > required is when playing a DVD (48kHz) on a 44.1kHz > soundcard, and in that case, the content between 22kHz > and 24kHz would wrap around to 20kHz to 22kHz. This is > ultrasonic content (and there isn't much there to begin with) > so it probably isn't necessary to filter it out. Ok. > The other thing I noticed while skimming through was that > there doesn't seem to be any kind of encoder state > preservation between calls to the resampling function. > When working with small buffers (typical of soundcard > buffers in BeOS -- I'm using a buffer size of 64 frames), > there's the danger of inaccuracies appearing at the initial > (or last) samples, which could become audible as a tone > at these buffer sizes. Providing some way for the function > to know what samples occured at the end of the previous > buffer (such as passing a state struct into the resampling > function) generally clears it up. *hehe* This is one thing I checked quite well (I hope). It should work on little buffers without problems (if you take a closer look the interpolation "continues" also where it is "normally" impossible by assuming unchanged slopes/coefficients). A problem, instead, is heavy upsampling (I'd say more than 4x), since the last values of each output buffer are guessed as described above, but I think that this problem is common to all interpolators around (maybe not if you use FFT - one could also consider some "shadow zero values" at the beginning and end of the input buffer, or use the input buffer as it was circular). > Regarding the denormal optimizations, this is usually a serious > issue in multimedia -- even on my old AMD machine, I've seen > slowdowns in the order of 200x or more when the numbers > become small enough. Yes, I know. > Rather than put workarounds for the denormal problem in > the resampling algorithm (thus slowing it down), I propose > completely disabling denormals on the CPU across the entire > OS as standard. This is up to Haiku devs :-) Best regards, Stefano