Re: [PATCH 1/6] media: v4l2: Add audio capture and output support
From: Shengjiu Wang <shengjiu.wang@gmail.com>
Date: 2023-07-04 04:25:55
Also in:
alsa-devel
On Tue, Jul 4, 2023 at 1:59 AM Mark Brown [off-list ref] wrote:
On Mon, Jul 03, 2023 at 03:12:55PM +0200, Hans Verkuil wrote:quoted
My main concern is that these cross-subsystem drivers are a pain to maintain. So there have to be good reasons to do this.quoted
Also it is kind of weird to have to use the V4L2 API in userspace to deal with a specific audio conversion. Quite unexpected.quoted
But in the end, that's a decision I can't make.quoted
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