Messages in this thread | | | Date | Fri, 14 Mar 2008 14:39:42 +0100 | From | Takashi Iwai <> | Subject | Re: [PATCH] at73c213: Fix DMA size at the end of DMA buffer |
| |
At Fri, 14 Mar 2008 22:29:32 +0900 (JST), Atsushi Nemoto wrote: > > On Fri, 14 Mar 2008 10:44:45 +0100, Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote: > > > + size = runtime->period_size * runtime->channels; > > > + if (next_period == runtime->periods - 1) > > > + size += (runtime->buffer_size % runtime->period_size) > > > + * runtime->channels; > > > > Ow. That looks expensive. Isn't there any way we can force the client > > to select sane values of buffer_size and period_size? > > Well, I suppose it is not _too_ expensive. :) > > > It seems like a reasonable demand that buffer_size is a multiple of > > period_size, doesn't it? > > But actually it can happen. And I gave up understanding how are these > parameters determined... If there were any way the driver can enforce > that constraint, it would be better fix. > > Iwai-san, any comments from alsa guru?
Add the following constraint in the open callback:
err = snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); if (err < 0) return err;
This will guarantee that the period size fits with the buffer size.
Takashi
| |