[PATCH 1/6] media: v4l2: Add audio capture and output support

[Shengjiu Wang]

On Tue, Jul 4, 2023 at 1:59 AM Mark Brown <broonie at kernel.org> wrote:

> On Mon, Jul 03, 2023 at 03:12:55PM +0200, Hans Verkuil wrote:
>
> > My main concern is that these cross-subsystem drivers are a pain to
> > maintain. So there have to be good reasons to do this.
>
> > Also it is kind of weird to have to use the V4L2 API in userspace to
> > deal with a specific audio conversion. Quite unexpected.
>
> > But in the end, that's a decision I can't make.
>
> > So I wait for that feedback. Note that if the decision is made that this
> > can use V4L2, then there is quite a lot more that needs to be done:
> > documentation, new compliance tests, etc. It's adding a new API, and that
> > comes with additional work...
>
> Absolutely, I agree with all of this - my impression was that the target
> here would be bypass of audio streams to/from a v4l2 device, without
> bouncing through an application layer.  If it's purely for audio usage
> with no other tie to v4l2 then involving v4l2 does just seem like
> complication.
>

This audio use case is using the v4l2 application layer. in the user space
I need to call below v4l2 ioctls to implement the feature:
VIDIOC_QUERYCAP
VIDIOC_TRY_FMT
VIDIOC_S_FMT
VIDIOC_REQBUFS
VIDIOC_QUERYBUF
VIDIOC_STREAMON
VIDIOC_QBUF
VIDIOC_DQBUF
VIDIOC_STREAMOFF

why the driver was put in the ALSA, because previously we implemented
the ASRC M2P (memory to peripheral) in ALSA,  so I think it is better to
add M2M driver in ALSA.  The hardware IP is the same. The compatible
string is the same.

Best regards
Wang Shengjiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20230704/91ac19c0/attachment.htm>