[alsa-devel] period_size and relation to number of samples

[Takashi Iwai]

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
manner.

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).


Takashi