stream capture issue

[chihualee]

For stream capture scenario, I am tracing the behavior of Host (sof/src/audio/host-legacy.c and sof/src/drivers/generic/dummy-dma.c).

The data flow should be: Local-buffer => DMA-buffer => buffer-share-linux.

But I found the data flow in Host is:
First copy data from DMA-buffer to buffer-share-linux,
then copy data from Local-buffer to DMA-buffer ?

I think it's not correct. Did I miss something ?

Thanks.

[dbaluta]

Are you sure? Can you tell us what board are you using? Can you post some code snippets?

[chihualee]

in sof/src/drivers/generic/dummy-dma.c as below,

first invoke dummy_dma_do_copies() to copy data from DMA-buffer to buffer-share-linux,
then invoke notifier_event(...,NOTIFIER_ID_DMA_COPY, ...) that invoke host_dma_cb() that invoke host_common_update() to do
source = hd->local_buffer;
sink = hd->dma_buffer;
ret = dma_buffer_copy_to(source, sink, hd->process, bytes);
/* copy data from Local buffer to DMA-buffer */

I think the order is incorrect...but it's correct for playback scenario.

static int dummy_dma_copy(struct dma_chan_data *channel, int bytes,
uint32_t flags)
{
ssize_t copied;
struct dma_cb_data next = {
.channel = channel,
};
struct dma_chan_pdata *pdata = dma_chan_get_data(channel);

copied = dummy_dma_do_copies(pdata, bytes);
if (copied < 0)
return copied;

next.elem.size = copied;

/* Let the user of the driver know how much we copied */
notifier_event(channel, NOTIFIER_ID_DMA_COPY,
NOTIFIER_TARGET_CORE_LOCAL, &next, sizeof(next));

return 0;
}

[lgirdwood]

@chihualee for capture copying from DSP to host driver, there are two buffers.

1. "Host" buffer in DSP memory. Capture DSP pipeline writes to this and host driver reads from this (host can use DMA or memcpy).
2. ALSA PCM driver buffer in host memory, allocated by driver. Userspace reads from this and driver writes to it (either DMA or memcpy).

The critical thing is to make sure that your R/W pointers are correctly aligned between host driver and DSP FW. i.e. to avoid overrun or underrun. Pls also make sure that the DSP pipeline R/W pointers are updating and buffer 1 is filling, then check same for buffer 2.

ALSA also needs to some data in the host driver buffer 2 before it will unblock a read() from userspace.

[chihualee]

https://github.com/thesofproject/sof/tree/main/src/drivers

I can't see the file drivers/dma/dma_nxp_sof_host_dma.c you mentioned.

[chihualee]

https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/dma/dma_nxp_sof_host_dma.c

I got it in Zephyr. But My SOF(2.8) and Zephyr(3.5) version is not too new enough...

Then I try to checkout SOF to the latest version as below.
commit 2e39952
Author: Laurentiu Mihalcea laurentiu.mihalcea@nxp.com
Date: Mon Aug 19 15:05:39 2024 +0300

Ther I grep dma_nxp_sof_host_dma under SOF folder, and nothing return... I think maybe it's not easy to build code with dma_nxp_sof_host_dma.c....
sof$ grep -r dma_nxp_sof_host_dma .

[dbaluta]

Yes, the driver is in zephyr repo. We switched from SOF standalone drivers to Zephyr.

Is very easy to build latest SOF.

Just clone the lastest sof version and then run:

$ ./scripts/xtensa-build-zpehyr -u -p imx8m (or whatever platform you use)

[chihualee]

@dbaluta

I tried to fix this bug, however the original design is bundled with capture and playback, it's not easy to fix it robustly.

The attached file is my patch, and I test it work.

Can you review this patch ? (You can disable log in patch manually to prevent log overflow)

my_patch.patch

[lgirdwood]

@chihualee can you send your patch as a pull request for review/merge process. Thanks !