[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce5f4c0f-25ff-4b20-a3f3-2a11ccb8b5f4@perex.cz>
Date: Mon, 6 May 2024 11:42:39 +0200
From: Jaroslav Kysela <perex@...ex.cz>
To: Shengjiu Wang <shengjiu.wang@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>
Cc: Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.de>,
Sebastian Fricke <sebastian.fricke@...labora.com>,
Shengjiu Wang <shengjiu.wang@....com>, hverkuil@...all.nl,
sakari.ailus@....fi, tfiga@...omium.org, m.szyprowski@...sung.com,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
Xiubo.Lee@...il.com, festevam@...il.com, nicoleotsuka@...il.com,
lgirdwood@...il.com, tiwai@...e.com, alsa-devel@...a-project.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On 06. 05. 24 10:49, Shengjiu Wang wrote:
> Even now I still think V4L2 is the best option, but it looks like there
> are a lot of rejects. If develop a new ALSA-mem2mem, it is also
> a duplication of code (bigger duplication that just add audio support
> in V4L2 I think).
Maybe not. Could you try to evaluate a pure dma-buf (drivers/dma-buf) solution
and add only enumeration and operation trigger mechanism to the ALSA API? It
seems that dma-buf has enough sufficient code to transfer data from and to the
kernel space for the further processing. I think that one buffer can be as
source and the second for the processed data.
We can eventually add new ioctls to the ALSA's control API (/dev/snd/control*)
for this purpose (DSP processing).
Jaroslav
--
Jaroslav Kysela <perex@...ex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
Powered by blists - more mailing lists