[alsa-devel] pcm_rate API question

[Rob Sykes]

----- Original Message -----

> From: Clemens Ladisch <clemens at ladisch.de>
> To: alsa-devel at 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