On 1/25/21 9:37 AM, Daniel Baluta wrote:
Hi Pierre,
We are experiencing issues using mixer piplines. I think it is the same issue mentioned here:
https://github.com/thesofproject/sof/issues/3171
We get the issue for all formats: S{16|24|32}_LE
At some point aplay stops with I/O write error.
This PR: https://github.com/plbossart/sof/commit/baed1f0283f190e319444d06cdfc7f7c78af... doesn't fix the issues as it seems it does for Intel.
We are investigating and suspecting it might be a wild scheduling issue, anyway I have a generic question about this scenario. Looking at sof-cht-max98090.m4 we have 3 pipelines involved in the playback:
-> [pipeline 1] -> playback DAI using 2 periods -> [pipeline 3] -> playback pipeline 3 on PCM 0 with 1ms deadline -> [pipeline 4] -> playback pipeline 4 on PCM 1 with 10ms deadline.
The question is why pipeline 3 and pipeline 4 are not symmetrical, meaning that they should have the same period size. But one has 1ms and the other one has 10ms.
What's the idea behind this?
That difference was intentional.
One path is supposed to be 'low-latency' and one 'deep-buffer'. The latter can be used to reduce the interrupt rate, turn off the path to DDR and improve power consumption.
That said, I honestly don't think this case works. we've seen that a large period for this deep-buffer stream breaks quite often. I haven't had time to investigate, but I think the SOF scheduling does not quite support this sort of usages. The mixer should use its own period/scheduling and all sources providing data to the mixer may or may not be aligned to that mixer period.
There was already a conceptual issue with pause-push/pause-release, now it's fixed but the SOF mixer still needs a lot of love. IIRC another problem is that if there are two sources that can provide data at different formats, the *first* source to be active will define the format due to hw_params propagation. It's wrong, the mixer should have its own data format and sources should process their inputs to match that format.