[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