----- Original Message -----
From: Clemens Ladisch clemens@ladisch.de To: alsa-devel@alsa-project.org Cc: Sent: Monday, 30 September 2013, 9:59 Subject: Re: [alsa-devel] pcm_rate API question
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,
Thanks Clemens. Having to prefix the output with a signal that is unrelated to the input signal doesn't seem great, though I guess this just manifests itself as a delay (variable, dependent on resampler, etc.) and may go unnoticed. Of more concern is that this situation can apparently occur at any time: "after that first call all subsequent calls will probably get you about 2000 samples out for every 1000 samples you put in" — only "probably", not "always"; occurring after the start, this will likely cause audible distortion.
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.
Oh okay, the application in question was aplay 1.0.25; maybe it's since been fixed, but no matter, it seems that the above buffering issue is the main problem.
Cheers, Rob