Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework

[Takashi Iwai]

On Wed, 23 Aug 2023 16:33:19 +0200,
Shengjiu Wang wrote:
> 
> On Fri, Aug 11, 2023 at 7:05 PM Shengjiu Wang <shengjiu.wang@xxxxxxxxx> wrote:
> >
> > Hi Mark, Takashi
> >
> > On Thu, Aug 3, 2023 at 9:11 PM Shengjiu Wang <shengjiu.wang@xxxxxxxxx> wrote:
> > >
> > > On Thu, Aug 3, 2023 at 1:28 AM Mark Brown <broonie@xxxxxxxxxx> wrote:
> > > >
> > > > On Wed, Aug 02, 2023 at 10:41:43PM +0800, Shengjiu Wang wrote:
> > > >
> > > > > Currently the ASRC in ALSA is to connect to another I2S device as
> > > > > a sound card.  But we'd like to the ASRC can be used by user space directly
> > > > > that user space application can get the output after conversion from ASRC.
> > > >
> > > > That sort of use case would be handled via DPCM at the minute, though
> > > > persuading it to connect two front ends together might be fun (which is
> > > > the sort of reason why we want to push digital information down into
> > > > DAPM and make everything a component).
> > >
> > > Thanks.
> > >
> > > ASRC M2M case needs to run as fast as possible, no sync clock control.
> > > If use sound card to handle ASRC M2M case,  the user application
> > > should be aplay/arecord, then we need to consider xrun issue, buffer
> > > may timeout, sync between aplay and arecord,  these should't be
> > > considered by pure memory to memory operation.
> > >
> > > DPCM may achitect all the audio things in components and sound
> > > card,  it is good. but for the M2M case, it is complcated. not sure
> > > it is doable.
> > >
> >
> > Beside the concern in previous mail,
> >
> > DPCM needs to separate ASRC to be two substreams (playback and capture).
> >
> > But the ASRC needs the sample rate & format of input and output first
> > then start conversion.
> >
> > If the playback controls the rate & format of input,  capture substream
> > controls the rate & format of output,  as a result
> > one substream needs to get information(dma buffer address, size...
> > rate, format) from another substream, then start both substreams in the
> > last substream. How to synchronize these two substreams is a problem.
> > One stream can be released but another stream doesn't know .
> >
> > So I don't think it is a good idea to use DPCM for pure M2M case.
> >
> > So can I persuade you to consider the V4L2 solution?
> >
> 
> Just a summary:
> 
> Basic M2M conversion can work with DPCM, I have tried with some
> workaround to make it work.
> 
> But there are several issues:
> 1. Need to create sound cards.  ASRC module support multi instances, then
> need to create multi sound cards for each instance.

Hm, why can't it be multiple PCM instances instead?

> 2. The ASRC is an entirety but with DPCM we need to separate input port and
> output port to playback substream and capture stream. Synchronous between
> playback substream and capture substream is a problem.
> How to start them and stop them at the same time.

This could be done by enforcing the full duplex and linking the both
PCM streams, I suppose.

> 3. How to handle the xrun issue. pause or resume. which are brought by ALSA.

Doesn't V4L2 handle the overrun/underrun at all?  Also, no resume
support?

Pause and resume are optional in ALSA frame work, you don't need to
implement them unless you want/need.

> So shall we make the decision that we can go to the V4L2 solution?

Honestly speaking, I don't mind much whether it's implemented in V2L4
or not -- at least for the kernel part, we can reorganize / refactor
things internally.  But, the biggest remaining question to me is
whether this user-space interface is the most suitable one.  Is it
well defined, usable and maintained for the audio applications?  Or
is it meant to be a stop-gap for a specific use case?


thanks,

Takashi