[FEATURE] Add virtual DAI

[dbaluta]

Is your feature request related to a problem? Please describe.

We want to have a Virtual DAI for two reasons:

• debugging and rapid prototyping. We want to be able to create a quick audio pipeline without using a real DAI device.
• first step in implementing a software loopback pipeline that will help implement a memory to memory processing pipeleline

Describe the solution you'd like

The DAI should have two directions:

• playback -> just get the data from source and do 'consume' it. Similar with /dev/null.
• capture -> generate data (zeroes or some patterns) and send it to sink. Similar with /dev/zero or /dev/urandom

Additional context

End goal would be to use this Virtual DAI to implement memory to memory processing. See Compress API interface discussion here: https://lore.kernel.org/all/CAA+D8APHT8-wsKjqbkP+0gEYXWRFfpNuSpjAQ6Uf_RxZzNQT-g@mail.gmail.com/T/

Cc: @AnneOnciulescu

[plbossart]

It would make sense indeed to have a 'Null' DAI similar to the 'Null' sink/source in PulseAudio, i.e. an entity that can consume data (playback) or generate data (capture) based on a timer. The loopback could be added. This would handy to e.g. replace SSP or DMIC in the 'nocodec' Intel topologies.

The path to the memory-to-memory solution is less clear. This ALSA/compress solution is based on the premise that there is no real-time limitation or behavior, the data will be processed as fast as possible. This doesn't align well with the rest of the SOF infrastructure IMHO. a "DAI" is really meant to model physical interfaces, and the memory-to-memory doesn't rely on physical interfaces at all. There's also a risk that such a pipeline would prevent others from running, by just using all the processing.

[kv2019i]

@singalsu had a draft PR to this direction -> #8830