On Mon, 2017-12-11 at 11:18 +0200, Seppo Ingalsuo wrote:
On 08.12.2017 22:37, Liam Girdwood wrote:
Return the number of frames we produce in the copy() function.
Signed-off-by: Liam Girdwood liam.r.girdwood@linux.intel.com
src/audio/src.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/audio/src.c b/src/audio/src.c index 0103e2e..d494d96 100644 --- a/src/audio/src.c +++ b/src/audio/src.c @@ -535,9 +535,12 @@ static int src_copy(struct comp_dev *dev) if (consumed > 0) comp_update_buffer_consume(source, consumed);
- if (produced > 0)
- if (produced > 0) { comp_update_buffer_produce(sink, produced);
return cd->param.blk_out;I wonder if it can cause problems that this value is the minimum number of frames for SRC to run. The actual processed is +N sometimes with sample rates those don't have an integer number of frames in schedule interval like with the 44.1 kHz family rates in a 48 kHz mixer.
If need the actual frames count could be get from inside the copy function to avoid dividing the produced value.
It's not actually used by pipeline atm so may be dropped (i.e we return 0), pipeline just cares about negative error numbers atm.
Liam
}
/* produced no data */ return 0; }
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware