[Sound-open-firmware] amixer pipeline issues

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Mon Jan 25 16:56:04 CET 2021



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/baed1f0283f190e319444d06cdfc7f7c78afc8b1
> 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.


More information about the Sound-open-firmware mailing list