[alsa-devel] pcm_rate API question
aquegg at yahoo.co.uk
Mon Sep 30 13:15:13 CEST 2013
----- Original Message -----
> From: Clemens Ladisch <clemens at ladisch.de>
> To: alsa-devel at alsa-project.org
> 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.
More information about the Alsa-devel