<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 3, 2023 at 9:25 PM Takashi Iwai <<a href="mailto:tiwai@suse.de">tiwai@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 03 Jul 2023 15:12:55 +0200,<br>
Hans Verkuil wrote:<br>
> <br>
> On 03/07/2023 14:53, Mark Brown wrote:<br>
> > On Mon, Jul 03, 2023 at 02:07:10PM +0200, Takashi Iwai wrote:<br>
> >> Shengjiu Wang wrote:<br>
> > <br>
> >>> There is no such memory to memory interface defined in ALSA.  Seems<br>
> >>> ALSA is not designed for M2M cases.<br>
> > <br>
> >> There is no restriction to implement memory-to-memory capture in ALSA<br>
> >> framework.  It'd be a matter of the setup of PCM capture source, and<br>
> >> you can create a corresponding kcontrol element to switch the mode or<br>
> >> assign a dedicated PCM substream, for example.  It's just that there<br>
> >> was little demand for that.<br>
> > <br>
> > Yeah, it's not a terrible idea.  We might use it more if we ever get<br>
> > better support for DSP audio, routing between the DSP and external<br>
> > devices if driven from the CPU would be a memory to memory thing.<br>
> > <br>
> >> I'm not much against adding the audio capture feature to V4L2,<br>
> >> though, if it really makes sense.  But creating a crafted /dev/audio*<br>
> >> doesn't look like a great idea to me, at least.<br>
> > <br>
> > I've still not looked at the code at all.<br>
> <br>
> My main concern is that these cross-subsystem drivers are a pain to<br>
> maintain. So there have to be good reasons to do this.<br>
> <br>
> Also it is kind of weird to have to use the V4L2 API in userspace to<br>
> deal with a specific audio conversion. Quite unexpected.<br>
> <br>
> But in the end, that's a decision I can't make.<br>
> <br>
> So I wait for that feedback. Note that if the decision is made that this<br>
> can use V4L2, then there is quite a lot more that needs to be done:<br>
> documentation, new compliance tests, etc. It's adding a new API, and that<br>
> comes with additional work...<br>
<br>
All agreed.  Especially in this case, it doesn't have to be in V4L2<br>
API, as it seems.<br>
<br>
(Though, the support of audio on V4L2 might be useful if it's closely<br>
tied with the a stream.  But that's another story.)<br></blockquote><div><br></div><div>audio is a stream,  for this m2m audio case, V4L2 is the best choice</div><div>I found. </div><div><br></div><div>I know there is API change for V4L2,  but V4L2 is a good framework</div><div>for memory to memory,  I think it is worth to do this change.</div><div><br></div><div>if implement this M2M case in ALSA,  we may need to create a sound</div><div>card and open it twice for playback and capture,  it is complicated</div><div>to do this,  and I am not sure if there is any other issue besides these.</div><div>I can't find an example in the ALSA framework for this case.</div><div><br></div><div>best regards</div><div>wang shengjiu</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
thanks,<br>
<br>
Takashi<br>
</blockquote></div></div>