What to do when a device clears the buffer in the start trigger?

What to do when a device clears the buffer in the start trigger?

[Paul Pawlowski]

Hello,
I have a device which clears the DMA buffer when I command it to start the
playback. How can this be workarounded?

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.

Thank you,
Paul Pawlowski

Re: What to do when a device clears the buffer in the start trigger?

[Takashi Iwai]

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

Re: 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@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

Re: What to do when a device clears the buffer in the start trigger?

[Takashi Iwai]

On Mon, 19 Aug 2019 18:39:37 +0200,
Paul Pawlowski wrote:
> 
> 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?

Yes, that sounds like the only way...

One way would be to avoid the buffering in the driver completely.
This also includes to disable the mmap buffer access, of course.

In this alternative way, you'd need to implement copy, copy_kernel and
silence ops, for the copy operation, so the whole buffering is done in
the driver side as you like.  But if the chip clears the DMA buffer,
then you'd need to anyway do some workaround by copying & restoring
the data, so I don't think the alternative way would be worth for
consideration :)


Takashi


> 
> Thank you,
> Paul Pawlowski
> 
> 
> On Tue, Aug 6, 2019 at 12:57 PM Takashi Iwai <tiwai@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
>