[Sound-open-firmware] [PATCH] dai: prepare does not need to bzero buffers.
Already done by pipeline, but prepare still needs to write back. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> --- src/audio/dai.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/audio/dai.c b/src/audio/dai.c index cc61e83..2fbfc5f 100644 --- a/src/audio/dai.c +++ b/src/audio/dai.c @@ -442,15 +442,14 @@ static int dai_prepare(struct comp_dev *dev) return -EINVAL; } - /* writeback buffer contents from cache */ + /* initialise buffers */ if (dev->params.direction == SOF_IPC_STREAM_PLAYBACK) { + + /* write back buffer contents from cache for playback */ dma_buffer = list_first_item(&dev->bsource_list, struct comp_buffer, sink_list); - /* fill playback periods with silence */ - bzero(dma_buffer->r_ptr, dma_buffer->avail); - - dcache_writeback_region(dma_buffer->r_ptr, dma_buffer->avail); + dcache_writeback_region(dma_buffer->addr, dma_buffer->size); } /* dma reconfig not required if XRUN handling */ -- 2.14.1
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> --- src/audio/volume.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/audio/volume.c b/src/audio/volume.c index e741b1a..9ad48e6 100644 --- a/src/audio/volume.c +++ b/src/audio/volume.c @@ -573,12 +573,12 @@ static int volume_copy(struct comp_dev *dev) * check for XRUNs */ if (source->avail < cd->source_period_bytes) { trace_volume_error("xru"); - comp_overrun(dev, source, cd->source_period_bytes, 0); + comp_underrun(dev, source, cd->source_period_bytes, 0); return -EIO; /* xrun */ } if (sink->free < cd->sink_period_bytes) { trace_volume_error("xro"); - comp_underrun(dev, sink, cd->sink_period_bytes, 0); + comp_overrun(dev, sink, cd->sink_period_bytes, 0); return -EIO; /* xrun */ } -- 2.14.1
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; + } + /* produced no data */ return 0; } -- 2.14.1
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.
+ }
+ /* produced no data */ return 0; }
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
On 11.12.2017 13:43, Liam Girdwood wrote:
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.
Oh, that's fine then. Cheers, Seppo
participants (2)
-
Liam Girdwood -
Seppo Ingalsuo