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
