[RFC] dai: dma_buffer: fix pop noise issue when start playback

[RanderWang]

Another type of pop noise.

The pop noise is generated by invalid data in dma buffer.
Since all buffers are cleared by pipeline_comp_prepare except
dma buffer, so clear it to zero to avoid this issue.

[dbaluta]

@RanderWang PR looks good to me, lets wait for other people to review.

I wonder if you could share with us more about your tools for fixing this kind of bugs. So, I assume you are using audacity? and also a separate machine to capture the output from DUT?

[RanderWang]

@RanderWang PR looks good to me, lets wait for other people to review.

I wonder if you could share with us more about your tools for fixing this kind of bugs. So, I assume you are using audacity? and also a separate machine to capture the output from DUT?

No, I enable loop-back feature which routes stream data from playback to capture. This feature may be supported by codec or vendor audio IP.

[lgirdwood]

@tlauda fyi
@RanderWang the SSP FIFO may be another pop source at stream start. i.e. it could have some stale data from previous playback that is not flushed. This would be obvious if the pop was always <= 16 samples. If so, you could hopefully manually clear it by writing 16 0s to the FIFO (and clearing overrun status bit).

[plbossart]

@tlauda fyi
@RanderWang the SSP FIFO may be another pop source at stream start. i.e. it could have some stale data from previous playback that is not flushed. This would be obvious if the pop was always <= 16 samples. If so, you could hopefully manually clear it by writing 16 0s to the FIFO (and clearing overrun status bit).

IIRC there was an SSP FIFO clear already. 992f081
('ssp: cavs: make sure that SSP FIFO is empty')

Don't know if this is enough though?

[plbossart]

does this also force the zeroed data to be written back?

[RanderWang]

good question. This function does it.

static inline void buffer_zero(struct comp_buffer *buffer)
{
tracev_buffer_with_ids(buffer, "stream_zero()");
bzero(buffer->stream.addr, buffer->stream.size);
if (buffer->caps & SOF_MEM_CAPS_DMA)
dcache_writeback_region(buffer->stream.addr,
buffer->stream.size);
}

[RanderWang]

@tlauda fyi
@RanderWang the SSP FIFO may be another pop source at stream start. i.e. it could have some stale data from previous playback that is not flushed. This would be obvious if the pop was always <= 16 samples. If so, you could hopefully manually clear it by writing 16 0s to the FIFO (and clearing overrun status bit).

Thanks @lgirdwood . We also clear FIFO in sdw master controller.

[YvonneYang2]

Since aplay with speaker is blocked by #2570 on latest master branch, only tested it with headphone. Pop noise is gone except has slight noise when switch foreground from background during aplay. Same result as cml-010-hotfix2 branch.

[lgirdwood]

SOFCI TEST

[RanderWang]

SOFCI TEST

@xiulipan It is not caused by my PR.

[xiulipan]

@RanderWang What is not caused by your PR?
I do see some logger issue from on-device test. But with the logger issue now. I am not sure if others are known issues.

[RanderWang]

@RanderWang What is not caused by your PR?
I do see some logger issue from on-device test. But with the logger issue now. I am not sure if others are known issues.

This PR just clear a DMA buffer used by GP-DMA in prepare function. Null sof log in failed case to prove it is connected to this PR.

[lgirdwood]

Jenkins CI known issues.