[alsa-devel] period_size and relation to number of samples
tiwai at suse.de
Thu Sep 6 16:48:12 CEST 2007
At Thu, 06 Sep 2007 16:30:17 +0200,
Markus Korber wrote:
> Takashi Iwai schrieb:
> > At Thu, 06 Sep 2007 07:52:37 +0200,
> > Markus Korber wrote:
> >> [...]
> >> Now, what is an application allowed to send and what not? For example,
> >> could an application only send 1024 l/r samples and is the driver
> >> responsible for buffering the data? Or must it obey the announced
> >> period_size and *always* provide 2048 l/r samples?
> > No, as mentioned, the app is free to send any size in general. When
> > the period size is filled up, basically it's supposed to be playable.
> > But, the procedure "fill the whole buffer then start" is the most
> > robust way.
> > The period size is the minimal chunk size that controls the poll
> > frequency. So, it's natural to send in this size. It's no
> > requirement but a common use case.
> Thus, is it possible to buffer the data in ALSA before sending them to
> the driver, in such a way, that the driver always receives period_size
> samples, regardless of what the application sends to ALSA? And how
> would I configure ALSA for such a setup?
No, it's NOT guaranteed. The application may behave in a very wrong
The point is that it's driver's responsibility to check whether the
data filled is OK or not. The ALSA framework is not a style like
"fill -> wakeup -> process". Instead, the data transfer is done
asynchronously, and the driver is woken up via irq (or whatever).
More information about the Alsa-devel