Writing a driver for a device which clears the buffer on the start trigger

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Writing a driver for a device which clears the buffer on the start trigger

Paul Pawlowski
Hello,
I'm writing a driver for a device which clears the BAR DMA buffer if I send the Start IO command to it. I'm not sure how to workaround this issue.

I have got the driver working to some extent by moving the Start IO command code to the open() callback instead of the trigger(SNDRV_PCM_TRIGGER_START) however that's obviously a hack and causes issues (the first ~0.1s of audio is lost).

I also tried to memcpy() the memory to a temporary buffer in the SNDRV_PCM_TRIGGER_START trigger, however that turned out to be a performance bottleneck (it took about ~300ms to copy that memory back, which is ~the period size, probably related).

I'm also aware that using some sort of a copy buffer could work, but that sounds like a performance waste as it's not needed after the playback is started.

I tried to search for existing kernel drivers utilizing a similar mechanism (there's the SNDRV_PCM_INFO_DOUBLE flag after all), but could not find any results that made sense.

Any help is appreciated.

Thank you,
Paul Pawlowski

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Writing a driver for a device which clears the buffer on the start trigger

Adrian Knoth
On Wed, Jul 31, 2019 at 09:34:45PM +0200, Paul Pawlowski wrote:

> Hello,

Hi!

> I have got the driver working to some extent by moving the Start IO command
> code to the open() callback instead of the trigger(SNDRV_PCM_TRIGGER_START)
> however that's obviously a hack and causes issues (the first ~0.1s of audio
> is lost).

You're probably better off on alsa-devel@:

   https://alsa-project.org/wiki/Mailing-lists#alsa-devel_at_alsa-project.org


I have no good immediate solution to offer (I lost touch with Linux
audio 5yrs ago, don't know why I'm still on this list :) ). Maybe you
can even start streaming in the chip init function and track in a
bool whether this is the actual stream or not. If not, then send
silence (memset the buffer, so that there's no noise), and only send
real data if there was a start command.

Terrible hack and obviously bad for power consumption.

I'm sure Takashi has better ideas on alsa-devel@. ;)

--
mail: [hidden email]   http://adi.thur.de        PGP/GPG: key via keyserver
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev