[alsa-devel] What to do when a device clears the buffer in the start trigger?

[Paul Pawlowski]

Hello,
I have implemented that today, and it seems that it takes 30ms to
memcpy() the data from the buffer to the host memory. Other than this
is works well. Source available at:
https://github.com/MCMrARM/mbp2018-bridge-drv/blob/65a09949c2d7343a073d92e4d4c24c5effa420c5/audio/pcm.c#L148

Do you think this is acceptable? Is there a better way to handle this?

Thank you,
Paul Pawlowski


On Tue, Aug 6, 2019 at 12:57 PM Takashi Iwai <tiwai at suse.de> wrote:
>
> On Wed, 31 Jul 2019 19:48:13 +0200,
> Paul Pawlowski wrote:
> >
> > Hello,
> > I have a device which clears the DMA buffer when I command it to start the
> > playback. How can this be workarounded?
>
> So it clears the DMA buffer at start, then you need to put the data on
> the DMA buffer again on the running stream?  What a weird chip.
>
> > I found the SNDRV_PCM_INFO_DOUBLE flag, but it doesn't seem that it changes
> > alsa/alsa-lib behaviour. I wasn't able to find any drivers which shared
> > this quirk.
> > I'd like to avoid double buffering if possible, as once the stream is
> > actually started it's not required.
>
> The PCM_INFO_DOUBLE flag has no effect for anything like that.  It's
> merely a information bit exposed to the user-space as a hint.
>
> In such a case, you need to implement some ugly workaround in the
> driver side.  Since the double-buffer is needed only at start, you can
> save the whole content (up to appl_ptr) and write back after starting
> the stream.
>
>
> Takashi