Re: pcm_rate API question

[Clemens Ladisch <clemens@ladisch.de>]

Rob Sykes wrote:
>> Typically there is some buffering/delay within a resampler -- how
>> does the pcm_rate API allow for this?

The API itself does not allow for this.  Your code must generate
dst_frames samples.

At startup, prefix the output with zero samples.  For example,
rate_samplerate.c in the alsa-plugins package does this:

    src_short_to_float_array(src, rate->src_buf, src_frames * rate->channels);
    src_process(rate->state, &rate->data);
    if (rate->data.output_frames_gen < dst_frames)
            ofs = dst_frames - rate->data.output_frames_gen;
    else
            ofs = 0;
    src_float_to_short_array(rate->dst_buf, dst + ofs * rate->channels,
                             rate->data.output_frames_gen * rate->channels);

> If, as you say above, the buffer sizes

the period sizes

> define the conversion ratio, then this seems to imply that alsa is
> unable to perform accurate rate conversion for one of the most common
> uses!

The conversion indeed is not accurate, unless you are using a period
size of an integer multiple of 441 frames.  In your example, the
application probably used a buffer of 0.5 s and four periods per buffer;
it should either double the buffer size or halve the number of periods.


Regards,
Clemens