Audio: Start add simulated DAI and host component #8830
Conversation
| } | ||
|
|
||
| DECLARE_MODULE(sys_comp_host_init); | ||
| SOF_MODULE_INIT(host, sys_comp_host_init); |
There was a problem hiding this comment.
this and the dai version look like a lot of copy-paste, is this what we want to do? The code of the original source file will evolve over time so it's a maintenance nightmare to keep two separate files aligned by parts and different when they need to be different.
Code management/maintainability is hard.
There was a problem hiding this comment.
Good, question. This way I would remove the disabled code parts. Though I didn't yet start to work with host so it's now just a duplicated. Other way would be adding abstraction to zephyr DAI and host and use stub functions for DMA and HW related for the simulated version.
singalsu
force-pushed
the
fake_host_dai
branch
from
890ccbe to
68f1e90
Compare
|
The just updated version adds a triangle wave generator to DAI capture and and glitch detector to DAI playback. |
singalsu
force-pushed
the
fake_host_dai
branch
from
68f1e90 to
4c06cc4
Compare
singalsu
changed the title
|
This version adds to host triangle wave generate to playback and to capture detecting of glitches. Both triangle generators in DAI and host have now an option to force making glitch every 5s for sanity check to make sure glitches are detected. |
There was a problem hiding this comment.
Thanks @singalsu - how would we use to fake the DAI today ? I assume we locally apply and enable in the Kconfig. Do we need any other Kconfig or usgae instructions.
@lyakh @serhiy-katsyuba-intel @abonislawski @kv2019i @ujfalusi fyi - this will enable some testing without any DAI IP (DAI and DMA) programming i.e. we should be able to see if this can change repro rates.
singalsu
force-pushed
the
fake_host_dai
branch
from
4c06cc4 to
2a72e1a
Compare
These replace the real dai-zephyr.c and host-zephyr.c if enabled in Kconfig. Simulation versions are copies of the originals without changes. The simulation versions are enabled by setting CONFIG_ZEPHYR_SIMULATED_HOST_DRIVER=y CONFIG_ZEPHYR_SIMULATED_DAI_DRIVER=y Signed-off-by: Seppo Ingalsuo <[email protected]>
singalsu
force-pushed
the
fake_host_dai
branch
from
2a72e1a to
e81de8a
Compare
singalsu
changed the title
|
@singalsu AFAIK the simulated Host will self-generate the data right? Can we call it "Virtual"? @lgirdwood @singalsu we are trying to decouple SOF firmware from Linux kernel to have it run on MCUs so this could be a good start for us. |
Virtual could be better., I'm not good in naming things. It's still a functional host with data flow to/from user but the playback data is replaced. The next step would be to remove the host DMA traffic, but I have no idea if such is possible without changes to kernel and other SOF framework. The DAI part is now decoupled from HW, so it is "virtual". |
With this change the DAI just consumes all playback samples and produces triangle wave capture samples. In the playback direction the consumed samples are checked for glitches base on assumed triangle wave. There is also count of leading zero PCM samples per channel. It can be used to estimate latency in the playback path. Signed-off-by: Seppo Ingalsuo <[email protected]>
The playback stream is replaced with a triangle wave. The capture stream is passed but checked for glitches. In capture direction the number of leading zeros for every channel is checked and reported in trace. It can be used to estimate latency in the capture path. Signed-off-by: Seppo Ingalsuo <[email protected]>
singalsu
force-pushed
the
fake_host_dai
branch
from
e81de8a to
5a227d4
Compare
|
Update - removed device driver probe from dai_get(). |
|
|
||
| config ZEPHYR_SIMULATED_DAI_DRIVER | ||
| bool "Simulate DAI component" | ||
| default n |
There was a problem hiding this comment.
how do we get the CI to test these?..
| if ((i & 1) == 0) | ||
| tg->pcm_increment[i] = 1; | ||
| else | ||
| tg->pcm_increment[i] = -1; |
There was a problem hiding this comment.
optional, matter of taste:
tg->pcm_increment[i] = 1 - 2 * (i & 1);
|
|
||
| static void dai_glitch_core(struct comp_dev *dev, | ||
| struct dai_glitch_detect_state *gd, | ||
| int *c, |
There was a problem hiding this comment.
maybe call it channel for more clarity
| @@ -228,7 +513,7 @@ dai_dma_cb(struct dai_data *dd, struct comp_dev *dev, uint32_t bytes, | |||
| pcm_converter_func *converter) | |||
| { | |||
| enum dma_cb_status dma_status = DMA_CB_STATUS_RELOAD; | |||
| int ret; | |||
| int ret = 0; | |||
|
|
||
| for (i = 0; i < channels; i++) | ||
| if (gd->no_signal[i]) | ||
| no_signal_yet = true; |
| if (gd->no_signal[i]) | ||
| no_signal_yet = true; | ||
|
|
||
| if (!no_signal_yet && !gd->zeros_count_reported) { |
There was a problem hiding this comment.
is this correct? !no_signal_yet seems to suggest, that signal is present?
|
most comments apply to both host and DAI |
|
@singalsu what topology would you use to test these? Also, how do you start a simulated host playback or capture? Would you still need a PCM in the topology? Ideally, we also want hostless capabaility right? |
This is not intended for MCU, but you could modify for MCUs as needed - intention here was to help test code flows without invoking any IP programming. i.e. pipelines could be created and run without programming IPs (and do memory to memory copies). |
Re hostless - yes, that would be a followup. i.e. it would use locally generated test data instead of copying from host. |
No description provided.