g_sdl at zewt.org
Sun Apr 6 15:01:31 EDT 2003
On Sun, Apr 06, 2003 at 08:25:44PM +0200, Frank Ranostaj wrote:
> Yes, it is intended to do so. I though, it was more or less working.
> The allocation interface in playsound should take a additional buffer
> length into account for the settling time of the filter.
> The conversion e.g. 44.1 <-> 48.0 is approximated by 44.0 <-> 48.0.
> The use of Splines can be superior to the windowed sin(x)/x filter
> used in the alt-converter.
That won't work; not for me, anyway. It'll result in a lot of drift. The
application I'm working on, at least, has a fundamental requirement that
there be no long-term drift in the conversion, since it syncs events in
music to timestamps. A few samples jitter doesn't matter, but cumulative
drift will wreak havoc.
Just to be clear on what I mean: if I open a file with 10 minutes worth
of audio, and my data says that there's a note at 650s200ms in, the
conversion can't introduce drift (by being an approximation), since
that'll mess up all of the timestamps. I guess I'll have to write my own
resampler to guarantee this (possibly at a loss of quality).
(I'm aware that having a timestamped music stream would be a lot more
robust, but there are already thousands of songs in the wild synced in
this way, and the program is designed around that. It's a data
limitation that I have to cope with.)
> I presumed there was not much interest in the rate converter and my
> lousy english has made it diffcult to explain functions of the converter,
> so I am uncertain on how to proceed.
I couldn't make heads or tails of it. :) It isn't working for me, at
least, but if it's going to drift it won't help me anyway. (I got a lot
of noise when resampling was being used.)
More information about the sdlsound