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