[FEATURE] Allow components/buffers to XRUN

[lgirdwood]

Is your feature request related to a problem? Please describe.
Currently if a component source buffer underruns or a component sink buffier overruns the pipeline will enter an XRUN status and attempt recovery. This is desired in most pipelines but some topologies need to support use cases where we expect buffers to underrun or overrun.

Host ---> Proc----> Selector0 --> Buf0 ---- > DAI Playback
                      |
                      v
                     Buf1
                      |
                      v
Host <---------------Selector1 <----- Buf2 <----- Echo Ref DAI

In the example above we two host PCMs that can be independently started/stopped thereby causing buf1 to either underrun or overrun (and stop the pipelines). Buf1 should be permmitted to underrun or overrun without invoking pipeline XRUN logic and should over write oldest data (for overrun) and readback 0s (for underrun).

Describe the solution you'd like
Add two new topology token for buffers.

TOKEN_BUFFER_UNDERRUN_NO_XRUN
TOKEN_BUFFER_OVERRUN_NO_XRUN

Firmware should process these tokens and if set for a buffer will not invoke pipeline XRUN status.
If buffer overflows, it should overwrite oldest data.
If buffer underruns, it should read back 0s.

[lgirdwood]

Needed for #2407 and #2462

[lgirdwood]

@akloniex @sebcarlucci fyi.

[bkokoszx]

@lgirdwood
It will also be required in smart amp topology (#1896). I don't know whether somebody is working on it right now. If not, I can assign myself to it.

[lgirdwood]

@bkokoszx can you have a chat with @akloniex - also needed for echo ref

[akloniex]

@lgirdwood Regarding implementation details for the underrun case, I can think of 2 ways of approaching the subject:

1. Minimal changes, mostly focused around components' copy functions (check underrun-related flag in buffer, read as much as buffer has, fill in the zeros as needed)
2. Far-fetched changes regarding buffer read management, so that underrun would be transparent to the components, by utilizing behaviour similar to std fread()

Now, the first approach is much easier to develop and doesn't involve any big changes to the buffer API, but it comes with quite a heavy drawback - every component has to implement buffer underrun separately. The second approach is the exact opposite.

If you have any suggestions on how to approach this, how to improve on any of the above ideas, or if you have a different one of your own, then please point me in the right direction.

[lbetlej]

@lgirdwood @akloniex @tlauda could you follow up on idea regarding buffer reader API ?

[tlauda]

@lgirdwood Is this mechanism in some way related to the improved buffer locking API you've mentioned here #2545 (comment)?

[lgirdwood]

@tlauda yes, hooking into the buffer API is probably the best way forward. i.e.

/* acquires lock for bytes to read - buffer will 0 bytes here if we underrun AND underrun flag is true */
buffer_rlock(buffer, bytes, flags);
/* acquires lock for bytes to write - buffer wont XRUN here if we overrun AND overrun flag is true */
buffer_wlock(buffer, bytes, flags);