Hi Mark
On Tue, Jul 4, 2023 at 12:03 PM Shengjiu Wang shengjiu.wang@gmail.com wrote:
On Tue, Jul 4, 2023 at 1:59 AM Mark Brown broonie@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.
Could you please share more of your ideas about this patch? and could
you please check further about this implementation.
I tried to find a good interface in ALSA for this m2m request, but didn't find one, then I try the V4L2, find it is good this audio case.
but it needs to extend the V4L2 API.
I have no idea how to go on, could you please recommend?
best regards wang shengjiu