On Tue, Jul 4, 2023 at 1:59 AM Mark Brown <broonie@xxxxxxxxxx> 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
