Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 02 Aug 2023 13:22:51 +0200
Message-ID: <87il9xu1ro.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Hans Verkuil <hverkuil@xs4all.nl>
Cc:     Shengjiu Wang <shengjiu.wang@nxp.com>, sakari.ailus@iki.fi,
        tfiga@chromium.org, m.szyprowski@samsung.com, mchehab@kernel.org,
        linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
        shengjiu.wang@gmail.com, Xiubo.Lee@gmail.com, festevam@gmail.com,
        nicoleotsuka@gmail.com, lgirdwood@gmail.com, broonie@kernel.org,
        perex@perex.cz, tiwai@suse.com, alsa-devel@alsa-project.org,
        linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
In-Reply-To: <47d66c28-1eb2-07f5-d6f9-779d675aefe8@xs4all.nl>
References: <1690265540-25999-1-git-send-email-shengjiu.wang@nxp.com>
        <47d66c28-1eb2-07f5-d6f9-779d675aefe8@xs4all.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Wed, 02 Aug 2023 09:32:37 +0200,
Hans Verkuil wrote:
> 
> Hi all,
> 
> On 25/07/2023 08:12, Shengjiu Wang wrote:
> > Audio signal processing has the requirement for memory to
> > memory similar as Video.
> > 
> > This patch is to add this support in v4l2 framework, defined
> > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
> > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
> > for audio case usage.
> > 
> > The created audio device is named "/dev/audioX".
> > 
> > And add memory to memory support for two kinds of i.MX ASRC
> > module
> 
> Before I spend time on this: are the audio maintainers OK with doing
> this in V4L2?
> 
> I do want to have a clear statement on this as it is not something I
> can decide.

Well, I personally don't mind to have some audio capability in v4l2
layer.  But, the only uncertain thing for now is whether this is a
must-have or not.

IIRC, the implementation in the sound driver side was never done just
because there was no similar implementation?  If so, and if the
extension to the v4l2 core layer is needed, shouldn't it be more
considered for the possible other route?


thanks,

Takashi