[tlauda]

Increases number of periods for low latency playback pipeline
from 1 to 2 for volume and mixer components. 1 period
is not good enough to have continuous DMA transfer across
the whole pipeline, especially with the new copy flow,
which requires playback pipeline preload.

Signed-off-by: Tomasz Lauda tomasz.lauda@linux.intel.com

[juimonen]

@tlauda did this fix the "metallic" sound?

[plbossart]

Increases number of periods for low latency playback pipeline from 1 to 2 for volume and mixer components. 1 period is not good enough to have continuous DMA transfer across the whole pipeline, especially with the new copy flow, which requires playback pipeline preload.

Humm, isn't there something fundamentally broken if we have to increase the latency of the low-latency pipeline? This doesn't look right to me.

[juimonen]

@tlauda @plbossart I can confirm that this fixes the metallic sound on minnowboard with first playback. But if you use "aplay -i" and resume/pause the pipeline couple of times, you will get the same metallic sound as before. So now this behaves more like @ranj063 simplified pipeline, but the issue is still there. So somehow the dma pointers get out of sync...

Shouldn't we get xrun if the pipeline can't keep up with the dma?

[xiulipan]

SOFCI TEST

[tlauda]

@plbossart We don't increase latency, just the buffers inside the pipe. Host and Dai already had 2 periods. I'm truly amazed that it worked previously with just 1 period buffers inside the pipeline. Probably just because we had this "workaround" in the Dai to move buffer pointer before the start, but still it was pure luck that we didn't observe any glitches nor xruns.

@juimonen Pause/release is another issue and I'm gonna fix it in another PR.

[plbossart]

On 4/10/19 3:41 AM, Tomasz Lauda wrote: @plbossart <https://github.com/plbossart> We don't increase latency, just the buffers inside the pipe. Host and Dai already had 2 periods. I'm truly amazed that it worked previously with just 1 period buffers inside the pipeline. Probably just because we had this "workaround" in the Dai to move buffer pointer before the start, but still it was pure luck that we didn't observe any glitches nor xruns.

Humm, how does increasing the number of buffers not increase the latency? I must be missing something here, for elements that don't add new samples such as volumes in theory they could take the data from the host 'read-only' period and stick into the DAI 'write-only' period.

[tlauda]

On 4/10/19 3:41 AM, Tomasz Lauda wrote: @plbossart https://github.com/plbossart We don't increase latency, just the buffers inside the pipe. Host and Dai already had 2 periods. I'm truly amazed that it worked previously with just 1 period buffers inside the pipeline. Probably just because we had this "workaround" in the Dai to move buffer pointer before the start, but still it was pure luck that we didn't observe any glitches nor xruns.
Humm, how does increasing the number of buffers not increase the latency? I must be missing something here, for elements that don't add new samples such as volumes in theory they could take the data from the host 'read-only' period and stick into the DAI 'write-only' period.

Let's take our example pipeline: host - vol - mixer - vol - dai.
Dai needs at least two periods of data to properly start transfer without any glitches, because after triggering first period it instantly starts copying the next period.
So the first pipeline copy for render is so called "preload copy" and it should copy the whole buffer (2 periods in our case). Unfortunately we don't have large enough buffers across the pipeline to do it.
As for latency, we will still copy the same amount of data per millisecond as previously, just with the larger buffers to make sure we don't mess up our read and write pointers.

[juimonen]

@tlauda did you try the "aplay -i" with pause/resume from space bar? you still get the metallic sound like every third time... should we preload the buffers with pause/resume also? or something similar...

[tlauda]

@juimonen No, for pause/release the data is already there. The root cause is that buffer pointer alignment with next linked list item is done only for block transfers and not the manual linked list. I will have it fixed in the separate PR.

[plbossart]

@tlauda so you're saying this change only impacts the start, right?

I must still be missing something. It was my understanding that the direction was to start the DAI first, possibly with zero-value outputs and at some point start pushing mixed data in the output (I believe it's how the closed-source firmware worked and clearly remember the need to track the delta between interface start and insertion of data for cross-timestamp support). It looks like now we have valid data pushed out as soon as the SSP starts?

[tlauda]

@plbossart I'm not sure how it was done for closed source, but yes, instead of changing the start pointer of dai component and pushing out zeroes we are transferring valid data right away. Also we need to take into consideration how we are currently not limited to period size copy as it was before. We are now copying as much data as possible for every component by reading DMA read and write pointers, which eliminated many "workarounds" around e.g. pause/release.
To sum up, this change doesn't increase nor affect any latency in terms of DSP processing.

[plbossart]

Thanks @tlauda for the explanations, much appreciated. I hope this solution is not going to bite us when we enable the on-demand SSP clocks (which means DMA transfers even in the absence of data) but that's for another day.

[lgirdwood]

@xiulipan CI failure on BYT nocodec. can you check.

[xiulipan]

@lgirdwood
Used to be some regression from #1250 fixed by thesofproject/linux#816

If you would like to rebase and retest, there will be four platform fail due to the ABI issues: thesofproject/linux#822

There are a lot of regressions happen last week and CI have a unstable code base for testing.