At Wed, 22 Aug 2007 09:28:31 -0500,
Timur Tabi wrote:
>
> Takashi Iwai wrote:
>
> >> 3) Can I assume that .hw_params() is never called after .prepare() is called?
> >
> > The call is allowed.
>
> Ugh, so in other words, .hw_params() and .prepare() can be called any number
> of times in any order?
Well, prepare is always after hw_params. But the number of times is
unlimited.
> That makes it impossible to optimize the creation of
> the DMA buffer. Currently, I have this code at the top of my .hwparams()
> function:
>
> if (substream->dma_buffer.addr) {
> dma_free_coherent(substream->pcm->dev,
> runtime_data->ld_buf_size, runtime_data->link,
> runtime_data->ld_buf_phys);
> snd_dma_free_pages(&substream->dma_buffer);
> }
>
>
> When I look at the AT91 ASOC driver as an example, I see it allocates a DMA
> buffer of the maximum allowed size (currently hard-coded to 32KB) in the .new
> function. To me, this is cheating, but it appears to be the only way to avoid
> doing what I'm currently doing. Is this the recommend approach?
Well, the buffer size is determined dynamically, and apps may want to
change sometimes the buffer size during the run. So, the buffer
pre-allocation of fixed size is a workaround.
Alternatively, you can remember the last allocated buffer-size and
re-use the same buffer if the requested size is less than it.
Since the buffer size change won't happen _so often_ (even via OSS
emulation), this would work well in practice, too.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
